1997 Product Development Management Columns

 

Learning from Your Development Projects

Some companies recognize that their product development process is far from what it could be, so they reengineer the whole thing. This tends to be a major project and a high-risk, relatively slow path to organizational change. Other companies use a pilot project approach to "prototype" the proposed process change, which is faster and safer. However, the pitfall here is that often the pilot never becomes the model for the future; it is just an isolated interesting experiment, and thinking soon reverts to the old method. An effective alternative is to consider every project, not just the isolated pilots, as a learning experience to improve the process for the future. Here are some ways to learn from projects and what commitment is needed to make this approach work:

Expect Two Deliverables from Every Project

We usually think of a development project as delivering only one item: the product itself. But there is a second, valuable deliverable available: learning about the process that was used. Managers who are serious about improving their development process do not consider a project complete until both are delivered. There is more to it though, because there is a cost attached to process reviews. They take effort, and this effort comes directly out of your capacity to develop new products. In other words, it is a tax you place on every project to build a competitive asset--your development process--for the future.

Separate Process Reviews from Project Reviews

These reviews probably sound familiar, because you now probably conduct regular reviews of your projects. But the type of review needed to improve the process is quite different from the normal ones that focus on the project. Project reviews identify shortfalls or overruns in the project and take action to correct that project. Process reviews instead write off the project under review as a "sunk" event but look at it deeply for clues that will improve future projects.

Review Every Project

Do not review an occasional project that proceeded especially well or poorly, but expect to learn from every project (above a certain threshold in size). There are practical reasons for this. Most companies do not have a large enough sample of projects to see patterns clearly; they need all of the reviews they can get. More subtly, selecting certain projects for review makes them special. They turn out to be congratulatory exercises for the participants--or worse, witch hunts--which erode the learning and suggest to the participants that both they and the process are on trial.

Institutionalize the Feedback Process

In order to gain benefit from the effort expended on the review, establish a leak-tight system to convert significant findings into action. Those with the authority and resources to make changes in the process must initiate and monitor the change process.

The resource issue cannot be overemphasized. Conducting effective process reviews will divert resources from activities, such as product development, with more immediate payoff, and taking action on certain findings will usually demand even more resources. Thus, an improved development process must be viewed as a strategic investment, just like a new laboratory. How much you are willing to invest depends on how quickly you wish to improve. Viewing the benefits as being free is a prescription for failure.

Return to newsletters  |  Product development publications  |  Home

 

Will You Profit from Rapid Product Development?

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.

Return to newsletters  |  Product development publications  |  Home