Innovation at the speed of Information

7/28/2019 Innovation at the speed of Information

http://slidepdf.com/reader/full/innovation-at-the-speed-of-information 1/11

TOOL K IT

nnovation

at the Speed of

nformation

by Steven D. Eppinger

Developing a new product involves trial and

error, but beyond a certain pointy redesignbecomes was teful. A practical and proven

tool, the Design Structure Matrix, can help

streamline the way a com pany innovates.

TH E E X C H A N G E OF I N F O R M A T I O N

is the lifeblood of product develop-

ment. When an electronics company's

circuit designers know what the casing

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 w here it's easier to put in a bette r

circuit. Such flows of information allow

for experimentation and innovation,

and for that reason, many companiesencourage feedback and iteration in

their product development processes.

This practice is known as concurrent

engineering.

But excessive itera tion 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 w asteful. For example, at a

telecommunications company that mycolleagues and I advised, there were as



TO OL K IT • Inno vation at the Speed of Inform ation

many as 20 regular iterations among

the teams working on tw o key technical

specifications. The result was that few

people worked carefully on specifica-

tions in the early stages, because every-

one knew that extensive rework would

occur down the line.

The lesson is clear. Iteration must be

carefully planned and managed. Good

iteration should be encouraged and bad

iteration eliminated. To do that, man-

agers need representational tools to

help them identify and model iteration.

change, the complete organization of

such a process with a conventional

project-management tool. In addition,

by their nature, high-tech product-

development processes usually involve

many interwoven tasks.

There is, however, a tool that man-

agers can use to obtain a simple and

meaningful representation of such com-

plex processes. This tool, the Design

Struc ture Matrix (DSM), differs funda-

mentally from conventional project-

mana gemen t tools in that it focuses on

The Design Structure M atrix differs from conventional project-management tools in that it focuses on representing informationflows rather than work flows. Thus, it is better able to depict the

key dynamic o f innovation processes.

Unfortunately, the standard project-

manag ement to ol kits such as Microsoft

Project don't contain such tools. The

most commonly used project-planning

tools-principally PERT and CPM net-

work diagrams-a re graphic descrip-

tions of task flows. In th em , tasks are usu-

ally repres ented by boxes or circles, and

sequencing is represented by arrows.

In a complex project, a chart can ru n

to tens or even hundreds of pages, andeach page accommodates only so many

readable circles and arrows. A boxes-

and-arrows depiction of the design pro-

cess for a car's suspension, for example,

would run to more than 30 pages. If th e

project is made up of tasks that can be

completed in sequence w ithout fear of

rework, manageable charts for small

chunks of work can be generated.

But the tools become very hard t o use

if what happens on page 60 forces you

to rework a task on page 18, and, thus,

many of the subsequent tasks down to

page 60 again. It is almost impossible

for managers to comprehend, let alone

Steven D. Eppinger is the General Motors

Leaders for Manufacturing Associate

Professor of Managem ent Science and

Engineering Systems at MIT's Sloan

School of Management in Cambridge,

Massachusetts. He is also codirector of

MIT's Center for Innovation in ProductDevelopment.

representing the information flows of

a project rather th an th e work flows.

As a result, it isbetter able to depict the

key dynamic of innovation processes

such as product development. What's

more, it can often provide representa-

tions of complex develop ment processes

on a single page. In this a rticle, we will

explain how the DSM works and show

how a manager can use it to make de-

velopment processes more efficient.First, though , let's explore why p roduct

development needs a fundamentally

different planning tool.

Product DevelopmentIs About Inform ation,No t Tasks

PERT charts, Gantt charts, and other

common scheduling tools were created

to help managers plan large construc-

tion projects such as btiilding ships or

factories. Although these projects canbe

complex, involving hundreds of differ-

ent tasks or mo re, the planning princi-

ples are fairly simp le: you decide w here

and when tasks should be carried out

No matter how complicated, all con-

struction projects can be thou ght of as

a sequence of discrete tasks, many of

which can be conducted simultaneously

but n one of which should need rework-

ing as a result of later information .

Imagine you are building a house.Some tasks have to be completed in

sequence. You can't frame the wall

until you've built the foundation. You

can't put on the roof until you've buil

the w alls. Sequential tasks, by definitio

rely on information generated by ear

lier tasks. Other tasks, called paralle

tasks, can be carried out sim ultaneousl

You can install w indows, run wires, and

lay plumbing at the same time. These

three jobs need walls, but none need

the other two. Neither sequential no

parallel tasks will need to be reworked

as a result of subsequent tasks. You don

change the foundation afte

building the walls. You do n'

rewire as a result of the win

dow glazing.

Product development i

very different. It requires innovation, and innovation re

quires complex learning (feedback

loops. You repeat prior tasks as you

learn from subsequent ones. Interde

pendent tasks that benefit each othe

in this way are known as coupled task

If you want to come up with a bette

found ation for future hou ses, you migh

rework a fotmdation after building the

walls. The infonnation from such an it

eration is precisely what helps you fin

the improvement, and the presence ocoupled tasks is what distinguishes in

novation processes such as product de

velopment from construction projects

Conventional tools answer the ques

tion, "What other tasks must be com

pleted before I begin this one?" But th

planners of a product development pro

cess need a too l tha t answ ers a very dif

ferent question: "What information do

I need from other tasks before 1 ca

complete this one?"This is the question

the Design Structure Matrix addresses

Drawing the DSM

Constructing a DSM of your company'

existing product-development proces

is a relatively straightforward, if some

times time-consu ming, process.The fir

step, identifying the tasks involved, i

easy and is often available as part of th

project-management documentation

Companies with an established devel

opm ent process already know th e taskneeded to develop a new product. Ford



Innovation at the Speed of Informa tion • T O O L K IT

for example, executes largely the same

process each tim e it develops a new car

engine.

What tak es time is correctly identify-

ing the infonnation needs ofthe 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 the ir jobs. It's important to focus

on input rather than o utput 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 tha t supply necessary infor-

mation. In other words, looking acrossa row shows you all the information in-

puts you need to complete a task, and

looking down a column shows you ail

the information outputs you'll provide

to other tasks. Consider the simplified

DSM shown below. Reading along row

A

B

CD

E

F

C

H

1

J

A

•

X

XX

XX

B

•

X

X

X

c

•

XXX

XX

D E

•

•

XX X

X

F

•

X

X

c

X

X

•

X

H 1

X

• X

•

j

X

XX

B tells you that task B needs informa-

tion from tasks A, G, and J. Reading

down column B tells you tha t task B sup-plies information for tasks E, H, and J.

Wh at the D SM Can Tell You

A DSM of your development process

provides a useful reality check. First, it

clearly reveals which infonnation ex-

changes involve design iteration and

which do not. In the example just pre-

sented, note the diagonal formed by th e

dots that divide our matrix. All the X's

below the diagonal denote feedforward

infonnation exchanges in which infor-

mation from earlier tasks is available

for later tasks. But an X in th e uppe r

half denotes feedback in which infor-

mation from a subsequent task may force

a reworking of a prior task. These are

th e 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-

matio n from task G is finally available,

a rew orking 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'show. 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 infonnation

among them. If all the X's above the

diagonal are captured w ithin the boxes,

your organization has planned for these

iterations and has arranged its process

to accommodate them as efficiently as

possible. Our second example, below,

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

ofthe boxed tasks. These are unplanned

iterations.

In practice , of course , successful prod-uct developers are good at recognizing

A

B

cDLLJ

FcH

1

J

A

•

X

XX

X

X

B

•

X

X

X

c

•XX

X

X

X

D

•

XX

X

LLJ

•

X

F

•

X

X

c

o

X

•

X

H 1

X

• X

•

J

o

oo

•X j reforma tion flows

• planned iterations

O unplanned iterations

potential iterations, and their DSMs will

usually reveal a fairly efficient flow of

information. But some companies findthat 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 t o

deveiop new services, but it wasn't un til

they saw a DSM that they realized just

how many feedback loops were huilt

into their process.

OptimizingInformation 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 oft he DSM, a process tha t 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



Experiencing a Merger?

Acquiring a Company?Beina Acauired?

Ensure a smooth and lsuccessful transitionfor your workforce...

the future depends on it!

I i_Making Mergers Work/

is a powerful two-day interactive

semjnar offenng step-by-step

formulas for managing

large-scale c hange aftera merger or acquisition.

Making Mergers Work!

will arm you with proven

methodology and practical tools

to help you minimize difficulties,maximize results ond ach ievereturn on investment quickly.

Select from these ovoilobte dotes;

January 2Sth and 26th

February 8th and 9thFebruary 22nd and 23rd

CsJxUz of

Co~i.uL

sequentialtasks

paralleltasks

coupledtasks

coupledtasks

need t o be reworked. Refer-

ring to the two previous

DSMs, task A, therefore,

stays first. Task C comes

next because it nee ds infor-

mation only from A; these

are sequential tasks. Then,

we select tasks D and F to

come next because they

require information only

from A and C. Note tha t

D and F require no infor-

mation from each other, so

they can be carried out in

parallel, which we denote by a dashed-

line box in our third example.

Similarly, the ideal last task would not

produce any information required by

other tasks (in other words, its columnwould be blank). Here, that's task H,

which becomes the last task in the

project.

When you can no longer find any

tasks to schedu le early or late, you must

then group the remaining tasks into

blocks, bringing th e X's closer to the di-

agonal. In our exam pie, the most effec-

tive sequence shows two blocks of cou-

pled tasks: B, J, and G must be executed

together, as must tasks E and I. This

DSM plans for ail iterations.

A

cDLl

BJ

E

J_H

A

.

XX

XX

X

c

•XX

X

XX

D

'• "

X

XX

F

•

XX

B

•

X

X

X

J

X•X

X

c

X

•

XX

E

•

X

1 H

X•X •

For a simple DSM like the one here

it's fairly easy to identify by trial and

error the task ordering and couplin

that minimize the number of informa

tion feedbacks above the diagonal. Ithe case of more complicated DSMs

though, you will need to apply a sys

tematic approach involving the use o

computer-based algorithms.

Revisit task organization. Havin

rearranged the order of tasks, yo

should now reconsider their organiza

tion. Look again at the two blocks o

coupled tasks shown in the third DSM

above. In principle, the tasks within eac

set should be carried out at the sam

time and in the same place. But loo

Change Management Systems, INC.Call 'Ji at 305 iA? 9707 or visil

www.aboutcms.net

Chaotic Development in Telecommunication

Drawing a DSM ofthe development process or this company's

data services immediately revealed tbe degree of unplanned

iteration. Iterations w ithin the phases were built into the process

(the shaded boxes), but unplanned iterations across the phases

(the O's) were the reality.

planningphase

implementationphase

concept

business requirements

system requirements

network plan

techinical specifications

engineering design

billing implementation

operations engineering

customer service

launch

A

B

cD

ELl

G

H

1

J

A

•

X

X

X

X

H

•

X

X

X

X

c

•X

X

X

X

X

X

•

X

X

X

X

F

X

•

X

X

L

0

oo•

X

0

0

0

•

X

X

H

o

o

•X

X

1 J

0

X

X

•

X •



back to the second DSM, which shows

th e tasks that the hypothetical company

actually carries out concurrently. Task E

is grouped with 1, but tasks B, J, and G

do not fall within the initial group ing of

concurrent tasks; as a result, iterations

involving B , J, and G require many more

tasks in the original process. Clearly, this

company needs to rethink which tasks

are put together with which others.

Keeping interdependent tasks sepa-

rate can cause considerable waste, and

this is where grouping tasks differently

can really help to speed along the pro-

cess. One electronics company we ad-

vised found that it was performing a

set of tightly coupled tasks in two dif-

ferent coun tries. When th e teams were

briefly located together, they were ahleto complete the coupled tasks in just

two w eeks, thereby allowing other work

to proceed using their results.

Reduce information ex chang es. Re-

sequencing the matrix, though , will only

get you partway t o an efficient dev elop-

men t process. The next step is to reduce

the number of information exchanges

by changing the content of some ofthe

tasks. Because the importance and na-

ture of infonnation exchanges between

A DSM clearly reveals which

information exchanges involve

design iteration and which

do not It can also help you to

see how well your development

process is anticipating the

need for rework.

tasks can differ considerably, it is usu-

ally possible to break down coupledtasks into sm aller sets by chang ing task

specifications. Although this can mean

increasing the nu mb er of tasks and peo-

ple, the reduction in the number of

information flows-and thus in poten-

tial iterations - more than compensates

for these investments. The executives

at an aerospace firm we have worked

vtfith, for instance, believe that this ex-

ercise helped them to reduce the num-

ber of potential iterations in the com-

pany's development processes by asmuch as 50%.

I T P A Y S

T o B E T H O U G H T F U L

Join us at The Fuqua School of Business, wh ere th e th ou gh tfu l business leaders

of tomorro w are being taught today.

U.S. Te lephone: 919.660.7700

Europe Telep hon e: 4-49.69.972.6990

w w w . b u s i n e s s . d u k e . e d u

Thoughtful Business Leaders

Worldwide

D U K ETHE FIXJLJA

S C H O O LO F BUSINESS



T O O L KIT • Innovation at the Speed of In formation

Here are three ways to reduce the

need to exchange information. First, you

can transfer key knowiedge 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

suppiy information that would other-

wise have been exchanged in one or

more iterations between teams.

A simiiar effect can be achieved by

using information technoiogy. Com-

puter-aided engineering software, for

exampie, allows design teams to predict

the implications of their designs on each

other, again obviating the need for a di-

rect exchange of infonnation. A piastic-

parts designer at a manufacturer of cellphones can use moid-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 iater.

Second, you can introduce a new task

eariier in the process so as to simpiify

subsequent, time-Intensive iterations

performed by interdependent teams.

The new task typicaiiy requires eariy

Keeping interdependent tasks

separate can cause considerabie

waste, and this is where grouping

tasks djfferentiy can speed along

the deveiopment process.

agreement about aspects common to

the coupled tasks. The addition of a new

task, carried out by representatives ofthe coupled teams, can break down

some ofthe iterations. For example, two

teams designing coupled parts-say, an

electronic control circuit and its user-

interface keypad-can agree in advance

on the locations of the attachment

points and microswitches. This interface

specification aiiows the circuit-design

team and the keypad team to proceed

in parailei.

Third, you can redefine tasks within

coupled groups. Another way to reduceiterations is to eliminate an informa-

Improving Communication atGeneral Motors'Powertrain Division

W I T H I N THE PO W ER T R AI N D I V I S I O N

of General Moto rs, we used an inter-

esting variant ofthe 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 wit h one

ofthe four engine subsystems: the

short block, the valve t ra in, the in-

ductio n system, and the emissions

and e lectrical system. We suspected,

however, that th is org anization did

not adequately accommodate the

communication needs of all PDTs.

To check ou t our hypothesis, we

surveyed each of th e 22 PDTs about

it5 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 w ith an X, we used three sym-

bols to reflect the varying frequency

of team interactions: a large circle

for daily communication, a midsize

circle forweekly m eetings, and a

small dot for monthly conferences.

The results are shown in the chart

"Organizing Communication atGM

PT: Before."The boxes show which

tasks were coupled in CM's originalstructure of system team s.

The DSM revealed that CM 's exist-

ing organization was indeed flawed.

In addition to the regular interac-

tions by the PDTs with in 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 sh ort block system

team, also had daily meetings with

me mb ersof all three teams in the

valve train system te am , 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

form al process, and their orga niza-

tion was left to the people involved.

In many cases, the interactions sim-

ply didn't occur and, thus, informa-tio n 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 c omm unication needs

across the e ntire developm ent 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 atGM PT: After."

The new DSM demonstrated to

CM that it needed to introduce a

different type of organization. For

a start, while many PDTs could

be assigned to one system tea m

encompassing their principal inter-

actions, a certain amount of cross-

mem bership was required. SomePDTs-pistons, for example-were

assigned to tw o system teams. Two

PDTs, cylinder heads (G) and intake

manifold (J), were assigned to three

system teams. (For visual c larity in

the new m atrix, these teams appear

as Gl and G2 and Ji and J2, respec-

tively.) The boxed groups on the re-

configured m atrix denote the four

new overlapping system teams that

CM created.



Innovation at the Speed of Information • TOOL KIT

But the greatest chalienge facing

GM was how to organize the five

PDTs atthe bottom ofthe matrix,

whose systemwide c omm unication

needs could not be met within the

structure of a system team. The solu-

tion we worked out with GM was to

group these teams into a special

"system integration team " whose

respon sibility was to ensure theoverall integration of work by the

four system teams so that the engine

being developed would meet the

required performance standards.

The system integration team met

its communication needs by leading

monthly program meetings at which

everyone discussed issues related

to overall product performance.

Organizing Com mun ication at GM PT

Before...

short blocksystem team

valve train

system team

inductionsystem team

emissions andelectrical

system team

engine block Acrankshaft Bf lywheel cpistons Dconne cting rods E

„ . lubricat ion Fp cylinde r beads c] camshaft/valve train H

l_ water pump/cooling ippintake manifoldfuel systemaccessory driveair cleanerAIR

_ t b r o t t l e b o d yexhaustEGREVAPigni t ionECM

_ electrical systemengine assembly

j

A B C D E F C H I J K L M N O P Q R S T U V

A * • • • •• B • • • •

. , c• a • Q a a

• • • E •• a . a . F• . a

• • • a

• a a

a .

• a

• • • •

• a , .

• . a . •

• • a • a •

a - -

m 9 9

. • .

G • •• H •

• • 1• • •

•• • •

a .

• a

•

a

• • •

• • •

• a •

•

a

• a

• a • a .

a . • .

) • • • • •

• • L • • •• • AM • •

a * N *

• > • • • Oa a . . •

• • •

• • a

a • . » •

• • a a a

• •

a .

•

• • a

• • a •

a • • •

p • • • •• Q . • .

R • •• • S * *• • • • T *• • • • • Ua a . • a •

a

•

a

•

a

•

•

a

•

•

a

a

a

a

a

a

•

a

•

V

frequency of team interactions

• daily • weekly • monthly

These DSMs use symbols of varying size to

reflect the requency of team interactions .

The boxes show which product develop-

ment teams (PDTs) are grouped together

into system teams. In the "before"DSM,

we see that m any PDTs had frequent

contacts outside their designated groups.The reorganization first isolated

the PDTs with communication needs

across the whole organization and then

regrouped the remaining PDTs into new

system teams so that most daily and

weekly meeting needs would be met.

Th e "after"DSM shows the four new

overlapping teams as well as the system

integration team that communicated

with PDTs throughout the organization.

..,and After

team i

team 2

teams

team 4

integrationteam

crankshaftf lywheelconnecting rodspistonslubricat ionengine blockcamshaft/valve traincylinder headsintake m anifoldwater pump/coolingfuel systemair cleanerthrott le bodyEVAPcylinder beadsintake ma nifoldAIRexhaustECRaccessory driveigni t ionECMelectrical system

_ engine assembly

B

rEDF

AHr,1|1

1

KMO

RC?n

NP0L

TI IV

B C E D E A

B • • • • •

• c - •• E • • '

a • •

• • •

• F •

• • A

H G l Jl 1 K M 0 R G2 J2 N

•

a • •

• • • •

• . W H • • •

• • • •G I • •• • • ^ j ! •

a a • a • a 1

• -

• . .

• K • • • • • •

• M • • • •

a a • O • • • •

• • R

a

• * 4 *t a •

. . . a .

. .

G 2 » "

L

a

•

•

•

•

. a

• : •

a a

• •

• 12 * • '

• • NU •• • • p •• • • • Q

•

•

•

•

•

• • • • • • • • • • • • • • • • L

a . . . . . a « « a a . a a . a .

• a . a « a . . . a . . . . . . .

• a a * « « a » « a « • . 9 9 9 • * *

S 1

• •

••

•• •

• •

a

•

a a

a

a a

• •

• •

• T• •• a

U

a

a

•

•

•

•

•

•

•

•

*

•

•

V

•a

a

a

a

•

•

•

•

a

•

•

a

a

•

a

a

•

V



TO OL K IT • Innovation at the Speed of Inform ation

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

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 hased on

output from the first two tasks, and

A coupled process encourages iterations and th e

search for creative solu tions. But som etimes speed is

more imp or tant than innovat ion.

Supplier A adopts a concurrent engi-

neering process, carrying out th ree tasks

(casing design, wiring layo ut, and light-

ing details) at once, with three taskteams working in close proximity. The

three teams go through a number of

iterations and take a relatively long time

to finalize th eir plans, but the end result

is a fairly advanced prototy pe. However,

if the testing phase reveals problems,

the speedometer is then crudely proto-

typed. Once the prototype has been

tested, wiring revisions are made to

produce the final design. Although itinvolves an extra task-re visin g th e wir-

ing-in fact, this process is faster than

the first because the re is mu ch less iter-

ation between two task teams than

among three. The extra step also antici-

pates and allows for changes to th e pro-

Reducing Information Exchange

by Decoup ling Tasks

Supplier A has three teams that carry out their tasks concurrentfy. After a number

of iterations, a fairly advanced prototype is developed an d tested. But if problems

arise during the testing phase, up to four steps of the engineering process ca n be

affected (see O's).

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

of wiring revision is introduced. However, this process is faster than Supplier A's

because less iteration occurs between the two initial task teams, and the extra

step of planned iteration virtually eliminates unplanned iteration.

Supplier AHighly innovative, but slow

Supplier BFast, bu t less innovative

A B C D E F A B C D F C

casing designwiring layoutlighting detailstoolinghard prototypetesting

• X X

X - X

X X •

X X X

ooo

oX •

X •

casing design Alighting details Bwiring layout csoft prototype Dtesting Erevision F

hard tooling c

• X

X •

X X

X X

X X

*

X •

X •

X •

X X X '

totype, and planned iterations virtually

eliminate unplanned ones.

In general, any decision to decoupl

a task (in this case, wiring) depends on

how the company views the trade-of

between speed and quality. A coupled

process encourages iterations and the

search for creative solutions and thu

is more likely to produce a significan

improvement in the quality of the prod

uct being developed. But sometime

speed is more important than innova

tion. Then, a faster, less coupled proces

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 op timizea process so that all of the X's were

moved close to or below the diagonal

All coupled tasks could be carried ou

concurrently, so all iterations could be

planned for.

In real life, however, product devel

opm ent 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 carded out together

There will generally be tasks that can

only be conducted later in the procesbut that provide information for task

completed months earlier.

Consider Intel, one of the most con

sistently successful product developer

and a company that regularly leads the

way in developing the next generation o

microprocessors. The p roduct develop

men t process for semiconductor chips a

Intel consists of 60 distinct tasks, and

the DSM is shown in the chart "Semi

condu ctor D evelopment at Intel." Abov

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 m anaged stages. Som

of the stages overlap, that is, some o

the tasks in one grou p are also included

in the next. As you might expect, there

is little inc entive for a highly successfu

company like Intel to improve its tried

trusted process through rearranging andreorganizing its tasks. Equally, there i



Innovation at the Speed of Information • T O O L K I T

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 1 5 planned stages, most of which

involve substantial iteration. There are also a significant

number of unplanned iterations (the O's), v^'hich are the

subject of Intel's process-improvement efforts. Three of the

iterations occur so tate 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 , 2 0 , , 3 0 , , 4 0 ,

Set customer targetEstimate sales volumesEstablish pricing directionSchedule project time lineDevelopment methodsMacro targets/contraintsFinancial analysisDevelop program mapCreate initiaTQFD matrix

10 Set technical requirenient5

Write customer specificationHigh-level modelingWrite target specificationDevelop test planDevelop validation planBuild base prototypeFunctional modelingDevelop product modulesLayout integration

30 Integration niodelingRandom testingDevejop test parametersFinalize schematicsValidation simulationReliability modelingComplete product layoutContinuity verificationDesign rule checkDesign package

30 Generate masKSVerify masks in lab

Run wafersSort wafersCreate test programsDebug productsPackage pro ductsFunctionality testingSend samples to customersFeedback from customers

40 Verify sample functionalityApprove packaged productsEnvironmental validationComplete product validationDevelop tech. publicationsDevelop service coursesDeterrnine marketing nameLicensing strategyCreate dem onstrationConfirm quality goals

50 Life testingInfant mortality testingM f g . process stabilization

Develop field support planThermal testingConfirm process standardsConfirm package standardsFinal certificationVolume productionPrepare distribution network

60 Deliver product to customers

, 5 0 , ,60

20

0000 0 0

XX

X

X

x x x xX X XX

XX

X XX XX

X XX X X

X X X X X X XX X X X X X XX X XXX

X X

X X

X X

XXXX

x x x x x x x x

X - X XX• X XX

X X X X X ' X X.Xx x x F Jtx

X X X X X ' X Xxxxx

XXX XX

X X X

XXXX

XXX

XXX

0 0 0 0

0 0

XX X XX

• XX •

X

0

Xx -XXX" '

0 0

00 0

XX

X X

0000 0

000 0

000 0

XXX

x x x x xx x x x x

X information flows D planned stages O unplanned iterations generational learning

little to be gained from breaking down

the existing coupled g roups.

But a s the O's show, a significant num-

ber of potential unplanned iterationscan occur when errors are discovered

during th e developm ent process. Results

from Intel's thermal testing (task 54),

for example, could force the company

to rework package design (task 2 9 ) or torework functional modeling (task 17 ) or

both. This rework would also require

the company to redo some intervening

tasks. T h e value ofthe D SM in cases tike

this resides principally in making ex-plicit where information exchanges of



TO OL K IT • Innova tion at the Speed of Inform ation

this kind might occur. The company

then decides what to do about them.

Sometimes, there's little it can do.

The interdep enden t tasks may be so far

apart that a delay caused by incorporat-

ing late information effectively means

erational learning feedback," as Intel

did (see • 's near the top of the chart).

Rather than entirely rework the devel-

oped product and come out behind

competitors in that product cycle, the

company will either abandon the proj-

By strip pin g away the m ystery arou nd the exchange

of inform at ion durin g inn ovat ion, the DSM can give

managers far more contro l over some of their company's

most risky and expensive projects.

starting the whole process again. These

situations usually arise because some

fundamental mistake in assumptions

was made at the beginning of the proj-

ect. In Intel's case, creating a product

demo nstration (task 48) had th e poten-tial to reveal that the company's esti-

mates of sales volumes and pricing levels

were faulty (tasks 2 and 3)- If th e mis-

takes were serious, the product wouid

have to be completely redesigned.

In such cases, we recommend treat-

ing the negative infomiation as "gen-

ect altogethe r if th e information reveals

fatal flaws or launch the product as de-

signed if the flaws are minor. Mean-

while, the information will be fed into

the design and development of a prod-

uct in the next generation.In most cases, though, development

teams prefer to minimize the probabil-

ity that a later task will generate infor-

mation that necessitates rework. Thus,

it makes sense to transfer key knowl-

edge and create prior tasks, as we dis-

cussed above. But individual solutions

can emerge unexpectedly. At Intel, fo

instance, managers found they could

reduce th e likelihood of failures in ther

mal testing by having a thermal-testing

engineer con tribute to package design

Solutions of this kind will never entirely

eliminate unplanned iterations, buthey will certainly reduce the probabil

ity of them .

In our experience, the information gen

erated in a DSM analysis has alway

yielded new insights to improve the

ways companies develop products and

services. By stripping away the myster

around the exchange of information

during innovation, the DSM can give

managers far more control over some o

their company's most risky and expensive proje cts.

For a more in-depth tutorial on how to crDSM models and for links to DSM researand so ftware, go to ht tp-JAveb.mit.edu/d

Reprint ROIOIL

To order reprints, see the last page

of Executive Su mmaries.

"Our idea is to use this logo if Congress won't approve a postal rate increase.



Harvard Business Review Notice of Use Restrictions, May 2009

Harvard Business Review and Harvard Business Publishing Newsletter content on EBSCOhost is licensed for

the private individual use of authorized EBSCOhost users. It is not intended for use as assigned course material

in academic institutions nor as corporate learning or training materials in businesses. Academic licensees may

not use this content in electronic reserves, electronic course packs, persistent linking from syllabi or by any

other means of incorporating the content into course resources. Business licensees may not host this content on

learning management systems or use persistent linking or other means to incorporate the content into learning

management systems. Harvard Business Publishing will be pleased to grant permission to make this content

available through such means. For rates and permission, contact [email protected].

Innovation at the speed of Information

Documents

Transcript of Innovation at the speed of Information