| <
Part I
An Interview with
Don Reinertsen (2/2)
Applying Batch Size to Product
Development: Unconventional Wisdom about Speed and
Flexibility - Part 2
 PDBPR:
Last month, in the
first part of this interview, we were speaking about how
"smaller batch" transfers of product development
information can create feedback that increases
efficiency in the process. But some observers feel that
this raises the risk of late changes in development
projects, while the conventional wisdom says that late
changes are always bad. Why do you believe that late
changes might make sense in some
cases?
Reinertsen: Our belief
that late changes are always bad arises from a natural
tendency to look at the wrong data related to the cost
of late changes. When someone asks developers, "Why
were you late?" they instinctively point to external
causes, saying, for example, "The project was late
because of rework that occurred when marketing changed
the requirements." When we are only provided with
examples of painful, late changes, we naturally conclude
that all late changes are painful.
Unfortunately, this data set
excludes the late changes that took place at low cost
and those that actually added more value than cost. Yet,
these changes are some of the most instructive examples
of all. For example, consider the choice to drop a
troublesome but marginally useful feature. The expense
and cycle-time savings of this change may far exceed the
damage caused by deleting a minor feature. Thus, we can
only understand the impact of late changes when we
consider the full economic context.
PDBPR: Can you give an example of a business that
derives an advantage from late
changes?
Reinertsen: One of my
favorite examples is the newspaper business. Over the
years they have evolved a very sophisticated process to
maximize the economic benefit of late changes. They
lower the cost of change by isolating late changes to a
small portion of the paper. A newspaper is divided into
"live" pages and "dead" pages. Only the live pages are
changed late in the process. Within these live pages are
zones called the "news hole." Late breaking news is
dropped into these well-defined zones. As result, the
front page – which is the page that is most visible to
customers – can have news that is only hours old. Even
the structure of the articles is designed to support the
process. The pyramid form, in which newspaper articles
are written, is designed so that you can cut an article
to size without losing any critical content. Newspapers
don’t say, "It’s expensive to make changes late in
the process, so we need to freeze everything early."
Rather, they recognize the enormous value in having the
capability to modify their product late in the
process. Their entire process, and product, has been
deliberately structured to enable them to make late
changes cost effectively.
In contrast, most product
developers assume that the only way to reduce the cost
of late changes is to completely eliminate them. While
this reduces cost, it also has the unfortunate side
effect of simultaneously eliminating the value of
late changes. In effect, most developers are
striving to create a process where there is no important
problem solving taking place during the last 80 percent
of the product development process. As a result, they
fail to capitalize on all the useful new information
that becomes available as to the preferences of
customers and the economics of their design. Rather than
insulating ourselves from late changes, I would prefer
to ask the question: What would we need to do to make
it cheaper to make changes late in the process? How can
we structure a process in such a way that we can capture
the benefit of late changes without incurring massive
amounts of cost?
PDBPR:
And this relates to what you have
said about the importance of product architecture in
enabling late changes to be made cost
effectively.
Reinertsen: Yes,
product architecture is a critical enabler. Expensive
changes frequently arise because subsystems are coupled
together too tightly. In such cases, a change in one
subsystem triggers changes in many other places. If you
provide adequate safety margin at the interfaces between
subsystems, you will buffer the effect of the initial
change. The amount of rework associated with a change
can be dramatically reduced.
PDBPR: You suggest that there is no
one-size-fits-all product development process that works
for all projects, in all cases. But companies need to
have some type of process that ensures a modicum of
predictability in product development. In a product
development process, how can we provide structure while
still preserving flexibility?
Reinertsen: The
problem here is the tendency to assume that development
process design is about standardizing the top level of
the process architecture. Developers try to derive
universal task lists and universal task sequences that
meet the needs of every product. I’d argue that such a
process is inherently sub-optimum for every product they
develop. Instead, they should standardize at a lower
level in the process architecture –
standardize the underlying building blocks of the
product development process, not the top level of the
process. Give people the flexibility to wire these
building blocks together in different ways that provide
the best natural sequence for an individual program. For
example, if I’m re-packaging an existing technology, I
don’t need to prototype the technology to check
feasibility. On the other hand, if I’m trying to
introduce a brand new technology in one particular
subsystem of the design, then I need to prototype that
particular subsystem early to prove that it works.
Whether I need to prototype and what scope
that prototype should have, will vary from one project
to another. When I do it and how detailed
I have to make it, can vary – the process of how I
create a prototype can still be defined.
For example, when I am
building a prototype to establish feasibility, I can
define the following tasks: a) I must define the test I
need to use to determine whether that prototype is
functioning or not; b) I need to establish a controlled
test protocol so I know what test I actually ran; c) I
need to establish pass/fail criteria, before I
run the test not after I see the results; d) I
need to reserve time in the test lab; e) I need to
reserve time in the assembly area to have someone
assemble my prototype; f) I need to produce a Bill of
Materials, identifying what parts are going to be
assembled, and g) I need to have an assembly drawing,
etc. The procedure can be standardized, but, again,
when you do it, within the process, and
whether you do it, is where you can offer
yourself flexibility.
PDBPR: Isn’t it the case that the
more "modular" approach that you’re suggesting is a
better reflection of how people actually develop new
products?
Reinertsen: Yes, to
some extent all I’m saying is this: document your
procedure to reflect what you’re actually doing,
today. People do not actually refer to their
development process and say, "Let me draw a
development plan that fits this development
process." What they actually do is pull out the PERT
chart of the last program that most resembles the new
one, and then they modify the old PERT chart in a way
that makes specific sense for the new program. Their
procedure says to use all of the activities, on every
program, in the same sequence, but they don’t do this.
You can check 20 PERT charts from past programs and you
will see that they don’t use all of their activities,
and they never use them in the same sequence. So, why
not simply write the procedure so that you’re permitted
to use only the activities that add value? Why not allow
people to perform these activities in a sequence that
makes logical, natural sense for that particular
program? Then you wouldn’t have confused product
developers who say, "This is the procedure, but let
me tell you what we really do!"
Developers can never get
there by trying to standardize the top-level process
map. If top-level process is standardized it is not
optimized, and if it is optimized it is not
standardized. You can only make headway when you begin
to focus on the underlying building blocks. By focusing
on the right level of the process we can create
disciplined development processes that are also
flexible development
processes.
This article originally appeared in the June
2003 issue of PDBPR
 To join our e-mail list and
receive future updates on "Lean Product Development, click
here.
| 
ABOUT DON
REINERTSEN