The coupling of product architecture and organizational structure decisions

RAO

ASEI\4EI\rr'

.'y.' '

^.^XCHU^^X

/tts)

DEWEY

^^^"^^"

_{Massachusetts}

_Institute

_of

_Technology

Sloan School

of

Management

Working

Paper

HD28

,M414

%

The

Coupling

of

Product

Architecture

and

Organizational Structure Decisions

Rosaline K. Gulati

Steven D. Eppinger

May

28, 1996

Working

Paper

Number

3906

Abstract

This

work

is motivated

by

ourinformal observation thatcorporations re-designtheir products

and theirorganizations quite separately.

We

find,however, thatthe relationshipof product

architecture toorganizational design isan intricate one. This study provides a rudimentarybasis

forunderstandingthe linkages between productarchitectureand organizational design,

which

may

allow

managers

to

implement

theappropnate organizational orarchitectural structures. In

addition,athorough understanding ofthe reliance that productarchitecture has

upon

organizational design

and

vice versacanaid managers increatingan environmentin

which

productarchitecturecan exploit theadvantagesofthecurrentorganizational design

and

in

which

theorganrzational designcan enhancetheeffuiency ofthepersonnel interactions ref^'iired ^o

implement

a product's architecture.

We

discuss severalobservationsaboutthedimensions

by

which

these attributes are coupled.

Acknowledgment

Funding

forthis research has been provided bythe

MIT

International CenterforResearch

on

the

Management

ofTechnology.

We

appreciate the assistance ofthe

company

that

we

studiedin

developingthe

examples

presentedin this paper.

Contact

Professor StevenD. Eppinger

MIT

Sloan School of

Management

Cambridge,

MA

02142-1347

Eppinger@mit.edu

MASSACHUSETTS_INSTITUTE

OF T'-^wvoi.OGY

SEP

le

1996

I. Introduction

This paperexplores theinterdependence between

two

keydecisionareas inthe

development

of

new

products: product architectureand organizational design.

We

conducted afieldstudy of

audiosystem

development

inamajor

American

automotive firm. This firm

competes

inglobal

markets

and

utilizes

new

technologies

which

give risetoseveral p)ossibleproductarchitectures

and

organizational structures.

By

separating thesedecisions forourdiscussion,

we

are able to

explore

some

ofthefundamental issues

which

couple them.

Our

results suggestseveral

ways

in

which

decisionsand plans forproductarchitecture

and

organizational design

must

be integrated.

Inorderto explore thecoupling betweenthese

two

issues,

we

focusedourstudyalong the

following dimensions: product andproblem decompositions, integration

mechanisms,

communication

patterns,supplier relationships, and reporting structures.

We

define product

and

problem

decomposition to be thepractice ofsplittinga

complex

engineering challenge into

several simpler ones, while integrationis thechallengeofmergingsolutions to theseseparate

problemsintoanoverall system.

Communication

patterns (i.e.

how

informationmight flow)

depend

on

the type and structureoftheprojectteam [Barczak and

Wilemon

1991]. Supplier

relationships can takeamyriad of forms. Therefore,

we

were particularlyinterested in

investigating the characteristicsofthese alliances

which

might haveinfluenced product

architectures. Reporting structures

we

examined

were those

which

affected or

were

affected

by

Figure 1.

Problem

Decomposition and Organizational Assignment.

The

organization

must

decompose

the

complex problem and

all(x;ate tasks to the product

de\clopment team

(solid arrows).

Additionally, information

must

be ccx)rdinated across individuals,

teams, and suppliers (dashedarrows).

Pastresearch in product

development

has

shown

thata

company's

capability toconceive and

design avariety of superiorprcxiucts and bring

them

tomarketfasterthan its competitors can be

a sourceofsignificant competitiveadvantage [Wheelwright and Clark 1992J.

Wheelwright

and

Clark

emphasize

the imptxtance oflearning in the organiziition.

Companies

that follow a path of

continuous

improvement

inproductand processdevelopment will

more

consistently "design it

right thefirsttime" and yield a head start in gettingtheir productsto market.

An

understanding

ofthe key relationships in product planning can facilitate "designfing] it rightthe first time."

Priorresearch by Clark and Fujimoto [1991] explores the impactofstrategy, organization,and

management

upon

product development.

They

claim that

management

direction and the

development

organization both playcritical roles iii providing the integrated effortand

leadership needed tosuccessfully execute a product's architectural plan

and

to

move

that prtxluct

efficientlyand quickly tomarket. _{Rosenthal [1991J suggests} that, inorderto besuccessful, a

firm

must implement

a managerial view ofthedesign and

development

process thatattemptsto

help catch design flawsearly, correct mistakes,andavoid long

development

delays.

Henderson

and Clark [1990] indicate that"architectural innovation has the pcHential to offerfirms the

opportunity to gain significantadvantage," in thecontextof understanding that a well-entrenched

Clark [1987] indicates thata corporation's problem solving structuremirrors thetechnical

and

conceptual structureofits product(s). Innovative changesin the productcan expose

discontinuities inorganizational knowledge, informationflows, andprocedures. Ultimately, the

natureof these breakscan determine the styleof competitive response [Clark 1987].

This research connectsarchitectural choicesandorganizational choices. Itexpands

on

our

previous research projects

which

haveexplored system integrationin

complex development

environments.

McCord

and

Eppinger [1993] highlight theimportance ofdeterminingtheneeds

for integration and coordination

by

studying theunderlying technical structure ofaproject.

Pimmler and

Eppinger [1994]

show

thatan understanding ofthe "system engineering" needs,

which

arise becauseof

complex

interactions between

components

of a design, is useful todefine

a product's architecture and toorganizedevelopment teams. Finally, Morelli, Eppinger,

and

Gulati [1995] propose thatfor the

management

ofproductdevelopment projects, certainaspects

of organizational design can be planned byanticipating the technical

communication

linkages

requiredforprojectexecution.

Ina

complex

product, theco-dependencies between architectural andorganizational choices can beimportant considerations

when

decomposing

aproblem. Alexander [1964] states thatthereis

an important underiying structural correspondence between thepattern of a

problem

and the

processofdesigning the problem's solution In ourcase, itis feasiblethat the architectural or

organizationaldecompositions

depended

on

the

numbers

and distributionsoftheirpotential

intermediatestable forms '. That_{is, thedirection} in

which

theorganization orarchitecture might

evolve can besignificantly influenced by it's priorform.

Complex

systems will evolve

from

simple systems

much

more

rapidlyifthere are stableintermediate formsthan ifthereare not.

Furthermore, the

components

of a technological system (suchas a

complex

organization) will

interact. Therefore, theircharacteristics will derivefrom thesystem [Bijker 1987]. Bijker,

Hughes, and Pinch 1 1987| give ihe

example

of the

managcmcnl

siruclurcofan cleclriclight and

pcnver ulilily depending

on

ihc character ofthe functioninghardwareor artifacts in the system.

They

alsostates thatthe

management

structure reflects theparticular

economic

mix

ofartifacts in

thesystem, and the layoutof the artifact

mix

is analogous to the

management

structure.

Simon

[1990] argues that in nearly

decomposable

systems (such as these) the shorl-run behaviorofeach

ofthe

component

subsystems is approximately independentoftheshort-run behavior oftheother

components. In the longrun, the behavior ofany oneofthe

components

depends only in an

aggregate

way

on

the behavior ofthe other

components [Simon

_1990J. In lightof thefact that

complex

problemsinvolve

communication

among

many

people,

von

Hippel [1990] proposes that

firms specify tasks in order toreduce the problem-solving interdependence

among

them

by

predicting

w

hich tasks are likely tobe important

new

information sourcesand

which

tasks affect

eachother.

ProductArchitecture

We

defineproductarchitecture tobe thesetoftechnical decisions (theplan) for the layoutofthe

product, its modules,and for theinteractions between themodules. Productarchitecture is the

scheme

by

which

the function of a productis allocated tophysical components. Itcan be a key

driverof theperformanceofthe manufacturing firm and relates toproduct change, product

variety,

component

standardization, productperformance, andprcxluct

development

management

[Ulnch 1995]. In

some

companies,the product architectures offlagship products might even

guide decision prcx:esses.

At

Sony, design is

done

verydifferently depending

on

the product.

For the

Walkman,

generational changesare led byengineering, with heavy involvement from top

management.

In other products, marketingand sales lead certain classesofchanges. In products

that

do

not fit in eitherofthe

above

two

categories,the industrial design organization plays a

heavy

role [Sanderson 1995].

The

physicalelementsofa productare the parts,components, and subassemblies that ultimately

implement

theproduct's functions.

The

chunksare the collectionsoftheseelements and so

may

implement

one

ora

few

functional elements intheirentirety [Ulrichand Eppinger 1995].

A

modular

architectureisone in

which

chunks implement one ora

few

functional elements in their

entirety,

and

where

the interactions between thechunks arefundamental to the primary functions

oftheproduct.

An

example

of a

modular

architecture isacar radio

which

is utilizedin several

differentaudio systemsacross vehiclelinesand is a stand-aloneproduct.

An

integral

architecture is theoppositeof a

modular

architecture. It isonein

which

asingle

chunk

implements

many

of thefunctional elements, and

where

the interactions

between

the

chunks

are

not well-defined and

may

be incidental to thefunction ofthe product.

An

example

ofan integral

architectureis the integrated control panel developed forthe 1996 Ford Taurus audio

and

climate

controlsystems.

Orf^cinizdliondlDesign

Organizational design is thedecision process thatbrings about acoherence between the goals

and purposes for

which

the organi/iilionexists, the patterns ofdivision ol laborand interunit

coordinationand the people

u ho w

ill

do

the

work

[Galbraith 1977].

We

focusourattention on

the creation offormal managerial processes and

communication

channels that facilitate the

organization's decision process.

One

importantdimension of organizational design is the typeof

structure thatgives rise toits capabilitiesand coordinationabilities.

A

pure functional

organizationencourages long-term technical specialization.

However,

physical and

organizational distance between sub-functions increases.

A

pure projectorganization focuses an

organization's energies major

development

projectsand encourages cross-functional

communication.

However,

by doing this, it

may

sacrifice

some

functional expertise

[Wheelwright and Clark 1992].

A

matrix organizationintegrates the specialized resources oftheorganizationswithout

organizing aroundaself-contained product orproject [Galbraith 1977]. Although a matrix

organization solves

many

ofthe problemsof pure functional and pure projectorganizations, it is

important torecognize that ithas otherdrawbacks

which

are

beyond

thescope ofthis paper(e.g.

problems caused

by

p)oor relations between units) [Galbraith 1994].

Otherorganizational design

mechanisms

include the creation of slack resources (i.e. adding

additional resourcesand reducingeach individual group's required level ofperformance),

creating .self-contained tasks(i.e. assure thateach group hasall theresources it needs to perform

its task), investing in vertical information systems(i.e. invest in

mechanisms which

allow the

organization toprocess information acquired

dunng

task performance withoutoverkxiding the

hierarchical

communication

channels), or creating lateral relations (i.e. selectively

employ

lateral

CouplingArchitectureto Organization

While

other research hasanalyzed thedimensionsofdecompositionof organizationsand product

architectures independently [Sanderson 1995,

Uzumeri

1995,

Meyer

1993],this paperhighlights

the

ways

in

which

organizational competenciesand

frameworks

arecoupled to architectural

interactions

and

theirfunction in theorganizational structure.

We

draw

the conclusionthat this

distinct relationship meritsspecial considerationinmanagerial decision making.

A

thorough

understanding ofthe reliance thatproductarchitecture has

upon

organizational design

and

vice

versacan aid

managers

increatingabeneficialenvironment in

which

productarchitecture can

exploit the advantagesofthecurrent organizational designand in

which

theorganizational

designcan

enhance

theefficiencyofthepersonnel interactions requiredto

implement

aproduct's

architecture. Additionally, organizational designcan assisttheexecution of a product's

technology

by

facilitating the integrationof variousdisciplines, technologies,components,

and

systems intoaproduct.

The

next section ofthis paperoutlines ourresearch

methodology

and introduces the

audio-system design focus ofourfield work.

Then

we

presentexamplesofarchitecture affecting

organizational designand organizational design affecting architecture,

and

discuss the coupling

ofthese decisions.

We

conclude with a

summary

ofthe implications for practitioners

and

directions for future research.

II.

Audio System Case

Studies

The

data forthis case study

come

from interviews andobservationsofaudiosystem

development

teams in

two

verydifferentorganizations (one

American and

one European)in a

major

US

automotive manufacturing firm. Although underthe

same

parent

company,

the

two

sites are

different in

many

ways,includingculture,language,

work

habits, vehicle programs,

management

style, technical capabilities, supplierrelationships,and scope oftechnical responsibility.

We

interviewed personnelin engineering, managerial,andbusiness functions

from

global

developmcnl

teams

on 26

dilTcrcnl car lines and 63 audio systems. Thjsparticular

company

designs and manufactures about3(X) different radios.

The

intersiews were conducted overafive

month

period in 1995.

Our

study concentrated largely on factory installedautomotive audio

systems. Finally,

we

extracted theexamples from the case studiesand re-framed

them

into

more

general issues forour presentation here.

An

audio systemconsistsofall the

components

ina vehicle

which

aid in providing audible

information.

These

components

include, butare notlimited to the radio, amplifier, speakers,

wiring harness, andcellulartelephone.

r^

IF Speaker CellJar Anlema TeOaT Phone lU AM/FM Anlema LB [Speaker

^^:^

A Tuner Anlema Mo(or Power Ampdfter

m

Dsp(ay Cassene

—

CD

—

Changer FronT Conlrols I Mear IControls

Figure3.

Audio System A

n-hitcci'ire.

lakec JJ Speaker Hear

4

m

Speak

^

At

first glance,an audio system

may

appearto be a very simple groupofcomponents. In reality,

however, it is quitecomplicated.

An

audiosystem can involve

anywhere

from 4(X) to

600

components, six totendesign engineers, and three to fiveoutsidesuppliers. Itcan also take three

years to fullydevelop.

The company

we

studieddevelops ten totwenty audiosystems at

one

time. Outside suppliers are often in\ol\cd in \arious functions including: integrated circuit

Some

ofthecomplexity inan audio system arisesfrom the technical interactions and coupling

effects from nesting. Nesting refers tothe idea that

components

within alargersystemare

self-contained, such as theaudiosystem within avehicle [Christensen and

Rosenbloom

1995].

Both

modular

and integral architecturescan be arrangedina nestedfashion. Ina nested hierarchy,

each

component

can alsobe

viewed

as asystem

which

comprises sub-components

whose

relationships toeachotherare alsodefined

by

aproductarchitecture. Similarly, the product

may

alsobe

viewed

asa

component

within alargersystem, relating toother

components

withina

definedarchitecture. Simply, products

which

atone levelcan be

viewed

as

complex

architected

systems actas

components

insystems ata higherlevel [Christensen and

Rosenbloom

1995].

Subsystems

aredefinedas systems-of-use within a nested hierarchyofproductarchitectures.

Figure

4

illustrates anested hierarchyofproductarchitecturesfrom vehicleaudiosystems to

entire vehiclelines.

At

the highest level, the architectureof a vehicle platform iscomprised ofall ofthe different

vehicle lines thatthis particular

company

makes.

At

thevehicle platform level, pricing is

determined,manufacturing issues are dealt with,

modular

components

are specified,

and

the

service

and

repairrequirements arelaid out.

The

nextlevel

down,

thearchitecture of a vehicle

line is

where

liaisons can be createdwith marketingand sales,ergonomics are taken into

consideration,

and

noise, vibration,and harshness issuesare oftenuncovered.

At

the thirdlevel,

the audiosubsystem level,orany otherelectronic subsystem forthat matter, theaudio-specific

customer requirementsare uncovered.

The

interfacesfjecifications and requirements

and

the

subsystem designspecifications are delineated. Lastly, the architectureofthe radio, in turn,can

itselfbe analyzed as asystem

composed

ofintegratedcircuits, speakers,

and

fasciadesign,for

example.

Archilfcturv ofa Vehicle I'latform

PricingDetennination ManufacturingIssues

Architcflurc ofuVehicle Line

l.iais«n witliMarketing

l-.rgononiii.!-Architecture ofanAudio Subsystem

("usiomcrRequirements

Antenna Requirements SpeakerRequirements

r 1

'ArchitcctureofaRadio ,

I Integrated CircuitSpetificatuins '

I

SpeakerRequirements |

ControlsandDisplays i

I Tuners andAmplifiers

I

FasciaDesign I

InterfaceSpecificationsandRequirements

Subsystem DesignSpecifications

Liaison withSales Noise,Vibration,andHarshness

LXtemiine ModularComponentSpecifications ServiceandRepairRequirements

Figure4.

A

nested hierarchyofprtxluct architectures.

The

interactions alongwith thenesting ofthe audiosystem in theautomobile forcea coupling

between theaudio system and thevehicle.

By

making

design decisions ofoneor theother

mdependently,a firm

would

sub-optimize pieces ofthe entire automobile.

III. Discussion of Findings

In this section,

we

will presentourfindingsbyfirstdelineating the

manner

in

which

and to

what

extentarchitectural choicesarecoupled to theestablished organizational capabilities

and

structures. Next,

we

investigate the natureofthecases in

which

organizational design drove

architectural decisions.

A. Architecture choicesdictate organizational design choices.

Developing audio systems forautomobiles is a surprisingly

complex

task.

Not

only is the

architectural layoutofa singleaudiosystem extremely complicated, but the interactions

between

a vehicle and its audio system

may

involve large

numbers

of peopleand physical parts.

Decomposition

determines

team

assignments.

Products that are

decomposed

into architectural chunks encourage theassignmentofa

team

to

each chunk. Productsare usually

decomposed

until a team, individual,or suppliercan be

assigned responsibility foreach

chunk

[Rechtin 1991]. Traditionally the groupsoffunctional

elements ina product have had afunctional team assigned tothem.

An

example

ofan effective

chunk-to-team

mapping

is theassignmentofautomotive systems todepartments/teams suchas a

climatecontrol systems oraudiosystems. Forstatic

modular

architectures in

which

the

interfaces arevery well understood, thisapproach

makes

sense.

However,

when

the architecture

changesor ifthe interface parameters are not well defined, this approach

becomes

less

appropriateas it

would

require theorganization tochange.

A

change intheorganization

would

probably be verycostly for justonearchitectural generation.

Inother design

domains

(e.g. software),

complex

systems arebroken intosmaller,

more

manageable

tasks.

The

complex

detailsofeachofthe smallersub-systemsare

below

the

abstraction barrier. Often there is anagreement(or contract) tospecify the detailsof the

interfaces

and

parameters passed between the

complex

system

and

each ofthesub-systems.

Effectively, ateachlevel, the architectureis theplan ofall these abstractions

and

contracts

[Moses

1995]

and

teamsare assignedto thesubsystems. See Figure5.

Complex

Problem

toplevel decomposiljon ABSTRACTION BARRIER ABSTRACTION BARRIER

Figure5.

Problem

Decomposition and Abstraction

The

organizationin ourstudytraditionally has engineered strictly

modular

architectures.

So

people have been grouped notaccording to theirtechnical specialties, butinstead according to

thephysical

modules

of the product. Since today's audiosystemarchitecturesare

becoming

more

integrated, theorganization has adapted to

accommodate

cross-module

team

structures.

Incidentalinteractionscatalyzetheformation of

problem

solving teams.

Often incidental interactionsoccuratthe intersectionofthe

decomposed

elements. Inourstudy,

couplingproblems

were

more

difficult toanticipate in the

more

novel technologies.

These

coupling issues giverise to integrationproblems

and

cause thecreation of

ad

hoc system

integration teams to handle theseissues.

A

solid analysis of

where

interactionscan facilitate the

clusteringofthe high frequency interactions within subsystems can minimize the interactions

acrossdifficult barriers

[McCord

and Eppinger 1993]. Furthermore, pre-development planning

and product integrityenhance theperformance ofprtxluct

development

teams (andalso minimize

unplanned incidental interactions), especially ifthe organiziition is verysystem focused, since

lead time and prcxluctivity

become

much

more

predictable

(Brown

and Eisenhardt 1995].

Inourcasestudy, theformation of

ad

hoc teams

on

asmall scale

was

not

uncommon. Though

we

did find that

ad

hoc teams had not been planned inadvanceduring the product

development

planningprocess. This lack ofanticipation caused the programdelaysand extracosts. Inone

instance, serious system problems had notbeendiscovered until the entireaudiosystem had been

integratedin thevehicleduring theprototyping process.

Due

tothe urgencyincorrecting these

issues (i.e. the vehiclecould notbe sold with a malfunctioningaudio system

and

a majordelay in

the manufacturingofthe vehiclecan be extremelycostly), aformal troubleshooting

team

was

established.

Architecturedetermines

communication

patterns.

The

layoutof the productarchitecture's fundamental and incidental interactions impliesa

specific patternof organizational communication. Ifthere exist barriers to theexecution ofthis

pattern, these barrierscan catalyzedelays in theproductdevelopment cycle. Thisissue

becomes

particularly relevant toco-locatedteams, especially ifonlyasubsetofthe larger

development

team is being co-located. Additionally,

knowledge

ofspecific types and patterns of

communication and

the ability topredictcommunications

may

allow

managers

to

implement

appropriate organizational structuresbased

on

aproject'stask structure [Morelli, Eppinger,

and

Gulati 1995].

On

theother hand,

when

one canidentifythat

two

people or

two

groups need to share

information,it is important toassurethat thecorrect information

exchange

takes place.

Sometimes,

aninformal

method

suchasco-location byitselfisnotsufficient. For example, it is

important notto

make

theassumption that

two

engineers withdesks inclose proximity will

communicate

the necessary information toeach other. Additionally,

we know

from

Allen's

communication

vs. distancecurve [Allen 1977], thatitis unlikelythatengineers will

communicate

withotherengineers intheirdepartment ifthey are locatedseveral floors apart.

Furthermore, theavailability, transfer, and useof information areall distinctconcepts.

Co-location increases the availabiliiy ol the information, while transfer implies that theinformation

isappropriately disseminated. Use implies that theactual information is utilized. Co-location

does not necessarily ensure that the correct information will be transferred

and

used. In

particular,in novel situations,

where

itis imperative thattechnical information be transmitted to

a group relati\ely unfamiliar with the

new

requirements, firms mightconsiderutilizing multiple

informationchannels or gathering mcthcxls inorderto insure transferofthe correct information

and

effective utilization.

Architecture determinesthe feasibilityofco-location.

Ifasystem is simple enough, theneed forhigh-frequency interactions can be fulfilled

by

effectively co-Icx;ating the entire team. This approach is valid and successful forsmall projects

and teams.

When

thesystem iscomplex, the

same

rules

do

notapply. Ifthe team is large,the

reasons forco-locationare

no

longervalid.

Subsystem

dc\elopers

do

notneed to interface

directly \\ithall of thevehicle developersatall times. For example, an audio system team

may

need to

work

more

directly with theinstrument panel designteam during

some

part ofthe

product

development

cycle;during other partsofthe process theaudiosystem design

team

may

need to interface withthe wiring harness orcliirate control design team. Often, there exist

interactions

which

require technical expertise forashort time during the product

development

cycle.

Another

way

todeal with thesecomplexities is bytemporarily co-locating

one

or

two

key

engineers from the subsystem

development

team

on

the vehicleengineering team. Thisapproach

might be a feasible solution ifonlyone vehicle teamexisted.

However,

in realityeach of the

many

vehicle teams needsthe expertise ofasubsystems engineer. In addition, the subsystems

departmentitself

may

have its

own

needsandbe unwilling topartwithits engineer(s) foran

extended period oftime.

Given

that multiple types ofintegration exist(within productdevelopment teams, within system

teams

which

are

made

up

ofseveral productdevelopmentteams, and betweenexternal teams and

product

development

teams),

we

recognize thateachintegration is

most

difficult atthe larger

subsystem level

[McCord

and Eppinger 1993]. Additionally, past research has

shown

that

decomposition

becomes

easierattheinternal team level.

At low

levels, integration iseasy

because interactions occurin high frequencies over asmall cross-functional team.

At

higher

levels, interactions

become

more

occasional and less frequent as the team gets bigger.

Integration iseasy

ina

sma

1 team.

As

interactions

become

more

incidental and less

frequent, integration

becomes

more

difficult.

Figure 6. Interactions inanorganization

Lastly,awell understood interface between architectural chunks minimizes theneed for

ad

hoc

communications. Ifthe architecturecan bepre-planned

and

allthe interfaces can be

pre-specified, co-location

may

not benecessary. Furthermore, ifcomplexity isaccurately defined,

tradeoffs

between

complexity,quality, and productdifferentiationcan be thoroughly considered.

In ourstudy,

one

team dedicated toreducingcomplexity

championed

thecomplexity issue

without

due

regard tootherfactors, causing

many

decisions tobe re-examinedand resulting in

delays in theproduct

development

cycle.

B.

The

establishedorganizational capabilities

and

structures dictate architectural choices.

The

organi/ations thatmanufacture

complex

products such asautomobilesexhibit complexity in

many

facets.

Each

division, eachdepartment, each prcxiuctdevelopment team consists of

many

different internal andexternal networks.

Each

ofthese networks in turn helps todefine the

organizntion.

The

capabilities and structures ofthatorganization then influence architectural

design.

Sialic organizations give rise to staticarchitectures.

Results

from

our study validatedourpriorobservations thatfixed organizational structures

generate products

whose

architectures remain fairly ngid.

We

believe that this generalization

may

hold across

some

ofthemajororganization types(i.e. pure product, pure functionalor

matrix),

however

this hypothesis remains tobe testedin afuture study.

The

architecture is often

areflection oftheorganization. Iftheorganizational structure isstatic, the architecture is likely

to bethe

same

over

many

product generations. Integratingand changingthe architecture also

becomes

difficult.

The

longerthis cycle remains to be true, thestrongera prediction it becomes.

Gi\ en this premise, one might suppose splittingintoproject organizations, forexample,

would

facilitate having each productarchitecture slightlydifferent from the others, because each

organization isaproject team (i.e. eithera matrix or a

hybnd

thatcuts across all the traditional

functions, butdoes notnecessarilyutilize cross-functional expertise). It appearsthat the project

organization might be

more

adaptable to

new

architectures, because each project team isso

separate. Innovations inone architecture

may

be difficult to

implement

inthe otherproject team.

In fact,each particularorganization

may

be staticand therefore produce astaticarchitecture.

Additionally,pure projectorganizations lend to produce architectures reflectiNe ofthat particular

organizationratherthan thatofthe

company

as a whole.

The

products

may

also require

engineeringefforts thatare duplicated in othersegments ofthe corporation, hence

becoming

more

costly than necessary [Galbraith 1973]. Purefunctional organizations might be

more

dynamic

than pure product organizations (because theproduct organizationsare pooled

together), butthey are

more

likely to losesightofthe goalsofeach individual product's

architecture. Matrix organizations cansolve

some

oftheseproblems, but they have other

problems

which

are

beyond

the scope ofthisresearch.

When

considering organizational designs,

it is importantto recognize thatthereis

no

one best

way

toorganize andnotall the

ways

to

organizeare equallyeffective [Galbraith 1977].

Organizationalskills

and

capabilities affectarchitecture.

An

organization with specific skillssometimes chooses its architecture suchthat the impactof

thoseskills are

maximized

inordertogain acompetitive advantage.

As

Meyer

and Utterback

[1993] have

shown,

product families canbe a resultoftheunderlying corecapabilitiesofthe

organization. Furthermore, thecross-functional skills of a successful product

development

organization

and

effective synergies with thefirm's existingcompetencies can lead toaproduct

advantage

[Brown

and Eisenhardt 1995].

For

some

corporations, this

method

hasproven tobequiteeffective. For example, in 1933

Toyota's founder,

Toyoda

Kiichirooannounced,

"We

shall learnproduction techniques

from

the

American

method

of

mass

production. But

we

will not

copy

itas itis.

We

shall use our

own

research andcreativity todevelop aproduction

method

that suitsour

own

country'ssituation"

[Ohno

1988]. During the 1970sand 1980s,

Toyota

challenged

GM

forthe title ofthe world's

largest automobile manufacturer [Pine 1993].

Supplier relationshipscan affectarchitecture.

Managing

supplier-customerrelationships is a very

complex

task. Ignoringthe

interdependencies in thispartnershipcan have direconsequences later inthe product

development

cycle

[Kim

1993].

Some

ofthemajor

ways

in

which

automotivesuppliers have

been organized in ihc past have been either tobe dedicated supphersor ifthey weren't dedicated

suppliers, long term relationships had been established such that both the supplierand the

manufacturer underslcxxlone another's

mode

of operation and the manufacturer had the ability

then to anticipateand

know

w

hich supplier tocall

when

the time forearlysupplier involvement

came

around.

The

advantage ofsucha relationshipis thatpurchasing did not have to be

involved toqualify a

new

supplierand time

was

savedduring the prcxiuct

development

cycle.

In ourstudy, the suppliers

were

not dedicated, and

we

noticed that ifthe suppliers did not have

the

same

incentivesas the prcxiuct

development

teams, thequalityand the timelinessof the

interdependent tasks

was

poor.

We

surmise that this

may

be thecase because each of the

subteamsof the larger prcxiuct

development

team hasits

own

organizational allegiances or

personal agendas thatprecede their

commitments

tothe goalsofthe project. Furthermore, these

allegiances

may

exacerbate theproblem ofsub-optimizing thesmaller systems

by

creating

disincentives to globallyoptimize. In thecaseoithe suppliers, they

wanted

to

maximize

their

profits.

Sc^metimes,this can result in higher than necessarycnerall \chiclecosts if thesupplierdevelops

anarchitecture that reaches

beyond

the specifications ofthe original architecture.

An

understanding ofthe supplier'sagenda can allow oneto position the product such thatthe

suppliercan cither get

more

sales

volume

orutilize t'leireniiinecring expertise in otherprofit

making

\enturcs.

Lack

of

commitment

and/orlackofgoal alignmentfrom all segments ofthe

prcxiuct

development

team can bedue toa desire toappease upper

management

outside the

subsystem groupat the expenseof a prcxluct'sdesign, a desire fora vehicle

program

manager

to

make

aradical

change

late in thesubsystem

development

cycle, cultural differences in

geographically disparate departments,differentcompensation systems in different countries,or

different

employee

motivators in differentcultures.

Organizationaldesign of agloballydistributedteam affectsarchitecture.

Sometimes

there arecompelling reasons toglobally distributeamulti-national product

organizationwith global sales (e.g. keeping intouch with customers, beingclose to

manufacturing facilities, etc.).

Given

this global distribution,it

would

beideal to clusterthe

architecturesuchthat the high- frequency interactionstake place within eachsiteand

low-frequency interactionscan occuracross sites.

We

haveyet todemonstrate thatvirtual

co-location (using collaborative technologies suchas video conferencing,electronic mail,

distributeddatabases, Internet,

CAE,

etc.)iscomparable tophysicalco-location.

For example,

we

observed thataglobally distributed organizational structure can causedifficulty

in scheduling video-conference or tele-conference meetingsdue toverylittle overlapin the

workday

and difficultyincoordinating team projects

when

the team itselfis geographically

separated. Co-location is not always thecorrectanswer tothese problems.

Good

reasons for

co-location inalarge

team

include situations

where

thereis alotofhigh-frequencycommunication,

situations

where

interface specifications are notfullyspecified,orsituations

where

communication

needsare unpredictable.

Team

A

TeamC] sutvlciim"^ ^iib- learn (sub-lcam ftub-li-arrTl

t

well specified interface ^ub-teani (sub-lcam"] (Tulvleam^ poorlyspecified interface (^b-te;iin sub-tciim^ (fub-team"

Team B

TeamD

Figure7.

A

well specified interface between

Teams

A

and

B

allows for lessformal co-location methods.

However,

co-locating

Teams

C

and

D

would

facilitatethe high-frequency interactions.

Virtual co-kx;ation canea.se theproblem, but not alleviate itfully.

Although

some

research

(Hamen

and Nihtila 1995] indicates thatthe useofelectronic

communication

reduces the effect

of physical distance

on communication

activities, face toface

communication

is still necessary.

The

useofinformation technologiescan beenhanced ifthey are seenas atool to facilitate the

businessand integrated into the business.

Davidow

and

Malone

[1992] recognize that, "in years

to

come,

incremental differences in companies' abilit''?s toacquire, distribute, store, analyze,

and

invokeactions based

on

information will determine the winners andlosers inthe battle for

customers."

Goldman

[1995] affirms this research by mdicating that,"sharing theexpenseof

precompetiti\'e technology, facilities,and resources leaves

more

resources tospend on

customizing prcxluct features andservices thatprovide forcompetitive ad\antage.

The

goal is to

unite

complementary

core competencies in ordertoserve customers

whom

theseparate

companies

could not serveon theirown.

Each

member

ofthis type of \iilual organi/ation is

chosen because it brings

somethmg

unique that is neededto

meet

acustomeropptirtunity."

In theory, the virtualorganizationcan give a

company

access to

more

specializedcompetencies

than

any one

organizationcanafford tomaintain and henceconcurrently engineer

many

more

products.

However,

more

compelling studiesaboutthe effectiveness ofvirtual co-location in

isolation haveyet to becompleted.

Inourstudy,

one

ofthe vehicleprogramsutilizedresources

from

North

America

as well as

Europe.

The

satellite organization did notalwayshaveaccess toallofthe resources ofthe

home

organization tocomplete theirprojects. Ifthis is the case, the situation is easily rectified ifthe

home

organizationcaninsure thatits satelliteorganizationsareassigned

mdependently

executableprojects.

However,

there

must

be adequate information flow

between

the parent

organization and thesatellite inordertoutilizeeachorganization's resourceseffectively.

Lastly, co-locationshould not beconsideredthecompletesolution tothis problem.

Tyre

and

von

Hippel [1995] suggestthat thelocation itselfplays an integral roleina projectteam's efficacy.

They

believe that

managers

should consider

what

types of

knowledge and what

forms of search

are

most

important toateam's progressat anygiven time,and selectthe

work

location

accordingly.

Importance

of

effective

communication

Automotive

audio systems havetraditionally been designed bylargely

autonomous

organizations

eitherwithinautomobile manufacturingfirms orat supplier firms.

Sometimes

this typeof

organizational structurepromotes the visual styleofan audio systeminterface tobe very

different

from

the style ofthe vehicleitself. Recognizing this problem, the

US

auto industry has

placed greateremphasis

on

organizing vehiclelineteams. Inthis fashion, they

hope

to create

natural

communication

patterns between subsystem designers(e.g., audiosystems) and the

vehicle interiordesigners.

Organi7ati(>ns lend lo(Jc\clop languages ol ihcir

own

as people a

ho

sharea

common

set of

problems lend loshare shorihand

ways

ol

relemng

loactiviiiesand technologies. Technical

dcparlmcnls hire people

who

have been irained and

know

ihe languageofIhc deparlmcnl's

specially.

Such

a language pcrmils people lo

communicalc more

efficiently by transmitting

more

information with fewersymbols.

However,

despite the fact that specialized languages

increase efficiency withinadepartment, they decreaseefficiency betweenorganizations

[Galbraith 1973].

Many

ofthe interactions

we

studied involved these types of formal organizational ties.

However,

we

did observethai

much

ofthe necessarytechnical

communication

occurred through

the informal organizational networks. Krackhardt and

Hanson

11993] indicate thatalthough

these informal networks canexpeditedelayed initiativesandaid in meetingdifficultdeadlines,

theycan alsobl(x;k

communication

and

evoke

opp<isilion unless

managers

know

how

loidentify

and direct them. Moreover, Granovetter's [1973] research has

shown

thatsmall-scale

interactionscan be translated into large-scale patterns, that is the strengthof mtcrpersonal ties

can affect the political

makeup

of theorganization.

The

underlyingphilosophies _of

an

internationalcorporationoften

assume

globalease of

communication.

Architectural direction canbe very difficult to

communicate

acrossorganizations. For example,

even thesimplest explanationsofarchitectural characteristicscan be misinterpreted ifagroup

speaking

American

Englishconveys the

message

toa group speaking British English or agroup

speaking English translated from

German.

In the

company

that

we

studied, the European di\ision and the North

American

di\ision shared

only

human

capital until recently,

now

they alsoshare products.

Only

now

is this

compan\

experiencing the

growing

painsofglobalization as heightened bythedifferences in each

organization's decision models andunderstandings oforganizational processes.

As

Allison [1971]

showed

through hisanalysisofthe

Cuban

missilecrisis, the actsof

complex

organizations cannot be simply understood by analogyas the purposiveacts ofindividuals. This

simplification obscures the neglected factthatcorporate policy decisionsare not

made

by

one

decisionmaker,but ratherbythe bureaucraticresults of aconglomerate oflarge internal

organizations.

Social researchhas

shown

thatthecreationoflateral relations inan organization oftenprovides a

mechanism

which

reduces the quantityof decisionsreferred

upward

in thecorporatehierarchy.

Itis

assumed

thatinformal processes are necessaryand inevitable ina

complex

organization.

However,

when

alarge productdevelopment team iscomprised ofdiffering attitudes,contains

members

from

differentcountriesand is geographically dispersed, the effective useofjoint

decision

making

may

also requireaformally designed process [Galbraith 1973].

Identificationof internally efficientdepartments

which

arehindered bybarriers toexternal

communication

may

allow anorganization toselectaproductarchitecturesuch that the

high-frequency interactionsoccur inside departments ratherthan across departments.

Effectsoforganizationalculture

on

architecture.

Organizations as a

whole

show

patternsofbasic assumptions thatareinvented,discovered, or

developed

by

given groups asthey learn tocope withtheirspecific problems.

These

problems

include, butare notlimited to external adaptationand internal integration [Schein 1985].

Groups

withintheorganization

may

also exhibit their

own

distinct

group

culture.

Wc

observed that theshared experiences, knowledge, and understanding oftheorgani/iition

caused each group lo bring dillcrcnlassumptions with it tothe larger prcxlucl

dc\ciopmcnt

team

and as aresultaffected architecture decisions.

In one example, the

company

wanted todesign a singleaudio architecture forglobal use.

However,

engineering decisions regarding interlacesandconnections

became

ver>'difficult to

resolve.

We

laterfound thatthe Europeanengineers regard mcxiulanty (and upgradability)as

fundamental loa prcxluct's architecture, whereas the North

American

engineers f(x;us

more on

specific prcxluctand vehicle line features. Interestingly enough, this finding reOects notonlya

dilference in organizational cultures, butappears losuggestthat this difference is

due

todistinct

differences in the regional customers. This difference

may

affect thefirm's ability to

manage

the

discontinuity

between

present productsand

unknown

future productsand

hamper

athorough

understanding oftheirmarkets

and

customers [Dougherty 1987J.

The

managerial implications ofunderstanding a group'sculture includeenhancing

management's

abilityto utilizetacit, highly situated

knowledge

of

employees

suchas

machine

operators, secretaries,orcustomers [Tyre and von Hippcl 1995]. Tyre and

\on

Hippel [1995]

suggestthat observingthese kindsof

employees

in their normal

work

environment (i.e. their

sub-groupculture or shared values) allows

managers

todevelopa "contextualized appreciation" of

issues that these

employees

may

face.

Lastly, Foster [1986] has

shown

thattechnological change necessitates significantorganizational

change.

He

states that

companies

lose theirleadership notonly becauseof

weak

strategies, but

also because of strongcultures.

IV.

Conclusion

This paperdescribesourexplorationofthe linkagesbetween productarchitectureand

organizational design

by

bringing forthspecific examples solidifying the premisethat product

architectureand organizational designare notindependent. Infact, theyare interdependentand

affecteach otheras

we

have found throughourcase studies. For this study,

we

interviewed

members

ofaudio-system teams in

two

very differentorganizationsofalarge

American

automotive manufacturing firm.

We

found that the technical decisions relating to

decomposition,architecture

and

integrationare tightlycoupled toboth the capabilitiesand the

design oftheorganization

which

must executethedevelopment process.

We

observedin ourcase studies thatorganizations

do

simultaneously exhibit

mechanisms

of

productarchitecture affectingorganizational structure as well as patternsof organizational

structure affecting productarchitecture. Hence,

we

assert thatthetechnical architectureof a

product co-evolves with theorganizational design.

The

notionof co-evolution is a

dynamic

extension of

Conway's

earlierobservation thatorganizations create technical systemdesigns

which match

the

communications

structureofthe organization itself

[Conway

1968].

Decomposition

Product

Architecture

Organization

Design

Figure 8.

Problem

Relationships

We

proposea possible

mechanism which

may

help toexplainthis fundamentalcoupling:

architecture

and

organization arelinked through theprocess ofproblem decomposition and

system intcgralion. Dc\clopcrs handle

complex

system design challenges by

dccomposinu

the

large system \n[o simpler(incs

which

can then be designed or specified forouLsourcing. (This

decomfX")sition process is repealed until thesubsystemsare simple

enough

to tackle.)

At

some

point, the

development

organization'schallenge is tomtc^ratc the various pieces togetherintoa

complete

workmg

system. In fact, decomposition and integration arc generalized inverse

problems.

We

are ot" theopinion thatestablishingand following prcx'edures

which

take advantageof the

benefitsachie\ed through recognizing thecoupling ofthese decisionscan facilitate the product

development

process. Inappropriateor inllexiblearchitectural or organizational

frameworks

may

becurtailed. For example, ifan organiz.ation has evolved from being tcx)closelyaligned to

a very

modular

prtxlucl architecture, an understanding of co-evolution

may

catalyzea

more

balanced

move

towardsa

more

integrated organizational structure. Perhaps a

more

effective

malnx

structure can be formed.

Over

time the product architecture willchange atadifferentrate than thedesign of the

organiziition.

Even

though these changes happen slowly, it isessential to

acknowledge

the

couplingat thedecision level inordertoachieve thebenefitsofrecognizing their

interdependence. Itdoes notappear feasible for

new

generations ofarchitectural changes to far

exceed thatof thepace oforganizational rc-slructurng.

While

we

were

able to

make

stringobservations based

on

ourfield study,

many

ofour

conclusions arc merely speculative sincethis study representsonly a single classofprcxluct

design. Inorder tostrengthen theconclusions thatmightbe drawn, it

would

be useful toconduct

studies ofseveral different prtxlucts toconfirm the robustness ofourfindings. Additionally,an

exploration ofthe following research questions might al.so be infomiativc:

How

can the time

constantfor theorganizational change smaller thanthetime constantfor architectural change?

What

attributesof product plansand organizational design plans lendthemselves toenhancing

strategic planning?

What

types of organizationscan

more

easilyadopt

new

product

architectures? Is anorganization

where

themajorskills

and

capabilitiesof the peopleset the

parametersof theproductarchitectures

more

successful than onein

which

the product

architectures dictate theorganizational structure?

Can

requirements forhigh-frequencyand

low-frequency

communications

beidentified

by

apriori

knowledge

ofinterface specifications?

To

what

extent

do

collaboration technologieschangethenature oftechnical interactions inproduct

development?

Bibliography

Alexander, C. (1964). Notes

on

the Synthesisof

Form,

Harvard UniversityPress,

Cambridge,

Massachusetts.

Allen, T.J. (1977).

Managing

the

Flow

of Technology,

MIT

Press, Cambridge,

MA.

Allison, G. T. (1971). Essence ofDecision:Explaining the

Cuban

Missile Crisis, Little,

Brown,

and

Company,

Boston, Massachusetts.

Barczak, G.,and

Wilcmon,

D. (1991).

"Communications

Patterns of

New

FYcxiuct

Development

Team

Leaders."

IEEE

Transactions

on

Engineering

Management

,38(No. 2).

Bijker,

W.

E., Hughes,T. P.,and Pinch, T. P. (1987). The Social Construction of Technological

Systems:

New

Directionsin theSociology

and

Historyof Technology,

The

MIT

Press,

Cambridge,

Massachusetts.

Brown,

S. L.,

and

Eisenhardt, K.

M.

(1995). "PrcxiuctDevelopment: Past Research, Present Findings, and Future Directions."

Academy

of

Management

Review,20(4),343-378.

Christensen, C. M.,and

Rosenbloom,

R. S. (1995). "Explainingthe Attacker'sAdvantage:

Technological Paradigms, Organizational Dynamics, and the Value Network." Research

Policy(24), 233-257.

Clark, K. B. (1987).

"Knowledge,

Problem-Solving, and Innovation in the Evolutionary Firm: Implications forManagerial Capability and Competitive Interaction."

Working

Paper,

Harvard BusinessSchcx^l Division of Research, Boston,

MA.

Clark, K. B., and Fujimoto, T. (1991). Product

Development

Perfortnance: Strategy,

Organization,

and

Management

intlie

World

AutoIndustry,Har\ard Business School

Press,Boston,

MA.

Conway. M.

E. (1968).

"How Do

Committees

Invent?" Datamation, 14(4), 28-31.

Da\

idow,

W.

H.,and Malone,

M.

S. (1992). The Virtual Corporation, HarperBcx^ks,

New

York.

Dougherty, D. (1987).

"New

Products in Old Organiziitions:

The

Myth

o\' the Better

Mousetrap

in Search of theBeaten Path," Doctoral Dissertation,

MIT,

Cambridge,

MA.

Foster, R. (1986). Innovation: TheAttacker'sAdvantage,

Summit,

New

York.

Galbrailh,J. R. (1973). Designing

Complex

Organizations, Addison-Wesley, London.

Galbraith,J. R. (1977). Organizational Design,Addison-Wesley, London.

Galbrailh, J. R. (1994).

Competing

with Flexible Ixiteral Organizations, Addison-Wesley,

London.

Goldman,

S., Nagel, R., and Prciss, K. (1995). Agile Competitors

and

Virtual Organizations,

Van

Nostrand Rcinhold,

New

York.

Granovetter,

M.

S. (1973).

"The

Strengthof

Weak

Ties."

American

Journal ofSociology,7S(6),

1360-1380.

Hameri,A.,and Nihtila, J. (1995). "Distnbuted

New

Product

Development

Project

Based on

Electronic

Communication

-

A

Case

Study." Helsinki University ofTechnology,Finland.

Henderson,R. M.,

and

Clark, K. B. (1990). "Architectural Innovations:

The

Reconfiguration of

Existing

Systems

and theFailure of Established Firms." AdministrativeScience

Quarterly, 35(9-30).

Kim,

D. H. (1993).

"A

Framework

and

Methodology

forLinking Individual

and

Organizational Learning: Applications in

TQM

and Product Development,"Doctoral Dissertation,

MIT,

Cambridge,

MA.

Krackhardt, D., and Hanson,J. R. (1993). "Informal Networks:

The

Company

Behind

the

Chart."

Harvard

Business Review.

McCord,

K. R.,

and

Eppinger, S. D. (1993).

"Managing

the Integration

Problem

inConcurrent

Engineering."

Working

paperno. 3594,

MIT

SloanSchool, Cambridge,

MA.

Meyer, M., and Utterback, J. (1993).

"The

ProductFamilyand the

Dynamics

of

Core

Capability."Sloan

Management

/?^v/>vv(Spring),29-47.

Morelli,

M.

D., Eppinger, S. D.,and Gulati, R. K. (1995). "PredictingTechnical

Communications

inProduct

Development

Organizations."

IEEE

Transactions

on

Engineering

Management,

42(3), 215-222.

Moses,

J. (1995).

System

Design

and

Management

Semmar

Lecture,

MIT,

October 16,

1995

unpublished.

Ohno,

T. (1988). Toyota Production System:

Beyond

Large-ScaleProduction, Productivity

Press, Cambridge,

MA.

Pimmler, T. U.,and Eppinger, S. D. "IntegrationAnalysis ofProductDecompositions."

ASME

Conference

on Design

Theory

and

Methodology

,Minneapolis,

MN,

343-351.

Pine,J. B. (1993).

Mass

Customization, Tlie

New

Frontier inBusiness Competition,Harvard

Business SchoolPress, Boston.

Rechtin, E. (1991). SystemsArchitecting: Creating

and

Building Cotnplex Systems, Prentice

Hall,

Englewood

Cliffs,N.J.

Rosenthal, S. R. (1991). EffectiveProductDesign

and

Development:

How

to

Cut

Lead

Time

and

Increase

Customer

Satisfaction.,Business

One

Irwin,

Homewood,

Illinois.

Sanderson, S., and Uzumeri,

M.

(1995).

"Managing

productfamilies

The

case ofthe

Sony

Walkman."

Research

Policy, 24,761-782.

Schein, E. H. (1985). Organizational Culture

and

Leadership:

A

Dynamic

View, Jossey-Bass

Publishers, Washington, D.C.

Simon,

H.A. (1990).

The

Sciences_oftheArtificial,

MIT

Press, Cambridge, Massachusetts.

Tyre,

M.

J.,

and von

Hippel, E. (1995).

"The

Situated Nature of

Adapted

Learning in

Organizations."

Working

paper no. 356S,

MIT

Sloan School of

Management

working

pap)cr.

Ulrich, K. (1995).

"The

Role ofProductArchitecture in the ManufacturingFirm." Research

Policy, 24{3),419-441.

Ulrich, K., and Eppinger,S. (1995). ProductDesign

and

Development

,

Mc-Graw

Hill, Inc.,

New

York.

Uzumcn,

M., and Sanderson, S. (1995).

"A

framework

for

model

and product family competition." ResearchPolicy, 24, 583-607.

von

Hippel, E. (1990).

"Task

Partitioning:

An

Innovation Process Variable."

Research

Policy

79,407-418.

Wheclwnght,

S.

C,

and Clark, K. B. (1992). RevolutionizingProduct Development,

Quantum

Leaps

in Speed, Efficiency,

and

Quality,

The

Free Press,

New

York.

3^27

U68

3

Jilllll

3 9080_009879120