As an expert on the management of product development for more than two decades, Don Reinertsen is famous for bringing ”fresh perspectives and quantitative rigour” to the subject. Here, he shares some of his thoughts on product development with Softhouse’s Ingemar Andreasson.
The title of Don Reinertsens latest book is “The Principles of Product Development Flow – The Principles of Second Generation Lean Product Development”. In the book, the terms “first generation” and “second generation” are used to highlight an evolving understanding of how lean methods can be applied in product development.
- First generation approaches started with the ideas of lean manufacturing and peaked at Toyota’s application of these ideas in its product development system. However, ideas that work with the repetitive, low-variability work of manufacturing are often not suited to fast moving markets that rely on innovation. For example, first generation thinking strives to eliminate as much variability as possible with the unpleasant side effect eliminating innovation. The need for innovation demands that we learn to function well in the presence of variability.
- Second generation approaches use Toyota as a starting point and incorporate advanced methods from many other domains. These include ideas from economics, queueing theory, statistics, telecommunication network design, computer operating systems, control engineering, and maneuver warfare. More advanced ideas are needed because the domain of product development is intrinsically less repetitive and more variable than manufacturing. As a result, you have to look to domains that have learned to achieve flow in the presence of variability – not domains that achieve flow by eliminating variability. It is simply too limiting to assume that reducing variability is the only possible solution.
A science-based approach
“Of course this makes second generation ideas more intellectually challenging,” says Reinertsen. “First generation thinking was very empirical and “faithbased”. We were told, ‘Trust us, if this method works for Toyota in the automotive business it applies everywhere. Don’t worry about why it works. Only non-believers ask questions.’ Second generation thinking is more sciencebased. It emphasizes the need to understand the mechanism of action behind methods. It emphasizes the quantification that is required to make tradeoffs between multiple important objectives.
” Reinertsen gives a simple example: First generation thinking treats the optimality of “one-piece flow” as an article of faith. In contrast, second generation thinking treats batch size as an economic tradeoff between holding cost and transaction cost. It uses larger batch sizes when transaction costs are high, and smaller batch sizes when they are lower. It understands the quantitative relationship between transaction cost and batch size and uses reduction of transaction costs as a way of enabling lower batch sizes.
“We see such thinking in software development where test process automation has driven down the transaction cost of testing and thereby enabled much smaller batch sizes,” says Reinartsen.
Queues need to be managed
Reinertsen often stresses the role of queues in product development. Like manufacturing, product development has work-in-process inventory. Most of this inventory is work products sitting idle in queues.
“It is hard to over-emphasize the importance of these queues,” Reinertsen says. “These queues are typically unmeasured and unmanaged – 98 percent of product developers do not know the size of the queues in their development processes. This should not really surprise us because inventory in product development is not physical objects, but information – information that is invisible both physically and financially.”
Why then do we have large queues in product development? According to Reinertsen, we only need to understand a little queueing theory to see that the answer is obvious. When a process with variability is loaded to high levels of utilization our work products will spend
most of their cycle time waiting in queue. The higher we load our resources the slower our cycle time becomes.
“Where do we load our processes today? Typically above 98 percent utilization! It should be no surprise that we have queues,” Reinertsen says. “These queues increase cycle time and overhead. They hurt quality by delaying feedback. They demotivate our workers. How do we reduce
them? It starts by measuring them and quantifying their cost. Then, we can look at actions we can take to shrink the queues and compare the cost of these actions to their benefits.”
How then would Reinertsen recommend that a company start introducing lean methods in product development? “I always start by developing an under standing of the economics, identifying the queues, and then determining their costs,” he says. “However, there are actually many places a company can start. Some companies start by reducing batch sizes in their processes, others by making work-in-process inventory visible with visual control boards, and others by implementing WIP constraints.In general it helps to pick something that is causing pain and to produce meaningful results quickly. This generates energy that can be harnessed to make broader changes.”
Understanding economics
In his books and lectures, Reinertsen often points out that a thorough “understanding of your economics” is crucial for anyone trying to optimize the product development processes in their organization.
“All product development activities attempt to simultaneously satisfy multiple competing performance objectives. We have product performance goals, schedules, and development budgets. We cannot maximize all of these measures of performance at the same time, so we trade performance in one area for performance in another area. How do we do this today? We use our intuition, and our intuition is terrible. If you ask people working on the same project to independently estimate the cost of delay on their project and you will get answers that differ by 50 to 1. To make better decisions we need to express all our objectives in the same unit of measure. We normally use life cycle profit impact as this measure. Let’s say that adding a new feature would delay the project by 2 weeks. If we know that cycle time is work € 100,000 per week then we should only add the feature if itwill produce more than € 200,000 of extra profit. This may seem quite basic but today 85 percent of product developers do not know the cost of delay for the projects that they are working on.
Taking control in a changing environment
Quantification is the foundation of any science-based approach. When we try to optimize our processes we always encounter situations where some measures of performance improve as others get worse. Overall performance is a U curve function. We can only deal with these problems with the aid of quantification. Moreover, by quantifying tradeoffs we can rationally adjust our tradeoffs as our economic context changes. This transparent logical relationship between our choices and our environment is critical in a world where the environment constantly changes. Finally, grounding our choices on economics is key to gaining the support of management. Management has the legal duty to pay attention to the economic consequences of its choices. Management always has surplus of good ideas to spend money on. When we package our choices within an economic framework we enable management to choose between these ideas quickly and correctly. When we use qualitative and “faith-based” arguments we make it much harder for management to support us.”
