|
According to the
renowned new product development expert Don Reinertsen, many companies
have a dangerously distorted view of Lean Product Development!
Lean methods have
delivered compelling benefits to many manufacturing processes - large
and simultaneous improvement in quality, cycle time, and efficiency.
Now, engineering managers are increasingly being challenged to apply
these same methods in product development. Yet, product development
expert Don Reinertsen finds that many companies fundamentally
misunderstand the dramatic differences in how these methods create value
in the very different worlds of manufacturing and product development.
He believes these key
misunderstandings are preventing companies from exploiting lean methods
in product development, and even leading some companies to totally
ignore this important new opportunity to improve performance. In
particular, he sees two key misunderstandings that clearly need to be
corrected for many businesses, especially in those in the UK, if they
are to get the real benefits provided by lean methods.
The first key
misunderstanding is on the nature of waste in product development
processes. He explains, “Because the primary focus for much of Lean
Manufacturing is the elimination of wasted expenses, many companies
incorrectly assume that this is also the focus of Lean NPD. This causes
two problems. First, some companies fail to even consider Lean NPD
because they assume it is irrelevant if they have already squeezed out
most of their inefficiencies. Second, other companies purse Lean NPD but
they focus the majority of their efforts on wasted expenses, which is
the most trivial aspect of Lean NPD. Instead, what managers have to
recognize is that real benefits of Lean NPD come from creating flow. It
is only by focusing on flow – not wasted expenses – that they can tap
into the true potential of Lean NPD to simultaneously improve cycle
time, quality and efficiency.”
The second key
misunderstanding is that lean methods should be applied just as they
were in manufacturing. Reinertsen argues that this view is dangerously
misguided, and suggests that in terms of creating flow, manufacturing
offers only a starting point, and not always a good one. He says, “The
Toyota Production System should be recognized for what it is; an
effective method for achieving flow but for a very primitive problem,
that of repetitive manufacturing. For more complex environments, such as
product development, it only offers a starting point of thinking about
flow not the pinnacle of achievement.”
He adds, “Once companies
accept that Lean NPD has to be about creating flow, and recognize the
major differences between Manufacturing and Product Development, then it
becomes obvious that there many other domains that have tackled the
problem of flow in a variable process. These domains are actually a
better source of advanced ideas and methodologies, than the factory
floor.”
Let Development Flow
Reinertsen claims that the
key to achieving flow is reduce the amount in-process inventory at all
levels of design processes. This inventory, which takes the form of
queues, hurts cycle time, efficiency, and quality. That queues increase
cycle time is obvious, but many companies fail to understand how queues
raise costs and increase risk. Costs go up because partially completed
designs are highly perishable. The longer a design remains in process
the more likely it will experience a major change in product
requirements. Risk rises because long flow through times force
developers to plan at longer and riskier time horizons.
Consider, for example, how
faster flow affects feedback in design processes. When flow improves
feedback loops become much tighter – i.e. important information, test
results, answers to key questions are fed back to the development team
much quicker. This, in turn, increases innovation. Engineers and teams
can aggressively try innovative, but risky, solutions, because the speed
of feedback means that they can keep in control the economic
consequences of that risk taking. At the same time, faster feedback
improves efficiency by reducing wasted effort. Any errors are picked up
quickly, so they will not be repeated in other sections of the design.
Even more importantly, companies avoid investing large amounts of effort
on a design foundation that they later discover was in error. If it
takes 30 days to get feedback team members may wait 30 days before
finding they have gone down an unproductive path forcing them to throw
now useless work away.
“Lean NPD deals with
variability in a very different way than Lean Manufacturing. ,” reports
Reinertsen. "Manufacturing treats all variability as bad variability and
strives to reduce the amount of variability. Lean NPD recognizes that we
cannot innovate without introducing uncertainty in outcomes. It
recognizes that the economic cost of variability comes from both the
amount of variability and the economic consequences of this variability.
Whereas manufacturing focuses on variability elimination with programs
like Six Sigma, Lean NPD focuses on ensuring that necessary variability
does the least possible amount of economic damage. "
This difference is
important because variability elimination offers very limited scope for
improvement. It would be virtually impossible to get designers to
achieve an order of magnitude reduction in defects. Even attempting this
would probably result in a dramatic reduction in creativity and
innovation. Instead the flow focused approach recognizes that we can
often achieve order of magnitude reductions in the cost of defects – via
improved flow and feedback.
An Established Example
Is Lean PD really a new
unproven approach to product development? In fact, often without
realizing it, many product developers already exploit the concept that
smaller batch sizes enable more rapid feedback, which creates value by
reducing the cost of mistakes rather than eliminating them. This is
exactly the reason that rapid prototyping is so useful.
“Rapid Prototyping is a
classic example of a technique that fits very cleanly into the framework
of lean based flow,” states Reinertsen. He adds, “However, many people
using this approach have not stepped back to think about why it work.
Because they have not abstracted the mechanism of action, they don't
realize they can use the same ideas and methods in other areas of the
development process.”
If they did, they would
apply flow focused batch size reduction techniques and queue management
principles to other areas, such product definition, project funding,
manufacturing release, and so on. Reinertsen claims that 95% of the
opportunities Lean NPD offers are found in improving flow, and that 5%
are found by searching for wasted expenses.
Looking Beyond
Manufacturing
Once we recognize that the
heart of the problem is flow, not waste, we will observe that there are
numerous domains where very clever people have worried about the problem
of flow for a long time. Many of these domains – from traffic flow, to
the Internet and computer operating systems - have progressed far beyond
the simple methodologies used in manufacturing. Even more importantly,
most of these domains resemble product development in a key aspect that
is absent in manufacturing - they accept that their systems must work in
the presence of high uncertainty.
“If an Internet protocol
engineer looked at the Toyota Production System, he would recognize the
principles used to control flow as a tail-dropping first-in first-out
(FIFO) queue, as system which accepts jobs in sequence, and then stops
whenever the Kanban limit is hit,” notes Reinertsen. He adds, “And, he
would add that this is how we controlled flow on the Internet 20 years
ago.”
What Internet engineers
have long recognized, along with others, is that there are fundamental
issues with FIFO, for certain environments. Certain messages must be
handled with different priorities than others. FIFO works well in
manufacturing where task durations are homogenous and predictable, and
where all jobs have the same cost of delay. It is not optimum in domains
such as Internet communications, computer operating systems and new
product development, where jobs have different costs of delay and are
unpredictable in duration.
Essentially, Reinertsen
reports that when it comes to controlling flow, some of the techniques
that come out domains that have spent decades trying to work with
uncertainty are often more interesting and relevant to NPD, than the
less advanced practices employed in manufacturing.
One example of such a
technique is the round robin approach often applied in computer
operating systems. Instead of servicing different jobs one after the
other, a computer shares capacity across jobs, giving each job a certain
amount of processing time, before moving on to the next and then back
again. This ensures that the shortest jobs get finished quickly and no
one job can block the capacity for an extended period, and create a
queue that destroys the performance of the system. Overall it creates
smoother flow for the majority of projects and only delays the most
difficult jobs, even when the effort involved for any job is completely
unpredictable.
To illustrate how this
concept might be applied in new product development activity, Reinertsen
suggests considering the idea of having a purchasing person work within
each development team on specific team needs for a fixed time period
each day. This ensures that the team will be able to get access to the
purchasing resource within 24 hours and that they will have "head of the
line" privilege during their time slot. It results in fast service times
for their highest priority needs. Such an approach can be used for many
‘design’ support services – centralized units supporting numerous
projects - from specialist CFD work to prototyping.
Obviously, with this
resource sharing approach, the project with unpredictably heavy needs
may get insufficient service. This will be immediately visible as an
increase in work-in-process (WIP) for that project, which occurs
whenever work arrives faster than it is completed. By monitoring WIP the
company immediately knows when an adjustment is required.
The beauty of this
approach is that it eliminates the need to predict in advance exactly
how much ‘specialist’ resource is required by each project, and when it
will be required. We no longer have to continuously reprioritize all the
work that goes into purchasing, or CFD, or prototyping. It also avoids
the long and highly variable processing times that typically occur when
a centralized NPD resource uses a FIFO approach. For example, in a FIFO
approach a single project requiring heavy resources can block the
resource for all other projects. This creates a "convoy effect" similar
to when one slow caravan creates delays for all the cars behind it.
The round robin approach
is even useful when there is some information on priorities. In such
cases work can be divided into priority groups. In product development
these priorities might be based on the relative cost-of-delay for each
project. Each priority group would be allocated a portion of the shared
resource and individual jobs within the priority group would be serviced
on a round robin basis.
“This slightly more
sophisticated approach recognizes high priority projects, but still
shares the allocated resource across them all, so that high cost of
delay jobs with the smallest resource requirement still get through the
queue faster than similar projects with high resource requirements,”
notes Reinertsen.
He concludes, “The fact is
that unlike manufacturing, NPD cannot add value when all variability is
removed. We must design NPD systems so that they work in the presence of
variability. Creating flow in the presence of variability is not a new
problem. We must simply turn to domains where this problem has already
been solved. There are well-proven methods, but, very few of them are to
be found on the factory floor of Toyota.”
|
