An Interview with Don Reinertsen (1/2)
Obsessing About Best Practices and Doing it Right the
First Time Can Hurt YouWhen it comes to conventional wisdom about how to improve product
development processes, Donald Reinertsen has some surprising views. In fact, they
challenge a too-easy acceptance of some of the key ideas promoted in this newsletter. It
may be worth paying attention to him because Don has spent close to twenty years working
with leading development organizations in the world and has done some of the best original
thinking in this field. His 1983 work at McKinsey & Company, quantifying the
value of development cycle time, helped pioneer the cycle-time reduction movement. He
is the co-author (with Preston Smith) of the best-selling Developing Products in Half
the Time (see BPR, 10/97). His most recent book, Managing the Design
Factory: A Product Developer’s Toolkit, explores ways to bring the discipline and
rigor of World Class Manufacturing to product development. In a manner reminiscent of
Deming, he has iconoclastic things to say about some of today’s favorite product
development hobby horses:
PDBPR: In
last month’s newsletter, we interviewed Preston Smith about the new edition of Developing
Products in Half the Time. From the sounds of it, you guys have produced a very
up-to-date toolbox. What’s different about Managing the Design Factory?
DR: "Developing
Products in Half the Time focuses on a vital problem: development speed. Its new
edition is designed to keep it the best book on this subject. At the intellectual heart of
that book is the notion that you must ground decisions about speed in the underlying
economics of the development project. Managing the Design Factory extends this
systematic, economics-based method to other development objectives besides speed. It takes
each of the four fundamental economic objectives, (performance, unit cost, development
expense, and development speed) and shows how you can anchor every management decision on
the underlying economics of a product development program."
PDBPR: Why this book at this time?
DR: "In my experience, companies can get to a certain level of
proficiency in product development by simply imitating practices of other companies that
get good outcomes. It is a bit like trying to build a fast car by selecting the tires from
one fast car, the engine from another. It’s not a bad approach to get a working
system. However, ultimately you discover that individually-optimum components cannot be
assembled into an optimum system. Then you return to fundamentals and engineer the system
as a system.
"This is the key lesson of system design, one we’ve learned in both product
design and manufacturing system design. For some curious reason it has not been
transferred to development process design. Instead, we still incorrectly assume that we
can create an optimum development process by assembling
together a bunch of individual ‘best practices’.
"The new book tries to take a more deliberate approach to development process design.
It views it as a system design problem and tries to highlight why we might make different
choices in different situations. It is designed for people who are starting to discover
the limitations of conventional approaches. It’s reassuring that the people reacting
most strongly to the book in the early reviews are from companies like Hewlett-Packard,
Motorola, and Sun Microsystems—those already at the leading edge of
product development."
PDBPR: Why did you call it Managing the Design Factory?
DR: "An important idea developed in the book is that we are managing
our development processes the way that we used to manage our factories 50 years ago.
Just-in-Time (JIT) manufacturing reflects a true systems approach to the design of
manufacturing processes. Unfortunately, little of the deeper learning of JIT has been
transferred into our development process design. For example, most development processes
have excessively large batch size, overspecialized sub-processes, massive inventory, and
slow learning cycles. Since the factory is a key area in which we have transformed our
thinking, I
consider it an excellent role model for what we have the potential to do in product
development.
"Nonetheless, there are some subtleties in transferring these World Class
Manufacturing techniques into the product development arena. Product development is truly
different than manufacturing in certain critical ways. For example, manufacturing is a
repetitive process with relatively low variability. Product development is a
non-repetitive process with high variability. This means we cannot bring rational
management to product development by using the deterministic math that works so well in
manufacturing. Instead, we must use the math of stochastic processes, such as queuing
theory and information theory.
"What is important about this is that when
you use the right math you reach strikingly different conclusions about how to manage the
process. For example, deterministic math says your development process can be loaded to
100 percent utilization before you will experience delays. In contrast, queueing theory
says you will experience massive delays in your projects if you try to load your
organization close to 100 percent utilization."
PDBPR: What are the practical implications of this?
DR: "Queueing theory gives you a much more rigorous way to look at
the issue of capacity utilization. For example, you discover that there is no possible way
to avoid queues in product development without excess capacity in the process. Even the
most brilliant forecasting and planning cannot prevent queues, as long as you insist on
utilizing 100 percent of capacity.
"When you understand this, you see that idle time in development is not
‘waste’, but rather a tool that prevents your resources from being blocked 100
percent of the time. This gives you insight as to why a company like 3M builds 15 percent
excess capacity into their development process. Do you really think they do it because
they like ‘waste’? They say it helps make them more ‘innovative’.
"I would argue that this excess capacity has a dramatic effect on process queues and
cycle time, and that finishing early is usually the difference between being the
‘innovator’ and being the ‘imitator’. Now, 3M may not understand
queueing theory—they may just be doing what they observed works. But, queueing theory
gives you the ability to assess what level of excess capacity is right for your own
process—instead of assuming that 3M’s 15 percent is a universal truth."
PDBPR: You make the radical proposal that there are no best practices. What
do you mean?
DR: "I am against the notion of ‘best practices’ because
it implies that there is a single best way of doing anything. Embedded in the idea is the
tacit assumption that following the ‘best practice’ always results in the
‘best outcome’. Since I have never met a really experienced manager who believed
this was true, I am not sure I am really being very radical. I simply believe that all
practices are ‘tools’ that are useful to achieve certain objectives in certain
contexts.
"For example, consider sequential development versus concurrent development. Neither
can truly be called a best practice. A concurrent process is very well-suited to achieve
development speed. A sequential process is generally better at minimizing risk and
controlling development expenses. Each is ‘best’ to achieve a certain objective.
The same is true for functional organizations versus teams. A functional organization is
an excellent tool to keep development expenses low. Teams are well-suited for
rapid development, especially when they are adequately manned. Again, neither is a
universal best practice.
"The great danger in labeling something a ‘best practice’ is that you
cannot be against it. People stop thinking as soon as something is labeled as a
‘best’. Such mindless behavior is dangerous in a complex world. I am
simply arguing for a more thoughtful approach to development process design."
PDBPR: Waste in the design process: where are the high-leverage
opportunities for improvement? Where do I begin to do my homework?
DR: "‘Waste’ is another one of those emotionally charged
words that suspend thought. Which of your readers would be in favor of ‘waste’?
We all know the mantras. Waste is bad, efficiency is good. Fat is bad, lean is good. A
seductive but stupid way to think about product development. The real problem is that most
people focus narrowly on expenses when they think about waste.
"Let me give you a simple example. Let us say a medical products company wants to be
‘efficient’ in their product development and ‘eliminate waste’. They
notice that their Regulatory Affairs team member prepares a submission package early in
the design process, but redoes it when Engineering changes
the design. Surely it is wasteful to do the same paperwork four times in the design
process, when only one time is necessary for submission. Let us eliminate this
‘waste’ by involving the Regulatory Affairs person later in the design process,
when the design will no longer change.
"What are the consequences? Regulatory is now on the critical path of the program,
when previously most of their work took place off the critical path, so we pay the cost of
time on the critical path. Furthermore, they are identifying design changes late in the
development process when it costs 100 times more money to make the changes. The
‘efficiency’ of the regulatory affairs person is costing us many times its
savings by its impact on costs and cycle time. The point is that we need to see
development as a system and try to optimize overall outcomes. Therefore, the place to
start is always by understanding the overall economics."
Part II >
This article originally appeared in the November
1997 issue of PDBPR
 To join our
e-mail list and receive future updates on "Fast & Flexible" techniques, click here.
|
