I'd rather play golf

In his latest book, The Principles of Product Development Flow [1] to be released next month, Don Reinertsen challenges what he calls the “current orthodoxy” of product development, which in his view suffers from its failure to recognize, and correctly quantify, economic factors and their essential role in management decision making. Tightly coupled to this discounting of economic factors is the ignorance surrounding the management of queues in the product development process, their impact on development cycles times and, in the end, profit. Quoted below are some introductory remarks from page 6:

Few developers realize that queues are the single most important cause of poor product development performance. Queues cause our development process to have too much Design-in-Process inventory (DIP). Developers are unaware of DIP, they do not measure it, and they do not manage it. They do not even realize that DIP is a problem. For example, product developers will say that they want to be more innovative and never realize that high levels of DIP undermine this objective. When DIP is high, cycle times are long. When cycle times are long, innovation occurs so late that it becomes imitation.

There are two important reasons why product developers are blind to DIP. First inventory is financially invisible in product development. We do not carry partially completed designs as assets on our balance sheet, we expense R&D as it is incurred. If we ask the Chief Financial Officer how much inventory we have in product development, the answer will be “Zero”. Second, we are blind to product development inventory because it is usually physically invisible. DIP is information, not physical objects. We do not see piles of DIP when we walk through the engineering department. In product development our inventory is bits on a disk drive, and we have very big disk drives in product development.

The Principles of Product Development Flow is a dense 290 pages organized around eight major themes, categorizing 175 individual “principles”:

• Economic Principles (21 rules)
• Queuing Principles (16 rules)
• Variability Principles (16 rules)
• Batch Size Principles (22 rules)
• WIP Constraint Principles (23 rules)
• Flow Control Principles (30 rules)
• Fast Feedback Principles (24 rules)
• Decentralization Principles (23 rules)

Economics

The main tenet of this new volume, and the foundation of most of the material in the book, is the necessity of including economically-based decision making in the product development process. Reinertsen argues that, since we are in business to make money, product development decisions must be based on economic arguments, and such economic choices must be made continuously. Indeed, it is the variability of product development, and its inherent risk, that necessitates continuous re-assessment and/or adjustment of management decisions. This can only be done effectively when one has an estimate of the Cost of Delay (COD): the financial impact of delaying a product by x time periods. Only if one understands COD can one make cost/benefit tradeoffs with respect to product development decisions: without COD, there appears to be no impact on extending a release schedule, delaying the introduction of a specific feature, or making design tradeoffs that can shorten or lengthen development time.

A lengthy introduction to determining the cost of delay was presented by Smith and Reinertsen in their earlier volume [3], and consequently is not covered in detail in the current work. Instead, Reinertsen concentrates on 21 principles that involve cost/benefit tradeoffs based on knowledge of the cost of delay. The most important of these is assessing the cost of Design-in-Progress (DIP) inventory, which Reinertsen argues has a significant holding cost that is not typically accounted for, as in the quote above. DIP is important because high levels of DIP lead to the formation of queues which kills productivity and lengthens cycle time, leading to additional delays and, hence, higher COD.

Anyone with experience in application software development has experience with Reinertsen’s Principle E21 (pp. 58), the Show-Me-the-Money principle:

Most corporations give control over financial resources to people who worry about the economics of their choices. To influence these people, we must speak the language of economics, not the language of proxy variables…..Whenever I am told that management makes decisions too slowly, I ask to see the specific proposal that went to management. Invariably, I discover that the cost and benefit of the decision are either unquantified or poorly quantified.

In my personal experience, the above scenario is often familiar because in software development it is relatively easy to quantify development effort; it is often extremely difficult to quantify the benefits of one solution over another. Management often requests the ability to choose among several potential solutions or designs to a specific request–but without effective analysis of the benefits of each design, which includes cost-of-delay, management will by default simply select the alternative with the lowest development cost: the proverbial “hack”.

Queues

In Chapter 3, Reinertsen brings up the theory of queues and their importance in the product development process. Here’s one quote (page 63):

Few product developers are aware of the causal links between high capacity utilization, queues, and poor economic performance. Instead, developers assume that their cycle times will be faster when resources are fully utilized. In reality, as we shall see later, high levels of capacity utilization are actually a primary cause of long cycle time.

Queues are a problem in product development for at least six different reasons: they increase product development cycle time; increase risk; increase variability; increase costs; delay feedback; and sixth, have a negative affect on the development team by decreasing motivation and initiative.

Reinertsen illustrates the problems with queues, particularly with high developer utilization, using examples from queuing theory. Here is Figure 3-5 from page 72, used with permission:

This figure illustrates the problems that occur with high levels of capacity utilization in product development: once capacity utilization exceeds the 80% threshold, even small deviations in project duration and/or arrival rates result in significant growth in queue size, which increases the cycle time of each work-in-process in the queue.

As with everything else in the book, Reinertsen re-asserts the arguments concerning queues in economic terms, in particular that optimum queue size is dependent on a firm’s cost of delay – described in detail in principle Q9 on page 78. Moreover, Reinertsen describes how managing queues can improve product development efficiency, because queues are a leading indicator of product development problems, much more so than cycle time, which is a lagging indicator. In the end, (pp. 80):

Finally, let’s stress that any economically grounded queueing discipline relies on knowing the cost of delay for the projects in the queue. This method of setting priorities has an interesting side benefit. When we base priorities on economics they tend to remain more stable than priorities based on opinions. Opinions can be changed by the last phone call received from a customer. In contrast, economic facts change less abruptly. The key to stable priorities is to link them to economic facts.

In part deux, I’ll discuss three other themes of this tremendously useful book: variability, batch size, and WIP constraints.

[1] Donald G. Reinertsen (May 2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, Redondo Beach, California. ISBN 1-935401-00-9.

[2] Donald G. Reinertsen (1997). Managing the Design Factory. Simon and Schuster, New York, New York. ISBN 0-684-83991-1.

[3] Preston G. Smith and Donald G. Reinertsen (1998). Developing Products in Half the Time: New Rules, New Tools (2nd edition). John Wiley and Sons, New York, New York. ISBN 0471-292524.