This article originally appeared in the
October 1999 issue of PDBPR
EXPERT COMMENTARY
There is no 'fun' in the funnel
Don Reinertsen,
Reinertsen and Associates
Most product developers think of the development funnel as a "best
practice". Its virtues are described in standard academic texts on product
development. However, few product developers are aware of the dangerous 'dark side' of
this tool. To understand this dark side we must look at the funnel as a production
process.
The standard advice on designing such a funnel
is to "widen its mouth" and "narrow its neck". Let us look at the
consequences of such a process design by examining two companies competing in the same
market.
The first company, Tunnel, Inc. shapes its
process like a pipe. Four ideas are started and all of them survive to completion. Even
from the beginning of the process each idea gets the dedicated attention of a full-time
person. This means that early activities operate at a high duty cycle and the process has
low percent queue time. As a consequence ideas become products in 12 months. The company
reports no problems in picking winners explaining that it is quite realistic to forecast
technology and market trends 12 months in the future.
The second company, Funnel, Inc. uses a classic
development funnel. Early in the funnel 40 ideas are processed by 4 people. Since in
reality each person works on one idea at a time, 9 ideas are sitting idle while one is
being processed. Thus, each idea spends 90 percent of its processing time sitting idle in
a work queue, and 10 percent of its processing time being worked on. This low duty cycle
means that processing which took 4 months for Tunnel, Inc. takes 40 months at Funnel, Inc.
Therefore, cycle time through the funnel is 48 months instead of 12 months.
Importantly this long cycle time forces Funnel,
Inc. to forecast technology and market trends at a 4-year horizon instead of a 1-year
horizon. Unfortunately, because forecasting difficulty rises exponentially with the time
to the planning horizon it is very difficult for Funnel, Inc. to pick the winners in
advance. They compensate for this by widening the mouth of the funnel to compensate for
fallout in the pipeline. Of course, a wider funnel mouth overloads early processing stages
lengthening the cycle time through the funnel. The longer cycle time in turn requires a
longer planning horizon. This
self-reinforcing property can make the development funnel a death spiral.
Does this mean we should discard the development funnel from the developer's toolkit? No,
it has a place, it just needs a warning label. The key weakness of the funnel is that it
focuses narrowly on efficiency and ignores cycle time. The very filters which ensure that
no bad ideas make it to later stages can add so much delay time that ideas become stale
before they make it through all the filters. A better approach is to evaluate the total
economics of the funnel by quantifying the dollar impact of both filtering efficiency and
cost of delay. By putting funnel design into a quantitative framework we can make sound
tradeoffs between different process objectives. You will find that funnels work well for
slow-moving markets with low cost-of-delay. In contrast, fast-moving markets with high
cost-of-delay typically need a process that looks like a pipe.
Ironically, we already learned this lesson in
our factories. Forty years ago many of our factories had long processing lead times. We
started more parts than we needed to compensate for yield problems along the way. As we
improved quality and reduced batch size we were able to achieve balanced flow and shorten
lead times. Shorter lead times reduced our dependence on uncertain long-range forecasts
and reduced our vulnerability to rescheduling by customers.
In our development funnel the yield problems are
caused by the distance to the planning horizon. This distance makes it harder to forecast
both technology and market requirements. And our yields drop the longer an idea spends in
the pipeline. We can improve them by balancing the pipeline to make it flow faster.
My key point is that development process design
is not simply a question of topology. What is far more important than the layout of the
process is the flow rates and queues that exist due to mismatches in flow rates. If you
fail to pay attention to this critical quantitative dimension you may find that there is
not much fun in the funnel.
|
This
article originally appeared in the
January 2000 issue of PDBPR
TOYOTA'S FUNNELS ARE FUN
(and fast, and work all the time)
Dr. Allen C. Ward,
Ward Synthesis, Inc.
The following article by Dr. Allen C. Ward is in response to Don Reinsertsen's
column, "There is No Fun in Funnel" which appeared in the October, 1999 issue of
BPR.
In the October issue of BPR, Don Reinertsen argued that a "funnel" development
process (in which many ideas are rejected during development) is bound to be slow. He
suggested a "tunnel" process in which any concept on which work is started is
carried through to completion. He argues that since a person can only work on one idea at
a time, considering many ideas early in the project results in a logjam where concepts are
stuck in a queue. This slows the project, increasing time to market, and resulting in more
market misses.
This argument omits the important fact that the
analysis done on ideas early in a project is much faster and consumes fewer resources than
the actual completion of the project. Considering a large number of ideas early in the
process can save the waste of full development projects carried out on inherently inferior
concepts. Indeed, it is rarely the case that the first idea that comes into the head of a
design engineer is the best one. Da Vinci previewed every painting with a number of
sketches, and Edison tried more than 1000 light-bulb filaments.
The real question is not whether to have a
funnel: every development system must have some means of sorting good ideas from bad
before committing to them. The questions are: 1) should we have many projects in the
funnel, and then "kill" some of them later; or, consider many ideas within each
project, and then carry each project to completion? And, 2) what should be the shape of
the funnel?
As to the first question, Reinertsen argues that
you should not start a project unless you intend to finish it. He answers the second
question by saying that the funnel should have a long straight tube at the bottom, while
the shape at the top of the funnel (in which bad ideas are rejected) should be, according
to his argument, so short and flat that, in fact, he doesn't mention it at all.
Experience with the auto industry suggests that he is half right. Toyota and its major
suppliers are considerably faster than their competition, while producing higher quality
designs with less engineering investment. They do this with a system that rarely – if
ever – kills projects. Every project goes to the finish. But each project employs a
fairly "deep" idea funnel, which converges very tightly at the end of the
project. That is, the project maintains a level of uncertainty about specifications,
dimensions, and concepts much later in the development process than is common in the US.
Importantly, multiple concepts are maintained not only at the system level, but also at
the subsystem level.
This works in part because it provides
redundancy, and therefore reliability, in the development process. At the beginning of the
process, there are many ideas for each subsystem; one will certainly succeed, even though
we have little knowledge to tell us which one. By the end of the process, we have killed
the weaker ideas through the simplest, cheapest, and fastest tests or analyses. And we
have learned enough about the surviving ideas to be sure that they will work.
Reinertsen's "tunnel" concept would be
valid if one only had good ideas, or at least some infallible way of separating good from
bad before starting development. Unfortunately, the more innovative the idea, the more
difficult it is to tell whether or not it will work without doing some development. Thus,
the clear data from automotive developers suggests that deepening the funnel can produce
faster results and save engineering resources.
Don Reinertsen Responds
Dr. Ward is a well-recognized expert on
automobile development. His work suggests that Toyota maintains a broader pool of
subsystem concepts active during the product development process than American automotive
companies. He does not claim that Toyota uses this approach at the system level, but
rather points out that Toyota's system "rarely – if ever – kills
projects." Thus, Toyota is using both a "funnel" and "tunnel,"
and if they are well-managed, as Dr. Ward believes, this demonstrates how well-managed
companies use both approaches. This is consistent with the central point of my column that
"funnels" are neither a universal best nor worst practice but simply a choice
that will make economic sense in certain contexts.
We would probably agree that the choice of a
funnel or tunnel is a question of economics not ideology. Toyota's subsystem approach
incurs extra subsystem development expenses in return for shortening response times and
reducing systems integration expenses when a dominant concept fails. Such an approach
would not make economic sense if:
The likelihood of the dominant concept not
working is very low.
The cost of keeping back-up concepts active is
higher than potential savings.
The extra cost of refining a back-up concept
sequentially rather than
concurrently is very low. (i.e. little added system integration expense and delay cost.)
If Dr. Ward is proposing that because the
technique of keeping a broad pool of options active is successful for some subsystems in
the automotive industry, that it then represents a general principle universally
applicable to all subsystems and all systems in all industries, this would, indeed, be a
very ambitious claim. In my experience, though it may be seductive to conclude that there
is one best way to do development, there is no evidence this is true. |
