Principles Of Product Development Flow
1 The Principles of Flow
I believe that the dominant paradigm for managing product development is fundamentally wrong. Not just a little wrong, but wrong to its very core. It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing.
Officially, many product developers have phase-gate processes.
What really happens is quite different. When I survey managers in my product development courses, 95 percent will admit that they begin design before they know all requirements.
The underground overlap of design and specification activities is just one simple example of this alternative paradigm in action. Among other things, this paradigm emphasizes small batch transfers, rapid feedback, and limited work-in-process inventory (WIP). These three specific methods are actually broadly applicable throughout the development process. When we recognize why they work, we can adapt them to dozens of situations.
At its heart, this new paradigm emphasizes achieving flow.
However, the methods of lean manufacturing have been optimized for a domain with very different characteristics than product development.
To distinguish this more advanced approach from the ideas of lean manufacturing, we call it Flow-Based Product Development.
What Is the Problem?
Today’s orthodoxy has institutionalized a set of internally consistent but dysfunctional beliefs.
Let’s look at how our current beliefs reinforce each other. For example, if we combine the belief that efficiency is good, with a blindness to queues, we will load our development process to high levels of capacity utilization.
Let’s take another example. If we combine the belief that variability is bad with the failure to correctly quantify economics, we will minimize variability by sacrificing other unquantified economic goals.
Let’s pick twelve key problems with the current approach,
Failure to Correctly Quantify Economics
the only way to comprehend the economic importance of queues is to quantify the Cost Of Delay for product development projects. Yet, today, only 15 percent of product developers know the cost of delay associated with their projects.
Cycle time is only a proxy variable.
The danger in focusing on proxy variables is that proxy variables interact with one another.
This unit of measure should be life-cycle profit impact, which is the ultimate measure of product development success.
Blindness to Queues
Queues cause our development process to have too much design-in-process inventory (DIP).
There are two important reasons why product developers are blind to DIP. First, inventory is financially invisible in product development.
Second, we are blind to product development inventory because it is usually physically invisible.
queues lie at the root of a large number of product development problems. They increase variability, risk, and cycle time. They decrease efficiency, quality, and motivation.
To understand the economic cost of queues, product developers must be able to answer two questions. First, how big are our queues?
Second, what is the cost of these queues?
Worship of Efficiency
If we are blind to queues, we won’t know the delay cost, and we will only be aware of the cost of capacity.
large queues form when processes with variability are operated at high levels of capacity utilization.
Although efficiency does have economic impact, it is only another proxy variable.
Hostility to Variability
This emphasis on variability reduction is deeply flawed for three important reasons.
First, without variability, we cannot innovate.
Second, variability is only a proxy variable. We are actually interested in influencing the economic cost of this variability.
we usually discover it is much easier to alter the payoff-function than it is to reduce the underlying amount of variability.
Third, with a little help from option pricing theory, we will discover that we can actually design development processes such that increases in variability will improve, rather than worsen, our economic performance.
Worship of Conformance
To manage product development effectively, we must recognize that valuable new information is constantly arriving throughout the development cycle. Rather than remaining frozen in time, locked to our original plan, we must learn to make good economic choices using this emerging information.
Institutionalization of Large Batch Sizes
Our blindness toward queues and our focus on efficiency lead us to institutionalize large batch sizes.
this efficiency gain and variability reduction is only an illusion.
we will examine how we can enable small batch processes by systematically lowering transaction costs.
Underutilization of Cadence
cadence and synchronization are surprisingly powerful tools for product development.
Managing Timelines instead of Queues
Queues are a far better control variable than cycle time because, as you shall see, queues are leading indicators of future cycle-time problems.
Absence of WIP Constraints
our development processes can be both efficient and responsive in the presence of variability. To do this, we must make resources, people, and processes flexible.
In telecommunications networks, we use adaptive approaches that enable us to adjust to emerging congestion
Noneconomic Flow Control
we should not prioritize on the basis of project profitability, but rather on how this profitability is affected by delay.
We create project management offices.
We shall see that this is a mistake in Chapter 8, when we examine the role of fast feedback.
One of the most interesting examples of decentralizing control without losing alignment is the way the military deals with the uncertainty of warfare.
A Possible Solution
We will explore eight major themes,
TOC deserves respect because it has been an extraordinarily useful tool for making people aware of queues. However, the time has come to go a bit deeper.
reducing batch size is usually the single most cost-effective way to reduce queues.
batch sizes have their own economic tradeoffs, which lead to U-curve optimization problems.
WIP constraints exploit the direct relationship between cycle time and inventory, which is known as Little’s Formula.
Cadence, Synchronization, and Flow Control
We can synchronize with or without cadence. We can use cadence with or without synchronization. It is best when we combine both.
The Relevant Idea Sources
Computer Operating System Design
The Design of This Book
organized into 175 principles.
I have chosen to emphasize principles for three reasons.
It Will Be a Long Journey, so Start Now
began writing about the importance of calculating Cost Of Delay in 1983.
The methods in this book can be implemented using two general paths. They can be implemented from the top down in one large batch, or from the bottom up in small batches.
2 The Economic View