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 eppinger@mit.edu http://www.mit.edu/people/eppinger/ http://web.mit.edu/dsm Lean Aerospace Initiative Plenary Conference April 10, 2001

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

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

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

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

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

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

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

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)

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

Process Architecture Example: Intel Semiconductor Development Process inside

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.

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

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

PDT Interactions

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

Existing System Teams

Proposed System Teams

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

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

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?

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

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)

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

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

Design Interfaces Not Matched by Team Interactions (2453) 228 2225 341 68 (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.

Effect of Organization/System Boundaries No 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

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

Lessons Learned: Architecture and Organization No 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

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.