1. Three Views of Product Development Complexity
Prof. Steven D. Eppinger
Massachusetts Institute of Technology
Sloan School of Management
Engineering Systems Division
Center for Innovation in Product Development
MIT ESD
©2000 Steven D. Eppinger
Lean Aerospace Initiative Plenary Conference April 10, 2001

2. Information Density in Complex Product Development
400 people
5000 part numbers
2000 significant parts
125 subassemblies
2000 drawings
12,000 problems
~1,000,000 decisions
~1,000,000 info. flows
Office copier by Xerox
complex product = system

3. Three Perspectives to Study Development of Complex Systems
Product/System-level
Process-level
Organization-level
Planning
Concept
Development
System-Level
Design
Detail
Testing and
Refinement
Production
Ramp-Up

4. System Decomposition
Decompose a complex system into sub-systems and components
Decompose a complex process into sub-processes and tasks
Decompose a large organization into teams and individuals

5. Decompositions Exhibit Architectures
The pattern of interactions between the decomposed elements define the architecture
System architecture
Process architecture
Organization architecture

6. Decompositions Exhibit Architectures
The pattern of interactions between the decomposed elements define the architecture
System architecture
Process architecture
Organization architecture

7. Potential Complexity Metrics
The number of elements determines the complexity of the decomposition
The uncertainty of elements determines their difficulty in development and integration
The pattern of interaction among the elements indicates the complexity of the architecture
The alignment of the patterns determines the difficulty of developing the system in context
Uncertainty of Elements ?
Number of Elements
Pattern of Interactions
Alignment of Patterns

8. An Approach to Studying the Patterns
We can study the patterns of interactions in three perspectives in order to better understand system complexity:
System example: Pratt & Whitney 4098 jet engine
Process example: Intel semiconductor development
Organization example: GM Powertrain organization
We can also compare the patterns across the perspectives:
System vs. Organization example: Pratt & Whitney engine
Process vs. Organization example: electrical connectors

9. System Architecture Example: P&W 4098 Jet Engine
9 Systems
54 Components
569 Interfaces
Design Interfaces:
Spatial, Structural
Energy, Materials
Data, Controls
HPC
Modular Systems
Distributed Systems
LPC
HPT
LPT
B/D
FAN
Mechanical Components
Externals and Controls (2)

10. Lessons Learned: System Architecture
Hierarchical system decompositions are evident.
System architecting principles are at work.
There is a disparity between known interfaces and unknown interactions.
Integrating elements may be functional and/or physical.
Hypothesis: Density of known interactions–
novel
experienced
mature
learning
optimization
sparse
dense
clustered

11. Process Architecture Example: Intel Semiconductor Development Process
inside

12. Lessons Learned: Process Architecture
Information flows describe the PD process more completely than task networks.
PDTs report their inputs more reliably than their output flows.
We find parallel and sequential stages within the (CDIO) phases of the PD process.
Planned iterations can be facilitated to accelerate the process.
Unplanned iterations require special attention to make the process more robust.

13. Organization Architecture Example: Engine Development
Organization: General Motors Powertrain Division
Product: “new-generation” engine (small-block V8)
Structure: 22 PDTs involved simultaneously

14. Decomposition of the Engine Development Project
22 PDTs
PDT composition
Design
Engine

15. PDT Interactions

16. System Team Assignments
Short Block
Valve Train
Engine Block Pistons
Crankshaft Connecting Rods
Flywheel Lubrication
Cylinder Heads
Camshaft/Valve Train
Water Pump/Cooling
Induction
Emissions/Electrical
Intake Manifold Air Cleaner
Accessory Drive Throttle Body
Fuel System A.I.R.
Exhaust Electrical System
E.G.R. Electronic Control
E.V.A.P. Ignition

17. Existing System Teams

18. Proposed System Teams

19. Electronic Control Module PDT-to-System-Team Assignments
Exhaust
E.G.R.
Team 3
Team 1
Team 2
A.I.R.
E.V.A.P.
Fuel System
Air Cleaner
Throttle Body
Water Pump/
Cooling
Flywheel
Connecting Rods
Crankshaft
Pistons
Engine Block
Lubrication
Cylinder Heads
Intake Manifold
Camshaft/
Valve Train
Accessory Drive
Electrical System
Engine Assembly
Ignition
Electronic Control Module
Integration Team
PDT-to-System-Team Assignments

20. Lessons Learned: Organization Architecture
Organization architecture can also be mapped in terms of interactions – across individuals or PDTs.
We usually find a (partial, at least) one-to-one mapping from system decomposition to organization structure.
Organizations can be designed based on the underlying technical structure of the system being developed.
Co-Evolution Hypotheses:
Organizations evolve to address deficiencies in their ability to implement the system architecture.
System architectures evolve to address deficiencies in the development organization.
Arch
Org

21. Comparing the System Architecture to the Organization Architecture
Product Decomposition
into Systems
Development Organization
into Teams
Technical interactions
define the architecture
Team interactions implement the architecture
How does product architecture drive development team interaction?

22. Research Method: Mapping Design Interfaces to Team Interactions
Resultant Matrix No
Team
Interaction
Design Interface Matrix
Yes
Yes No
Design Interface
Task assignment assumption: Each team designs one component
Team Interaction Matrix

23. Design Interfaces: P&W 4098 Jet Engine
9 Systems
54 Components
569 Interfaces
Design Interfaces:
Spatial, Structural
Energy, Materials
Data, Controls
HPC
Modular Systems
Distributed Systems
LPC
HPT
LPT
B/D
FAN
Mechanical Components
Externals and Controls (2)

24. Development Organization: P&W 4098 Jet Engine
Low intensity interaction
60 design teams clustered into 10 groups.
Teams interaction intensity:
Capture frequency and importance of coordination-type communications (scale from 0 to 5).
Interactions that took place during the detailed design period of the product development process.
Design executed concurrently.
High intensity interaction
Six system integration teams
Team Interactions

25. Overall Results 228 (8%) 2225 (78%) 341 (12%) 68 (2%)No
(2453)
228
(8%)
2225
(78%)
Team
Interactions
341
(12%) 68
(2%)
Yes
(409)
Yes
(569) No
(2293)
Design Interfaces
We reject the null hypothesis that “team interactions are independent of design interfaces”.
2 = 1208 >> Critical 2(0.99,1) = 6.635

26. Design Interfaces Not Matched by Team Interactions
(2453)
(40.1%)
(59.9%)
Team
Interactions
Yes
(409)
Yes
(569) No
(2293)
Design Interfaces
HYPOTHESES:
H1: Across boundaries, design interfaces are less likely to be matched by team interactions.
H2: Weak design interfaces are less likely to be matched by team interactions.

27. Effect of Organization/System BoundariesNo
Team
Interactions
Data set: 569 design interfaces
Yes
Yes No
Design Interfaces
First criterion:
Design interfaces matched
by team interactions
59.9%
Design interfaces NOT
matched by team interactions
40.1%
Design interfaces
WITHIN organizational
boundaries
ACROSS organizational boundaries
Second criterion:
78.8% are
matched
47.8% are

28. Data set: 569 design interfaces
Effects of Organizational/System Boundaries (modular vs. integrative systems) No
Team
Interactions
Data set: 569 design interfaces
Yes
Yes No
Design Interfaces
Overall:
36.4% of ACROSS
design interfaces
are matched
53.2% of ACROSS
Design interfaces
WITHIN organizational
boundaries
78.8% are
matched
47.8% are
Design interfaces
ACROSS organizational boundaries

29. Lessons Learned: Architecture and OrganizationNo
Team
Interactions
Yes
Yes No
Design Interfaces
We can predict coordination-type communications by studying the architecture of the product
83% of coordination-type communication were predicted
Teams that share design interfaces may not communicate when
Design interfaces cross organizational boundaries
Design interfaces are weak (within organizational boundaries)
Teams communicate indirectly through other design teams (across organizational boundaries)
Teams that do not share design interfaces may still communicate when
Unknown design interfaces are discovered
Design interfaces are system-level dependencies

30. Lessons Learned about Development of Complex Products
Product (system) complexity must be considered in the context of the process and organization which are developing it.
Processes and organizations can be designed to facilitate development of specific product architectures.
System concepts such as modularity and architectural knowledge apply at the level of sub-system interactions.