Here at Rose-Hulman Ventures, we love working in the innovation space. The most invigorating projects are the ones where clients challenge us to go beyond what they know is possible in developing a new process or product. However, our clients often struggle with how to define the scope of projects like this.
A common mistake is trying to include too much detail in the scope. This is understandable. If you are going to try to do something new and innovative, you might as well “swing for the fence”, and push the boundaries as far as you can. You know good and well that even achieving only 80% of your goal is still a valuable outcome, but why not push the development team to go as far as they can? After all, if you are going to commit to the cost of doing a project, you might as well get all you can for the money.
However, a problem arises if the people working on the technical challenges only have the scope to go by when accessing the value of their work. If the specification is for a performance value of “X,” then they won’t realize that reaching 80% of “X” is good enough. The team will continue to push the boundaries until “X” is achieved, and as we all know, that last 20% of performance is likely to require 80% of the overall cost.
A better approach is to start with the minimum functionality that is necessary to solve your biggest immediate issues. As you spell out your minimum requirements, you also include the performance or features that would be nice to have, but not necessary. You are more likely to end up at a favorable ratio of value per development dollar if the development team is informed enough to make some value decisions on their own.
You don’t have to pack all of your future needs into the first development effort. It may seem that doing so will save the cost of starting up another development team in the future, but this is often a false economy. It may well be that developing the features for tomorrow will cost less once the solutions of today have had time to become a stable foundation.