Innovation at the Speed

of Information
by Steven D. Eppinger

Reprint r0101l
 January 2001

HBR Case Study r0101a

Who Goes, Who Stays?
David A. Light
First Person r0101b
The Ultimate Creativity Machine:
How BMW Turns Art into Profit
Chris Bangle
HBR at Large r0101c
Tocqueville Revisited: The Meaning
of American Prosperity
Charles Handy

Level 5 Leadership: The Triumph of r0101d

Humility and Fierce Resolve
Jim Collins
Where Value Lives in a Networked World r0101e
Mohanbir Sawhney and Deval Parikh
The Ten Deadly Mistakes of Wanna-Dots r0101f
Rosabeth Moss Kanter
Strategy as Simple Rules r0101g
Kathleen M. Eisenhardt and Donald N. Sull
The Making of a Corporate Athlete r0101h
Jim Loehr and Tony Schwartz
HBR Interview r0101j
Managing for the Next Big Thing:
EMC’s Michael Ruettgers
Paul Hemp

Best Practice r0101k

Getting 360-Degree Feedback Right
Maury A. Peiperl
Tool Kit r0101l
Innovation at the Speed of Information
Steven D. Eppinger
Different Voice r0101m
What Is Science Good For?
A Conversation with Richard Dawkins
Books in Review r0101n
Should Strategy Makers Become
Dream Weavers?
John Stopford
 To o l K i t

Innovation
at the S p e e d o f

Information
by Steven D. Eppinger

Developing a new product involves trial and

error, but beyond a certain point, redesign
becomes wasteful. A practical and proven
tool, the Design Structure Matrix, can help
T he exchange of information
is the lifeblood of product develop-
ment. When an electronics company’s
circuit designers know what the casing
streamline the way a company innovates. designers are doing, they design a better-
fitting circuit for the casing. And when
the casing designers know what the
circuit designers need, they design a
casing where it’s easier to put in a better
circuit. Such flows of information allow
for experimentation and innovation,
and for that reason, many companies
encourage feedback and iteration in
their product development processes.
This practice is known as concurrent
engineering.
But excessive iteration can have draw-
backs. A continual back-and-forth of
work inevitably consumes time and re-
sources. And many of the iterations may
turn out to be only marginally benefi-
cial or even wasteful. For example, at a
telecommunications company that my
colleagues and I advised, there were as

Copyright © 2001 Harvard Business School Publishing Corporation. All rights reserved. 3
T O O L K I T • I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n

many as 20 regular iterations among change, the complete organization of

sequence. You can’t frame the walls
the teams working on two key technical such a process with a conventional
until you’ve built the foundation. You
specifications. The result was that few project-management tool. In addition,
can’t put on the roof until you’ve built
people worked carefully on specifica- by their nature, high-tech product-
the walls. Sequential tasks, by definition,
tions in the early stages, because every- development processes usually involve
rely on information generated by ear-
one knew that extensive rework would many interwoven tasks. lier tasks. Other tasks, called parallel
occur down the line. There is, however, a tool that man-
tasks, can be carried out simultaneously.
The lesson is clear. Iteration must be agers can use to obtain a simple and
You can install windows, run wires, and
carefully planned and managed. Good meaningful representation of such com-
lay plumbing at the same time. These
iteration should be encouraged and bad plex processes. This tool, the Design
three jobs need walls, but none needs
iteration eliminated. To do that, man- Structure Matrix (DSM), differs funda-
the other two. Neither sequential nor
agers need representational tools to mentally from conventional project-
parallel tasks will need to be reworked
help them identify and model iteration. management tools in that it focuses on
as a result of subsequent tasks. You don’t
change the foundation after
The Design Structure Matrix differs from conventional project- building the walls. You don’t
rewire as a result of the win-
management tools in that it focuses on representing information
dow glazing.
flows rather than work flows. Thus, it is better able to depict the Product development is
key dynamic of innovation processes. very different. It requires in-
novation, and innovation re-
Unfortunately, the standard project- representing the information flows of quires complex learning (feedback)
management tool kits such as Microsoft a project rather than the work flows. loops. You repeat prior tasks as you
Project don’t contain such tools. The As a result, it is better able to depict the learn from subsequent ones. Interde-
most commonly used project-planning key dynamic of innovation processes pendent tasks that benefit each other
tools – principally PERT and CPM net- such as product development. What’s in this way are known as coupled tasks.
work diagrams – are graphic descrip- more, it can often provide representa- If you want to come up with a better
tions of task flows. In them, tasks are usu- tions of complex development processes foundation for future houses, you might
ally represented by boxes or circles, and on a single page. In this article, we will rework a foundation after building the
sequencing is represented by arrows. explain how the DSM works and show walls. The information from such an it-
In a complex project, a chart can run how a manager can use it to make de- eration is precisely what helps you find
to tens or even hundreds of pages, and velopment processes more efficient. the improvement, and the presence of
each page accommodates only so many First, though, let’s explore why product coupled tasks is what distinguishes in-
readable circles and arrows. A boxes- development needs a fundamentally novation processes such as product de-
and-arrows depiction of the design pro- different planning tool. velopment from construction projects.
cess for a car’s suspension, for example, Conventional tools answer the ques-
would run to more than 30 pages. If the Product Development tion, “What other tasks must be com-
project is made up of tasks that can be Is About Information, pleted before I begin this one?” But the
completed in sequence without fear of Not Tasks planners of a product development pro-
rework, manageable charts for small PERT charts, Gantt charts, and other cess need a tool that answers a very dif-
chunks of work can be generated. common scheduling tools were created ferent question: “What information do
But the tools become very hard to use to help managers plan large construc- I need from other tasks before I can
if what happens on page 60 forces you tion projects such as building ships or complete this one?”This is the question
to rework a task on page 18, and, thus, factories. Although these projects can be the Design Structure Matrix addresses.
many of the subsequent tasks down to complex, involving hundreds of differ-
page 60 again. It is almost impossible ent tasks or more, the planning princi- Drawing the DSM
for managers to comprehend, let alone ples are fairly simple: you decide where Constructing a DSM of your company’s
and when tasks should be carried out. existing product-development process
Steven D. Eppinger is the General Motors No matter how complicated, all con- is a relatively straightforward, if some-
Leaders for Manufacturing Associate struction projects can be thought of as times time-consuming, process. The first
Professor of Management Science and a sequence of discrete tasks, many of step, identifying the tasks involved, is
Engineering Systems at MIT’s Sloan which can be conducted simultaneously easy and is often available as part of the
School of Management in Cambridge, but none of which should need rework- project-management documentation.
Massachusetts. He is also codirector of ing as a result of later information. Companies with an established devel-
MIT’s Center for Innovation in Product Imagine you are building a house. opment process already know the tasks
Development. Some tasks have to be completed in needed to develop a new product. Ford,

4 harvard business review


for example, executes largely the same
process each time it develops a new car
engine.
What takes time is correctly identify-
ing the information needs of the various
tasks. You cannot rely on what your
company’s managers tell you: they are
usually not the people doing the work,
and they may have an interest in justi-
fying existing or outdated processes.
When we draw a DSM for a product de-
velopment process, we go to the grass
roots and ask individual development
teams what they need from other teams
to do their jobs. It’s important to focus
on input rather than output because we
have found that managers, engineers,
and other product-development profes-
sionals are more accurate in identifying
what they need to know than in de-
scribing what others need to know.
Once you have all this information,
you are ready to draw the project’s
DSM. First, list all the tasks in the order
in which they are presently carried out.
Arrange them in the same order hori-
zontally and vertically to form a matrix
of rows and columns. Across each row
corresponding to a task, mark off the
other tasks that supply necessary infor-
mation. In other words, looking across
a row shows you all the information in-
puts you need to complete a task, and
looking down a column shows you all
the information outputs you’ll provide
to other tasks. Consider the simplified
DSM shown below. Reading along row
A B C D E F G H I J
A •
B X • X X
C X • your organization has planned for these
D X X •
E X X • X X to accommodate them as efficiently as
F X • possible. Our second example, below,
G X • X
H X X • X X
I X X X X X •
J X X X X X •
B tells you that task B needs informa-
tion from tasks A, G, and J. Reading
down column B tells you that task B sup-
plies information for tasks E, H, and J.
january 2001
I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n • T O O L K I T
What the DSM Can Tell You
A DSM of your development process
provides a useful reality check. First, it
clearly reveals which information ex-
changes involve design iteration and
which do not. In the example just pre-
sented, note the diagonal formed by the
dots that divide our matrix. All the X’s
below the diagonal denote feedforward
information exchanges in which infor-
mation from earlier tasks is available
for later tasks. But an X in the upper
half denotes feedback in which infor-
mation from a subsequent task may force
a reworking of a prior task. These are
the coupled tasks. Task B, for instance,
needs information from task G, which
is carried out long after B. Executing B
requires making a guess about or as-
suming the missing information from
G. When complete and accurate infor-
mation from task G is finally available,
a reworking of task B may be necessary.
Then the development process has to
begin again from B onward, with inter-
vening tasks also being repeated to re-
flect the change to B’s output.
A DSM can also help you to see how
well your development process is an-
ticipating the need for rework. Here’s
how. On the DSM, you simply draw
boxes around the tasks that your com-
pany performs concurrently, that is,
interdependently. These are your com-
pany’s planned iterations, the tasks
your company recognizes as repeating
and therefore organizes so as to facili-
tate and speed the flow of information
among them. If all the X’s above the
diagonal are captured within the boxes,
iterations and has arranged its process
shows that tasks E through I are done
concurrently. However, the company
has failed to prepare for a fair number
of potential iterations: there are still
four feedback marks (now represented
by O’s) above the diagonal and outside
of the boxed tasks. These are unplanned
iterations.
In practice, of course, successful prod-
uct developers are good at recognizing
A B C D E F G H I J
A •
B X • O O
C X •
D X X •
E X X • X X
F X •
G X • O
H X X • X O
I X X X X X •
J X X X X X •
X information flows
planned iterations
O unplanned iterations
potential iterations, and their DSMs will
usually reveal a fairly efficient flow of
information. But some companies find
that this exercise reveals muddled pro-
cesses. The telecommunications com-
pany whose development process for
data services is depicted in the chart
“Chaotic Development in Telecommu-
nications” is a case in point. The com-
pany’s engineers had long been frus-
trated by the time and energy it took to
develop new services, but it wasn’t until
they saw a DSM that they realized just
how many feedback loops were built
into their process.
Optimizing
Information Flows
The DSM is a powerful resource for or-
ganizations like the telecom company
because it helps managers not only
identify problems but also see how to fix
them. Below, we examine four ways to
improve a company’s information flows.
Rearrange the sequence of tasks.
The first step in streamlining a product
development process is to determine
whether a different sequence of tasks
will reduce the number of feedback
marks. This involves rearranging the
rows of the DSM, a process that Boeing
executives call “eliminating out-of-
sequence rework.” The objective is to
move as many X’s as possible from
above the diagonal to below it.
You begin by identifying candidates
for the earliest and the latest tasks. Ide-
ally, the first task would require no in-
puts at all, indicating that it would never
5
T O O L K I T • I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n

need to be reworked. Refer- back to the second DSM, which shows

ring to the two previous A C D F B J G E I H the tasks that the hypothetical company
DSMs, task A, therefore, sequential A • actually carries out concurrently. Task E
stays first. Task C comes tasks C X • is grouped with I, but tasks B, J, and G
next because it needs infor- parallel D X X • do not fall within the initial grouping of
mation only from A; these tasks F X • concurrent tasks; as a result, iterations
are sequential tasks. Then, B X • X X involving B, J, and G require many more
coupled
we select tasks D and F to tasks J X X X X X • tasks in the original process. Clearly, this
come next because they G X X • company needs to rethink which tasks
require information only coupled E X X X • X are put together with which others.
from A and C. Note that tasks I X X X X X • Keeping interdependent tasks sepa-
D and F require no infor- H X X X X • rate can cause considerable waste, and
mation from each other, so this is where grouping tasks differently
they can be carried out in can really help to speed along the pro-
parallel, which we denote by a dashed- For a simple DSM like the one here, cess. One electronics company we ad-
line box in our third example. it’s fairly easy to identify by trial and vised found that it was performing a
Similarly, the ideal last task would not error the task ordering and coupling set of tightly coupled tasks in two dif-
produce any information required by that minimize the number of informa- ferent countries. When the teams were
other tasks (in other words, its column tion feedbacks above the diagonal. In
would be blank). Here, that’s task H, the case of more complicated DSMs, A DSM clearly reveals which
which becomes the last task in the though, you will need to apply a sys- information exchanges involve
project. tematic approach involving the use of design iteration and which
When you can no longer find any computer-based algorithms.
do not. It can also help you to
tasks to schedule early or late, you must Revisit task organization. Having
see how well your development
then group the remaining tasks into rearranged the order of tasks, you
blocks, bringing the X’s closer to the di- should now reconsider their organiza-
process is anticipating the
agonal. In our example, the most effec- tion. Look again at the two blocks of need for rework.
tive sequence shows two blocks of cou- coupled tasks shown in the third DSM,
pled tasks: B, J, and G must be executed above. In principle, the tasks within each briefly located together, they were able
together, as must tasks E and I. This set should be carried out at the same to complete the coupled tasks in just
DSM plans for all iterations. time and in the same place. But look two weeks, thereby allowing other work
to proceed using their results.
Reduce information exchanges. Re-
sequencing the matrix, though, will only
Chaotic Development in Telecommunications get you partway to an efficient develop-
ment process. The next step is to reduce
the number of information exchanges
Drawing a DSM of the development process for this company’s by changing the content of some of the
data services immediately revealed the degree of unplanned tasks. Because the importance and na-
iteration. Iterations within the phases were built into the process ture of information exchanges between
(the shaded boxes), but unplanned iterations across the phases tasks can differ considerably, it is usu-
(the O’s) were the reality. ally possible to break down coupled
tasks into smaller sets by changing task
A B C D E F G H I J specifications. Although this can mean
concept A • increasing the number of tasks and peo-
business requirements B X • O O O ple, the reduction in the number of
planning system requirements C X X • O O information flows – and thus in poten-
phase network plan D X X • X O O tial iterations – more than compensates
technical specifications E X X X • O O for these investments. The executives
engineering design F X X X • at an aerospace firm we have worked
implementation billing implementation G X X X • X with, for instance, believe that this ex-
phase operations engineering H • X
X X X X ercise helped them to reduce the num-
customer service I X X X X • ber of potential iterations in the com-
launch J X X X X • pany’s development processes by as
much as 50%.

6 harvard business review

 I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n • T O O L K I T

Here are three ways to reduce the
need to exchange information. First, you
can transfer key knowledge between
teams. In some cases, a company can
decouple one task from another simply
by adding to each team someone with
expertise in the other task. These people
must be sufficiently knowledgeable to
supply information that would other-
wise have been exchanged in one or
more iterations between teams.
A similar effect can be achieved by
using information technology. Com-
puter-aided engineering software, for
example, allows design teams to predict
the implications of their designs on each
other, again obviating the need for a di-
rect exchange of information. A plastic-
parts designer at a manufacturer of cell
phones can use mold-flow simulation
software to foresee production prob-
lems arising from her design. In this
way, she can anticipate feedback from
the mold-tooling experts that would
otherwise force her to go back to the
drawing board weeks later.
Second, you can introduce a new task
earlier in the process so as to simplify
subsequent, time-intensive iterations
performed by interdependent teams.
The new task typically requires early
tion exchange within a group by add-
ing an extra task or two to intervene
between existing tasks in the group. To
see how this can be done, it’s instruc-
tive to compare how two suppliers de-
sign the same dashboard component,
a speedometer cluster for General Mo-
tors. (See the chart “Reducing Informa-
tion Exchange by Decoupling Tasks.”)
A coupled process encourages iterations and the
search for creative solutions. But sometimes speed is
more important than innovation.
Supplier A adopts a concurrent engi-
neering process, carrying out three tasks
(casing design, wiring layout, and light-
ing details) at once, with three task
teams working in close proximity. The
three teams go through a number of
iterations and take a relatively long time
to finalize their plans, but the end result
is a fairly advanced prototype. However,
if the testing phase reveals problems,
Reducing Information Exchange
by Decoupling Tasks
up to four steps of the process can be
affected, and much of the process may
have to be repeated (see O’s in the left
side of the exhibit).
Supplier B takes a different approach,
reducing the coupled tasks to just two:
casing design and lighting details. A
wiring circuit is worked out based on
output from the first two tasks, and
the speedometer is then crudely proto-
typed. Once the prototype has been
tested, wiring revisions are made to
produce the final design. Although it
involves an extra task – revising the wir-
ing – in fact, this process is faster than
the first because there is much less iter-
ation between two task teams than
among three. The extra step also antici-
pates and allows for changes to the pro-

Keeping interdependent tasks Supplier A has three teams that carry out their tasks concurrently. After a number
separate can cause considerable of iterations, a fairly advanced prototype is developed and tested. But if problems
waste, and this is where grouping arise during the testing phase, up to four steps of the engineering process can be
tasks differently can speed along affected (see O’s).
the development process. Supplier B couples only two tasks and creates a wiring circuit based on
output from them. A soft prototype is built and tested, and an additional task
agreement about aspects common to of wiring revision is introduced. However, this process is faster than Supplier A’s
the coupled tasks. The addition of a new because less iteration occurs between the two initial task teams, and the extra
task, carried out by representatives of step of planned iteration virtually eliminates unplanned iteration.
the coupled teams, can break down
some of the iterations. For example, two
teams designing coupled parts – say, an Supplier A Supplier B
electronic control circuit and its user- Highly innovative, but slow Fast, but less innovative
interface keypad – can agree in advance
on the locations of the attachment A B C D E F A B C D E F G
points and microswitches. This interface casing design A • X X O casing design A • X
specification allows the circuit-design wiring layout B X • X O lighting details B X •
lighting details C X X • O wiring layout C X X •
team and the keypad team to proceed
tooling D X X X • O soft prototype D X X X •
in parallel. hard prototype E X • testing E X •
Third, you can redefine tasks within testing F X • revision F X •
coupled groups. Another way to reduce hard tooling G X X X X X •
iterations is to eliminate an informa-

january 2001 7
T O O L K I T • I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n
totype, and planned iterations virtually
eliminate unplanned ones.
In general, any decision to decouple
a task (in this case, wiring) depends on
how the company views the trade-off
between speed and quality. A coupled
process encourages iterations and the
search for creative solutions and thus
is more likely to produce a significant
improvement in the quality of the prod-
uct being developed. But sometimes
speed is more important than innova-
tion. Then, a faster, less coupled process
is preferable.
Manage unplannable rework. So
far, most of our discussion has focused
on relatively small and easily managed
processes. In our theoretical example,
for instance, it was possible to optimize
a process so that all of the X’s were
moved close to or below the diagonal.
All coupled tasks could be carried out
concurrently, so all iterations could be
planned for.
In real life, however, product devel-
opment is a large and complicated pro-
cess. It is rare that a company will be
able to design a process in which all cou-
pled tasks can be carried out together.
There will generally be tasks that can
only be conducted later in the process
but that provide information for tasks
completed months earlier.
Consider Intel, one of the most con-
sistently successful product developers
and a company that regularly leads the
way in developing the next generation of
microprocessors. The product develop-
ment process for semiconductor chips at
Intel consists of 60 distinct tasks, and
the DSM is shown in the chart “Semi-
conductor Development at Intel.” Above
the diagonal, the X’s denote planned
information exchanges, and the O’s sig-
nify unplanned iterations.
As the boxed areas on the DSM re-
veal, Intel groups most of the tasks into
15 concurrently managed stages. Some
of the stages overlap, that is, some of
the tasks in one group are also included
in the next. As you might expect, there
is little incentive for a highly successful
company like Intel to improve its tried,
trusted process through rearranging and
reorganizing its tasks. Equally, there is
8 harvard business review
Improving Communication at
General Motors’ Powertrain Division
Within the Powertrain Division
of General Motors, we used an inter-
esting variant of the DSM to im-
prove communication during en-
gine development. The company
had organized its 22 engine product-
development teams (PDTs) into four
system teams, each dealing with one
of the four engine subsystems: the
short block, the valve train, the in-
duction system, and the emissions
and electrical system. We suspected,
however, that this organization did
not adequately accommodate the
communication needs of all PDTs.
To check out our hypothesis, we
surveyed each of the 22 PDTs about
its communication with other
teams, asking each to describe how
often it needed to meet with other
teams. From these data, we drew a
DSM to describe those communica-
tions. Instead of marking each inter-
action with an X, we used three sym-
bols to reflect the varying frequency
of team interactions: a large circle
for daily communication, a midsize
circle for weekly meetings, and a
small dot for monthly conferences.
The results are shown in the chart
“Organizing Communication at GM
PT: Before.” The boxes show which
tasks were coupled in GM’s original
structure of system teams.
The DSM revealed that GM’s exist-
ing organization was indeed flawed.
In addition to the regular interac-
tions by the PDTs within the four
system teams, PDTs also had exten-
sive and frequent contacts outside
their designated groups. The engine
block PDT, for example, which be-
longed to the short block system
team, also had daily meetings with
members of all three teams in the
valve train system team, one team in
the induction system team, and two
teams in the emissions and electri-
cal system team. These communica-
tions were entirely outside of any
formal process, and their organiza-
tion was left to the people involved.
In many cases, the interactions sim-
ply didn’t occur and, thus, informa-
tion was not transferred.
To see how GM could improve the
organization of its teams, we applied
a special kind of clustering analysis
to the DSM. First, we identified the
PDTs with communication needs
across the entire development orga-
nization and moved their rows to
the bottom of the matrix. We then
grouped the other teams into four
new system teams so as to capture
most of their daily and weekly
meeting needs. The results are
shown in the chart “Organizing
Communication at GM PT: After.”
The new DSM demonstrated to
GM that it needed to introduce a
different type of organization. For
a start, while many PDTs could
be assigned to one system team
encompassing their principal inter-
actions, a certain amount of cross-
membership was required. Some
PDTs–pistons, for example–were
assigned to two system teams. Two
PDTs, cylinder heads (G) and intake
manifold (J), were assigned to three
system teams. (For visual clarity in
the new matrix, these teams appear
as G1 and G2 and J1 and J2, respec-
tively.) The boxed groups on the re-
configured matrix denote the four
new overlapping system teams that
GM created.
 I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n • T O O L K I T

Organizing Communication at GM PT
But the greatest challenge facing
GM was how to organize the five
PDTs at the bottom of the matrix, Before…
whose systemwide communication
A B C D E F G H I J K L M N OP Q R S T U V
needs could not be met within the
• • • •• • •• • • • •
structure of a system team. The solu-
engine block
crankshaft
A A
B B
• •
• • •
•
•
• •• • •• •
•

••
short block flywheel C • C • • •
tion we worked out with GM was to system team pistons D • • D• • • • • •• •• •
group these teams into a special connecting rods
lubrication
E •
F • • •
E • •
• • • • F • •
•
•• • • • •
“system integration team” whose valve train cylinder heads G • ••• • G •••• •• • • • •• • •

responsibility was to ensure the system team

camshaft / valve train
water pump/cooling
H
I
•
•
• • H• • •
• • • •• • • • • • • ••
• • • I • • • • •
• •
•
overall integration of work by the intake manifold
fuel system
J
K
• • • •
J • •
• • K• • • • • • • • •
four system teams so that the engine induction accessory drive L • • • • • • • • M •• • •
L • • • • • • •

being developed would meet the

system team air cleaner
AIR
M
N • •
•
•
• •
• •
•N •
•
• • • • •
required performance standards. throttle body O • ••• •• O •• • • • •

The system integration team met

exhaust
EGR
P
Q
•
•
•• •
• • •
•
• • •Q •• ••
P • •
• •
•
• • •
•
•
emissions and
its communication needs by leading electrical
EVAP R •
• • R • •

system team
ignition
ECM
S
T
• •• •
• •
• • • • •• •• • • • • • • •S •T •• ••
•
• • •
•
•
•
•
•
monthly program meetings at which
everyone discussed issues related
electrical system
engine assembly
U
V
•• • •• • • •• • •• • • •• • • • •• • •• •• U• •V
• • • • • • • • •
•

to overall product performance.

frequency of team interactions

• daily • weekly • monthly

These DSMs use symbols of varying size to

reflect the frequency of team interactions. …and After
The boxes show which product develop- B C E D F A H G1 J1 I K M O R G2 J2 N P Q L S T U V
ment teams (PDTs) are grouped together
•• • • •• • •
crankshaft B B • • • • • • •
into system teams. In the “before” DSM, team 1 flywheel C C • • • •
connecting rods E E • • • • •
we see that many PDTs had frequent pistons D • • • D • •• •
• • • • •
•
• • • •••
lubrication F • • • • F • • • • • • •
contacts outside their designated groups. team 2
engine block
camshaft / valve train
A
H •
•• • • • • •• •
•
• •
A
H
•
• •
• •
• •
The reorganization first isolated cylinder heads G1 • • • •• ••
G1 • •• • • •

• •• • •• ••
intake manifold J1 • • • J1
the PDTs with communication needs water pump/cooling I • • • • I • • • • •

across the whole organization and then fuel system K • K • • • •

• • • •
•
• •
team 3 air cleaner
throttle body
M
O
• M • ••
•
• • •O• • • •
•
• • • • •
regrouped the remaining PDTs into new
EVAP R • •R • • •
system teams so that most daily and cylinder heads G2 • G2 • • • • ••
• • •

weekly meeting needs would be met. team 4

intake manifold
AIR
J2
N •
• •• • • •• J2• N• •• • •• • •• ••
• • • •
exhaust P • • • •• •• • P• Q• • • ••
• • • •
The “after” DSM shows the four new EGR Q • • • •
• • • • • •

overlapping teams as well as the system accessory drive

ignition
L
S
•
•• • • ••
• •
• ••
• •• •••• • L
• •
•
• • • • •• • • • •• • • • • S T• • ••
• •
• • •

integration
integration team that communicated ECM T •
•••
••
• • • •
• U•
• • •

• • • • • • • • • • • • • • • •• • • •• •• • V•
team electrical system U • • • • • • • • • • • •
with PDTs throughout the organization. engine assembly V •

january 2001 9
 T O O L K I T • I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n

Semiconductor Development at Intel

This DSM describes Intel’s proven and successful
process for developing and producing semiconductors.
This complex DSM clarifies to Intel where to concentrate
its efforts to improve the process. As the matrix reveals,
the process includes 15 planned stages, most of which
involve substantial iteration. There are also a significant
number of unplanned iterations (the O’s), which are the
subject of Intel’s process-improvement efforts. Three of the
iterations occur so late that the company treats feedback
from the later tasks (the ’s) as “generational learning”
feedback, to be used in the design and development of
subsequent products.

10 20 30 40 50 60
Set customer target • XX
Estimate sales volumes X • XX
Establish pricing direction X • X
Schedule project time line • X
Development methods X • X XXX
Macro targets/constraints XX • XXXX
Financial analysis XXXXX •
Develop program map X • X
Create initial QFD matrix X XXX •
10 Set technical requirements 10 X X XX • X
Write customer specification XX XXX • OOOO O O O O
High-level modeling XX XX • XXX
Write target specification XXX X XXXXX • XX
Develop test plan XX XXX • X
Develop validation plan XX X X •
Build base prototype X X XX XX •
Functional modeling X XX X X • XXXXXXXX O O O O O OOOO O
Develop product modules X XXXXXX XX • O
Lay out integration X XXXXXX X X •
20 Integration modeling 20 X X XXX X •
X X XX
Random testing X X • X XX
Develop test parameters X X XXXXX • XXX
Finalize schematics X X XXX • XX O O OO O
Validation simulation X X X XXXX • XX
Reliability modeling X XXXX • X
Complete product layout XX XXX • XX
Continuity verification X XX XX X •
Design rule check XX X •
Design package X X X X X • O O O OOO O
30 Generate masks 30 X XXX • X O
Verify masks in fab X X X •
Run wafers X • X O
Sort wafers X •
Create test programs X •
Debug products X X XXX • OO O OOO O
Package products X X X •
Functionality testing X X X •
Send samples to customers XX X X •
Feedback from customers X •
40 Verify sample functionality 40 X •
Approve packaged products X X XX •
Environmental validation XX X X •
Complete product validation X X XXX •
Develop tech. publications X X • XX
Develop service courses X X • X
Determine marketing name XXXX X • X
Licensing strategy XXX •
Create demonstration X X X X XX •
Confirm quality goals X X X XX •
50 Life testing 50 XX X • XX
Infant mortality testing XX X X • X
Mfg. process stabilization X XX • OO
Develop field support plan X X •
Thermal testing XXX •
Confirm process standards X • XX
Confirm package standards XX XXX • X
Final certification X XXX XXXXXXX •
Volume production X XX •
Prepare distribution network XX XXXXX X •
60 Deliver product to customers 60 XXXXX X X X •

X information flows planned stages O unplanned iterations generational learning

little to be gained from breaking down
the existing coupled groups.
But as the O’s show, a significant num-
ber of potential unplanned iterations
can occur when errors are discovered
during the development process. Results
from Intel’s thermal testing (task 54),
for example, could force the company
to rework package design (task 29) or to
rework functional modeling (task 17) or
both. This rework would also require
the company to redo some intervening
tasks. The value of the DSM in cases like
this resides principally in making ex-
plicit where information exchanges of

10 harvard business review

 I n n o vat i o n at t h e S p e e d o f I n f o r m at i o n • T O O L K I T

this kind might occur. The company erational learning feedback,” as Intel can emerge unexpectedly. At Intel, for
then decides what to do about them. did (see ’s near the top of the chart). instance, managers found they could
Sometimes, there’s little it can do. Rather than entirely rework the devel- reduce the likelihood of failures in ther-
The interdependent tasks may be so far oped product and come out behind mal testing by having a thermal-testing
apart that a delay caused by incorporat- competitors in that product cycle, the engineer contribute to package design.
ing late information effectively means company will either abandon the proj- Solutions of this kind will never entirely
eliminate unplanned iterations, but
By stripping away the mystery around the exchange they will certainly reduce the probabil-
ity of them.
of information during innovation, the DSM can give
managers far more control over some of their company’s In our experience, the information gen-
most risky and expensive projects. erated in a DSM analysis has always
yielded new insights to improve the
starting the whole process again. These ect altogether if the information reveals ways companies develop products and
situations usually arise because some fatal flaws or launch the product as de- services. By stripping away the mystery
fundamental mistake in assumptions signed if the flaws are minor. Mean- around the exchange of information
was made at the beginning of the proj- while, the information will be fed into during innovation, the DSM can give
ect. In Intel’s case, creating a product the design and development of a prod- managers far more control over some of
demonstration (task 48) had the poten- uct in the next generation. their company’s most risky and expen-
tial to reveal that the company’s esti- In most cases, though, development sive projects.
mates of sales volumes and pricing levels teams prefer to minimize the probabil-
For a more in-depth tutorial on how to create
were faulty (tasks 2 and 3). If the mis- ity that a later task will generate infor- DSM models and for links to DSM research
takes were serious, the product would mation that necessitates rework. Thus, and software, go to http://web.mit.edu/dsm.
have to be completely redesigned. it makes sense to transfer key knowl-
Reprint r0101l
In such cases, we recommend treat- edge and create prior tasks, as we dis- To place an order, call 1-800-988-0886.
ing the negative information as “gen- cussed above. But individual solutions

january 2001 11