| < 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.
|
