Hard-pressed, we want faster, better, cheaper in everything we do. Yet, fast cycle time can have its price, so it should not always be the primary emphasis. Wise managers apply cycle time reduction techniques only when their benefits outweigh their costs. When other objectives drive the project, they switch to other tools and metrics.
Often, the cost of short cycle time manifests itself as trade-offs with other project objectives, such as development expense, recurring manufacturing cost, or product features. Any of these objectives might be improved by stretching out cycle time. Conversely, techniques that accelerate development can compromise these other objectives.
Consequently, we suggest that fast cycle time techniques be applied selectively, on a project-by-project basis, where they yield the greatest return. Fortunately, you can determine quantitatively just where to apply the techniques. Techniques for calculating and applying the cost of delay — or “urgency factor” — are described in detail in Chapter 2 of Developing Products in Half the Time and summarized in this cycle time article.
Because the cost of delay can vary greatly, depending on the specific project under consideration, general guidelines, such as a 50-percent across-the-board reduction in cycle time, seldom have broad validity. Likewise, a “rule,” such as “accelerated development is more important in high-tech,” is also situation dependent. Many lower-tech companies have built a strong competitive advantage by having a shorter cycles than their direct competitors.
Another dimension to speed is the predictability of cycle time. Many of the tools that shorten development cycles actually make them less predictable. If schedule predictability is important to you, consider project risk management.
Clearly, speed could be gained in the short run by skipping some steps of development. Seldom is this wise, and we do not recommend skipping steps to accelerate your development unless you discover that these steps actually do not provide commensurate value.
An alternative to speed is flexibility, which recognizes that it is not speed itself that is important but nimbleness to follow change when technologies or markets are in flux or we don’t understand what customers want well. In short, consider the cost of change rather than the cost of delay. If this fits you, consider flexible product development.
In the end, however, speed is perhaps the most comprehensive metric we have to measure overall development performance. It is no accident that many athletic events are conducted as races against the clock. If there is a weakness anywhere in the athlete, the equipment, the environment, or the training, performance will suffer. Likewise with product development: it can be superior only when all facets work together well, and “well” is best measured in terms of speed. Whether or not you actually accelerate each project, an accelerated development capability will keep you fit in general and trained to sprint when circumstances demand it.
For more on this subject, see the handbook chapter on the techniques and traps in accelerated development, our article, “Reaping Benefit from Speed to Market,” our Quick Tip on faster, better, cheaper, or our interview in Product Development Best Practices Report.
(c) Copyright 2012 Preston G. Smith. All Rights Reserved.
