Over the past few years many managers have embraced short-cycle product development as a means of improving their competitive positions. Amazingly, few of these managers can elucidate just how getting a new product to market faster will actually improve their profitability. Furthermore, these are the same hard-headed managers who demand numbers and facts before making other business decisions. Why do they just accept time-to-market as an improvement target without the financial facts?
There are two quite practical reasons why you need to know the cost of delay for your projects before you attempt to accelerate them. One is that cycle time is not a universal benefit. The profit impact of shaving a week from a schedule differs greatly between projects, even in the same company. Some of your projects probably do not warrant what it will cost to speed them to market. You will not know which is which unless you calculate the “urgency factor” on a project by project basis.
Second, although it is usually no more expensive to develop products quickly, there is up-front work required to set up needed systems and processes. Companies such as Black & Decker, Chrysler, and Motorola, which have made remarkable time-to-market gains, have made substantial investments in improving their development processes. Unless the profit impact of this program is clear, the investment is likely to wane, and cycle time will never really improve.
On a daily basis, product developers implicitly trade off time against money without ever recognizing it as a trade-off, or knowing the cost of delay for their project. If you save a week on your project, is it worth $1,000 in profit to the company, or is it worth $1,000,000? Often, we make such decisions on a black-or-white basis. Either there is no money in the budget to “buy” time, or there is no time in the schedule to give up, regardless of its price. Typically, these groundless trade-off decisions are debated endlessly, consuming more time, or they get reversed by management, demoralizing the development team.
There is no reason to run a project without knowing the cost of delay, because it is quite straightforward to calculate. First, build a baseline cash flow model for the project for its entire development cycle and projected sales life. The result of this model is lifetime pre-tax profit for the product. “Baseline” means that the project goes according to plan. Then construct scenarios for off-plan situations: schedule slippage, a project budget overrun, a product unit cost overrun, and a shortfall in product performance of feature set. Express each of these off-plan scenarios as a variation of the baseline cash flow model. Finally, construct the trade-off rules by subtracting the profit of the off-plan case from the baseline profit.
Remember to keep the model simple, to promote buy-in and because you do not need a fancy model to improve greatly on the intuitive decisions most developers make. Also, promote ownership and understanding by using a cross-functional development team to create the model; finance people can help, but don’t let them take over. Lastly, post the cost of a week’s delay for your project boldly in the team area, and use it to make those daily trade-off decisions.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
