1997 Product Development Management Columns
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.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.