Product development projects are notorious for going over budget. Often way over budget. This is particularly true in small companies. The opportunity to develop products is generally less frequent in a small business.
Sometimes years can go by before another new product is developed and the team that developed that last product may no longer be with the company. Small businesses just do not get the experience necessary to be good at a task that is hard, even for those who do it every day.
Worse, small companies are more sensitive to the product development budget. They do not have the ability to sell a large number of units to offset unbudgeted tasks. If the budget is wrong, the project may never produce a positive return on investment and could be shut down after wasting significant funds.
Understanding the dynamics that can cause a product development budget to go awry is key to improving the budgeting process.
The dynamics of why a product development budget can go wrong
Unlike most business functions, developing a new product is about doing something that has never been done before. No one has ever engineered this product before.
In the beginning, it is often not entirely clear exactly what this product is going to be. Further, unlike some business activities, the product must actually function and meet certain objective requirements. We can’t just say it is good enough or change the goal to meet the budget.
All of these factors conspire to produce an environment where there are many unknown activities that must get done. But it is not possible to know they need to be done until you know the so-called “unknown-unknowns”. It is simply not possible to know all the tasks that will need to be done in product development.
How do you budget for tasks that you don’t know you will need to do?
Another common dynamic is wishful thinking. It is not uncommon for teams to believe in some product idea so strongly that they suspend all belief (and even ignore experts) about what it will cost.
A related dynamic that often creeps into the process is a failure to choose two of the three priorities: time, budget, and quality. Too often managers want all three and get none.
Taking shortcuts to reduce time and budget is not likely to produce a quality product. Trying to do all three costs more, takes more time, and produces a lower quality product.
Picking all three priorities always fails. But a small business with limited product development experience can be led to believe they can (and should) insist on all three.
And of course, there is always scope creep.
We start with a simple idea and start adding little pieces to it as we go. No one idea seems all that significant, but add them all together and soon the complexity mushrooms and cost expands accordingly.
None of these dynamics are new. Experienced teams with proven processes successfully deal with them all the time. However, small businesses with less experience and little product development processes often fall victim to one or all of these dynamics.
How should a small business avoid these pitfalls? Start with a good budgeting process.
The budgeting process
World-class product development budgeting processes all have one thing in common: they are all done in stages.
Each of these stages, or stage gates as they are sometimes called, follow the product development processes: Requirements, Conceptual, Detail, Verification, and Production.
It is simply not possible to know a budget with any certainty the day a product idea is born.
Sure, you can get some rough ideas, but this is merely an educated guess. Nothing wrong with doing a ROM (Rough Order of Magnitude) estimate on day one. It may help you to decide to forget about the idea altogether. However, a ROM is not credible enough to invest in anything more than the next step in the process.
At each stage in the product development process, there should be a gate: a re-estimation of the development cost and ROI analysis. We just completed the requirements phase. Let’s see if our estimate of the project cost has changed and if that change will cause us to reconsider the viability of the project.
Step one in any product development budgeting process is to determine if the timing is right for a new product.
Just because you can think of an idea for a project, does not mean it should be developed, or developed now. Or just because you cannot think of improvement in a product does not mean your competitor can’t.
Once you have decided it may be a good time to add a new product to the lineup, the first step is to get a ROM estimate of the cost. At this point, all you have is an idea. It will take time and money to develop requirements and conceptual design – the first two steps in the process.
Although these steps typically only make up 15 percent of the total product development budget, it is still a good idea to spend some time determining if the project is going to have a positive ROI.
This ROM estimate only has to be good enough to decide if it is worth investing time and money into requirements generation. After requirements generation, there will be another gate to determine if it is worth proceeding to conceptual design.
The best ROM processes either use a spreadsheet or simply compare to a similar project. For example, this project we did cost $XX and it is very similar to this new idea, so it will also cost $XX.
One word of caution on this second method – it is very easy to get wrong, especially if you do not have firsthand knowledge about the project used in the comparison. Many people have different ideas of what constitutes cost. It is not uncommon for us to find teams that do not include the people cost in estimates – which typically makes up 95 percent of the true budget.
It is also not uncommon for engineers to give estimates for just the part of the job they would be doing – leaving off other activities that are significant parts of the budget.
Unless you have really good activity-based cost accounting methods, use a spreadsheet and give validity to individual guesses of cost.
Very few people truly understand what it costs to do things in a business. If the ROM estimate looks good (it will have a positive ROI), then it’s time to start work on the requirements phase.
Any good requirements processes will include the developmental budget requirement, as well as functional, performance, unit cost, etc.
At the end of this process, your product engineering team needs to commit to designing a product that meets all of these requirements for the budget.
Ideally, this is the result of a lot of back and forth with the rest of the company (sales, marketing, ops, production, etc.) about what can and cannot fit in this budget.
If it is a budget simply dictated from above, without any push back, expect it to be wrong. Probe the team for true belief and commitment.
As they say, if you think you can, or cannot, you are correct. Once the requirements are complete and agreed to by the team, they should be fixed, and only changed by following a well-defined process.
At a minimum, the change should be run by the team that developed them, and some kind of impact analysis should accompany the change request.
This process is key in preventing the inevitable scope creep that so often blows up development budgets. During the conceptual phase, you will be comparing different concepts with the requirements.
The best processes weight the requirements including the developmental budget requirements. All the concepts generated will meet the requirements, but some will meet some requirements better than others.
In order to choose the best concept, it must be clear how important the development budget requirement is relative to the other requirements.
Detail design
Detail design is the phase where you finally have some idea of the tasks involved and start to develop a bottom-up plan. To this point, all planning and budgeting have been top-down.
We recommend to our clients, at the start of the detail design, to first develop a drawing tree. A drawing showing the product structure.
Get the entire engineering team, and the production team, to agree to the drawing tree. Once this agreement is in hand, assign the role and responsibility of each drawing to an engineer.
Get their commitment to when the drawing will be completed, when the part will be prototyped, when the DVT (Design Verification Test) will be done, and the cost.
One word of caution here. Some level of coaching will be necessary for members of the team that has never experienced this type of process before. Most engineers are not accustomed to this level of responsibility.
Expect push back, and anticipate some uncomfortable conversation. In all likelihood, they will not like this idea the first time they hear it.
However, once they go through the process a few times, they will insist on it being done. Even after design verification has been completed, there will be cost.
Ramping up production can mean test fixtures and procedures, molds, programming, stencils, etc.
These costs can be very small (software only product) to half the development budget or more. If your production is going to be complex, it is a good idea to involve your contract manufacturer early in the process.
Steve Owens, Founder and CTO of Finish Line Product Development Services, has over 30 years of successful product development experience in many different industries and is a sought after adviser and speaker on the subject. Steve has founded four successful start-ups and holds over twenty five patents. Steve’s insight into the product development process has generated millions of dollars in revenue for start-ups and small businesses.
