Coordination Networks in Product Development

Transcription

1 10 Coordination Networks in Product Development Manuel E. Sosa Abstract Complex products such as airplanes and automobiles are designed by networks of design teams working on different components, often across organizations. The challenge in managing these networks is to decompose the project into manageable pieces but then coordinate the entire network to produce the best overall design. In this chapter, Manuel Sosa offers insights on this challenge. He examines the design structure matrix (DSM) as a project management tool for planning complex development efforts and discusses the engineering and managerial implications of considering complex products as networks of interconnected subsystems and components. In particular, he considers the impact of modularity on interactions among subcomponents. Finally, he examines organizational communications, overlaying product interfaces with communications interfaces of development teams to understand where communication links may be missing or unnecessary. The discussion offers insights on any complex design and coordination challenge, where networks of individuals or teams work together to contribute to a larger whole. Designing new and complex products requires the interplay of processes, products, and structures across networks of individuals and organizations. From a network perspective, processes are networks of design tasks, products are networks of interconnected components, and organizations are networks of developers or design teams that interact when executing design tasks to develop new products. Because managing 165

2 166 THE NETWORK CHALLENGE interdependences is fundamental to developing new products, taking a network perspective can advance our understanding of how to coordinate resources in complex development efforts. Coordination is the result of both system decomposition and system integration. For example, in developing a product such as an airplane, managers decompose the overall project into manageable pieces. Hundreds of specialized cross-functional teams each work on a different component or subsystem of the airplane. Of course, these teams cannot work in isolation; they must integrate and coordinate their efforts to ensure that the system works as a whole. In planning a complex product development process, project managers need to plan and specify just which resources and information different teams will need from each other at particular stages of the project (Sosa, Eppinger, and Rowles 2007b, Sosa 2008). As we discuss in this chapter, product development managers in large organizations such as Airbus, Ford, or BMW often find themselves lost in their web of design activities and engineering teams, all trying to do the best they can to design their individual piece of the system. Only by taking a network perspective can we navigate the intricate web of activities associated with the design of each of the product components, which is what determines how designers ultimately communicate among themselves during the development effort. This chapter is structured in three sections: First, I review the product development literature focused on the use of the design structure matrix (DSM) as a project management tool that captures development processes as a web of design tasks. Second, I discuss the engineering and managerial implications of considering complex products as networks of interconnected subsystems and components. Finally, I turn to the informal organizational structure to understand how design teams establish and manage their technical communication networks during the design of complex systems. The Development Process as a Web of Design Activities In the early 1980s, BMW used to take about six years to complete a new vehicle development. A particularly important milestone in such a long process used to occur 18 months before product launch. That was the date on which the vehicle concept would be frozen so that detailed engineering could be completed, final prototypes built,

3 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 167 and production ramp-up started. During the development of the first 7 Series in the mid-1980s, managers at BMW decided to widen the entire vehicle by 40 millimeters just two months before completely freezing the design of the car. This, of course, required redesigning more than one-third of the parts in the vehicle. Yet managers at BMW have agreed that, although costly, carrying out such a major design iteration was strictly necessary to avoid making the car too cramped. Without such a costly decision, the original 7 Series would never have succeeded in the market like it has (Pisano 1996, 6). Although I will not discuss here the specific causes behind this design decision at BMW, this example helps us to illustrate vividly what design iterations are as well as their cost and performance consequences. Design iterations are the repetition of design tasks due to the arrival of new or more complete information during the development of a new system. Complex products are particularly vulnerable to design iterations because they are complex engineering efforts involving many highly interdependent design activities (Smith and Eppinger 1997b; Mihm, Loch, and Huchzermeier 2003; Sosa, Eppinger, and Rowles 2004). Which design activities are likely to be involved in design iterations? What can managers do to mitigate the negative effects of design iterations? Who is more likely to be involved in design iterations? These are some of the questions that product development managers need to address when planning the development of complex systems such as automobile, airplanes, or jet engines. Traditional project manager tools such as PERT charts and IDEF diagrams have been typically used during the planning of complex projects. However, because these tools have been devised to plan more sequential engineering efforts such as the ones encountered in the construction industry, they are limited in their capability to explicitly portray design iterations (Eppinger 2001). To address such limitations, Steward (1981) introduced a matrix-based tool called the design structure matrix (DSM), which captures the web of design activities in a product development process. Eppinger et al. (1994) extended the use of DSM-based models to improving complex product development efforts by highlighting the task dependencies that managers can encounter in the process. A DSM is a square matrix whose rows and columns are identically labeled with the design tasks of a development process (see Figure 10-1). In its simpler form, the nonzero cells of a DSM indicate the existence of an information requirement between two development activities. That is, a mark in cell (i,j) indicates that task i needs information produced by task j in order to be completed. Hence, by examining row i of a DSM, managers can easily identify the other tasks that provide information to task i, and

4 168 THE NETWORK CHALLENGE by examining column j, managers can easily determine which other tasks are using the information produced by task j. As a result, the DSM captures in a compact and visual manner the web of activities that form a development process as determined by the development tasks and their task dependencies. For a review on the various uses of the DSM to improve product development efforts, refer to Eppinger et al. (1994), Eppinger (2001), and Browning (2001). Figure 10-1 A generic design structure matrix The DSM also captures the order in which activities are sequenced. Typically, the rows (and columns) are ordered in the chronological sequence in which activities are to be executed, from product planning to product launch. Such a chronological arrangement of the rows (and columns) of the DSM allows managers to distinguish between marks below and above the diagonal. Whereas marks below the diagonal are considered feed-forward dependencies because they occur between activities that can be executed in a sequential manner, marks above the diagonal represent feed-back dependencies because they indicate that a design task requires information from another task that will be executed in the future. Therefore, marks above the diagonal represent sources of design iterations because they indicate the arrival of new or updated information that may trigger the rework of a series of design activities. For example, task B in Figure 10-1 would need information from tasks G and J, which are to be executed later in the process. Hence, the arrival of new or updated information to task B may force the team responsible for such a task to revise or rework part of the activities associated with it, which, in turn, can trigger other changes in other design tasks that depend on task B.

5 Of course, some of these sources of design iterations can be removed by simply resequencing the DSM to minimize marks above the diagonal (Steward 1981; Eppinger et al. 1994), that is, making the development process as sequential as possible (see Figure 10-2). By examining the resequenced (or optimally partitioned) DSM (see Figure 10-3), managers can identify the set of activities that could be executed in a serial fashion (sequential dependency) or those that are independent from each other (parallel dependency). More interesting, managers can also identify the set of design activities that depend on each other in a cyclical manner (coupled dependency). Those are the interdependent (or coupled) development activities that are likely to result in design iterations (Smith and Eppinger 1997a,b). CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 169 A B C D E F G H I J K L A B C D E F G H I J K L B C A K L J F I E D H G B C A K L J F I E D H G Swap rows and columns to make a lower triangular DSM Figure 10-2 Partitioning a DSM into a low triangular DSM B C A K L J F I E D H G B C A K L J F I E D H G Sequential Parallel Coupled Figure 10-3 Partitioned DSM and types of task dependencies (Eppinger et al. 1994)

6 170 THE NETWORK CHALLENGE An Example from Automobile Design As an example, Ulrich and Eppinger (2004) examine the task structure used by Fiat to develop the digital mock-up of its engine compartments, as shown in Figure The blocks along the diagonal of such a DSM highlight the groups of activities that are executed together (in parallel, sequentially, and/or iteratively) within each phase. As evident from Figure 10-4, an important contribution of a DSM representation is the simple and explicit representation of complex and iterative processes in which design iterations can be easily highlighted. Responsible Activity a b c d e f g h i j k l m n o p q r s t u v w x y z aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt uu vv ww xx Top Management Approve product architecture/configuration a a a Layout Team Leader Define extended layout team b b b Systems Determine project quality objectives c c c Layout Team Leader Establish the need for prototypes d d d Systems Establish prototype specifications e e e Layout Team Leader Establish DMU, PMU and prototypes to be developed f f f Layout Team Leader Prepare activity/resource plan g g g Systems Approve layout team leader's activity/resource plan h h h Planning Verify the feasibility of the LO team's plan with other plans i i I Systems Approve no. of DMU, PMU and prototypes to be developed j j j Layout Team Leader Verify that planning phase is complete k k k Platform Director Authorize go ahead to next phase l l l Concurrent Engineering Provide CAD models in PDM m m m Styling Center Provide style models n n n Core Layout Team Extract CAD models from PDM o o o Concurrent Engineering Convert non-standard CAD models p p p Core Layout Team Construct DMUs from CAD models q q q Core Layout Team Verify DMU completeness r r r Layout Team Leader Review issues document from past project s s s Core Layout Team Define volumes for new components t t t Core Layout Team Construct DMU for the verification process u u u Layout Team Leader Request missing CAD models v v v Concurrent Engineering Provide missing CAD models in PDM w w w Core Layout Team Verify DMU using checklist # x x x C ore Layout Team Verify style compatibility y y y Core Layout Team Prepare alternate solutions z z z Core Layout Team Analyze issues with appropriate members of the layout team aa aa aa Extended Layout Team Verify overall DMU with all stakeholders bb bb bb Project Planning CAD Data Collection DMU Preparation DMU Verification Core Layout Team Update issues document cc cc cc Concurrent Engineering Modify CAD models dd dd dd Styling Center Modify styling ee ee ee Core Layout Team Modify component positioning in DMU ff ff ff Extended Verifications Top Management Select two models of style gg gg gg Core Layout Team Freeze DMU (STEP1) hh hh hh ii Layout TL/Production TechDefine information required for assembly process ii ii jj Core Layout Team Specify component connectivity constraints jj jj kk Concurrent Engineering Perform detail design for component connectivity kk kk Production Technology Verify assembly feasibility ll ll ll Safety Center Verify safety objectives mm mm mm Vehicle Maintenance Verify vehicle maintenance feasibility nn nn nn Layout Team Leader Establish/communicate modifications to be done oo oo oo Top Management Select one model of style pp pp pp Core Layout Team Freeze DMU (STEP 2) qq qq qq Core Layout Team Verify that all critical CAD models are present rr rr rr Core Layout Team Prepare reference list of CAD drawings for prototyping ss ss ss Testing Build prototypes for design validation (DV1) tt tt tt Road Testing Run experiments on prototypes uu uu uu Core Layout Team Verify project quality objectives vv vv vv Platform Director Authorize go ahead to next phase ww ww ww Layout Team Freeze DMU (STEP 3) xx Core xx xx a b c d e f g h j i k l m n o p q r s t u v w x y z aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt uu vvwwxx Figure 10-4 Process to develop digital mock-ups at Fiat (courtesy of Steven Eppinger, Ulrich and Eppinger 2004, p. 356; The McGraw-Hill Companies, Inc.) Figure 10-5 provides a closer look at the highly iterative set of activities involved in one phase, DMU verification. It shows which organizational group is responsible for executing each design activity. Note that the group of design activities exhibited in Figure 10-5 forms a highly interdependent network of tasks. As a result, managers must pay particular attention to facilitating the information exchanges between the people responsible for this set of activities. Some information exchanges require more managerial support than others. In particular, managers have to be more actively involved in cross-boundary coordination, when iteration is across people from different organizational groups as opposed to people from the same organizational group.

7 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 171 Responsible Core Layout Team Layout Team Leader Concurrent Engineering Core Layout Team Core Layout Team Core Layout Team Core Layout Team Extended Layout Team Core Layout Team Concurret Engineering Styling Center Core Layout Team Activity Construct DMU for the verification process Request missing CAD models Provide missing CAD models in PDM Verify DMU using checklist #80195 Verify style compatibility Prepare alternate solutions Analyze issues with appropriate members of the layout team Verify overall DMU with all stakeholders Update issues document Modify CAD models Modify styling Modify component positioning in DMU u v w x y z aa bb cc dd ee ff u v w x y z aa bb cc dd ee ff u v w x y z aa bb ccc dd ee s Interdependence within the same group Interdependence across groups Figure 10-5 Iterative design tasks of FIAT s DMU verification phase In addition to identifying the subset of highly interdependent design activities that are likely to generate design iterations, managers need to understand the specific nature and criticality of the task dependencies of these coupled activities. In the FIAT example, to manage the interdependent design tasks shown in Figure 10-5, managers needed to know which specific engine components and CAD models were involved and how they were connected to one another. In other words, executing the development process shown in Figures 10-4 and 10-5 depends largely on the specific configuration of the product under development, as well as the organization and experience of the people involved. Hence, to effectively manage design iterations in product development, managers have to examine the architecture and organizational structure associated with the development process. This approach illustrates how a network view of product and organizational structures can improve the design and execution of complex product development processes. We now shift our view from the organizational processes to considering the products themselves. Complex Products as Networks of Components While complex products result from a network of interlinked design activities, as discussed previously, the products themselves can be seen as networks of interconnected components (Simon 1981). Product decomposition determines the architecture of the product, which is the way components interface with each other, so the product can fulfill its functional requirements (Ulrich 1995, Ulrich and Eppinger 2004). Moreover, the product architecture results in identifiable design interfaces between its various components (Henderson and Clark 1990; Ulrich 1995; Sosa, Eppinger, and Rowles 2007a). These interfaces, in turn, are the main source of technical interdependencies

8 172 THE NETWORK CHALLENGE between the design teams responsible for the development of such components, requiring coordination between them (Thompson 1967, Galbraith 1973). Considering products as networks of components has resulted in two important streams of research in engineering design: 1. Product decomposition Researchers decompose complex products using graphs, trees, and matrices (Michelena and Papalambros 1995; Chen, Ding, and Li 2005), paying particular attention to the identification of clusters of similarly dependent components (also called modules) to facilitate integration efforts during the design process (Pimmler and Eppinger 1994; Gershenson, Prasad, and Allamneni 1999; Sharman and Yassine 2004). 2. Design change propagation Researchers also have used product-based DSMs to examine how design changes propagate through interconnected components during the design process (Clarkson, Simons, and Eckert 2004; Eckert, Clarkson, and Zanker 2004). Because components are connected with each other to fulfill the functional requirements of the product as a whole, engineering changes in one component are likely to affect other components. Although the two areas of research previously described have had a great influence in the way complex engineered products are architected and developed, the focus has been on studying the product network as a whole rather than on structural properties of the components as a function of their connectivity with other components. To address this limitation, Sosa, Eppinger, and Rowles 2007a examine modularity of a component, defined as its level of independence from the other components. By doing so, we are able not only to quantify component modularity as a function of the lack of centrality of the component with respect to other components in the product (Freeman 1979, Wasserman and Faust 1994), but also to relate how the modularity of product components relates to important design decisions such as component redesign. Two important, and challenging, considerations when modeling complex products as networks of components are (1) defining the level of granularity at the node level; and (2) defining the various types of linkages between any two given components. To illustrate how we have addressed these challenges, consider the architecture of a large commercial aircraft engine developed by Pratt & Whitney (Sosa, Eppinger, and Rowles 2003, 2007a). Figure 10-6 shows both a cross-sectional diagram of the engine studied and its network representation. According to our interviews with systems architects at the research site, the engine was decomposed into eight subsystems, each of which was

9 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 173 further decomposed into 5 to 10 components, for a total of 54 components. As a result, there are 54 nodes in the network map shown in Figure The nodes are colored to illustrate the eight subsystems that composed the engine: Fan, Low-Pressure Compressor (LPC), High-Pressure Compressor (HPC), Combustion Chamber (CC), High- Pressure Turbine (HPT), Low-Pressure Turbine (LPT), Mechanical Components (MC), and External and Controls (EC). Because this was the third engine derived from the same basic engine design, the product decomposition into subsystems and components was well understood by our informants, and corresponded with the level of granularity used to establish the organizational structure that designed each of the 54 components. Using a higher level of granularity at the subsystem level would have resulted in a network of only eight nodes corresponding to the eight subsystems of the engine, while using a lower level of granularity would have resulted in several hundreds (perhaps thousands) of parts whose individual functionality did not correspond with any important functional requirement of the engine. Using the engine component, also called engineering chunks (Ulrich and Eppinger 1994), as the unit of analysis allowed us to represent the engine based on individual elements associated with important functional requirements with dedicated cross-functional teams responsible for their design and development. Figure 10-6 Cross-sectional view and network diagram of the PW4098 aircraft engine After documenting the general decomposition of the product, we identified the network of design dependencies among the 54 components of the engine. We distinguished five types of design dependencies to define the design interfaces (or linkages) of the physical components (see Table 10-1). In addition, we used a five-point scale to capture the level of criticality of each dependency for the overall functionality of the component in question (see Table 10-2), which captures positive or negative design dependencies between components, those that either enable or hinder the component s functionality

10 174 THE NETWORK CHALLENGE (Jarratt, Clarkson, and Eckert 2004). We consider three levels of criticality: indifferent (0), weak (-1,+1), and strong (-2,+2), because we assume that negative component interactions indicate equally important design dependencies to be addressed as positive ones. For additional details on metrics and linkages between product components in complex products, refer to Sosa, Eppinger, and Rowles (2003, 2007a). TABLE 10-1 Dependency Spatial Structural Material Energy Information Types of Design Dependency Description Functional requirement related to physical adjacency for alignment, orientation, serviceability, assembly, or weight Functional requirement related to transferring loads or containment Functional requirement related to transferring airflow, oil, fuel, or water Functional requirement related to transferring heat, vibration, electric, or noise energy Functional requirement related to transferring signals or controls TABLE 10-2 Measure Level of Criticality of Design Dependencies Description (+2) Dependency is necessary for functionality. (+1) Dependency is beneficial but not absolutely necessary for functionality. (0) Dependency does not affect functionality. (-1) Dependency causes negative effects but does not prevent functionality. (-2) Dependency must be prevented to achieve functionality. Those components that are less connected to other engine components are more modular because they have more degrees of freedom to fulfill their functional requirements independently of the state of other engine components. Less modular components, which are more integrally connected (via nonstandardized interfaces) to other engine components, are more dependent on other components to fulfill their functional requirements. Interestingly, components in complex products exhibit large variation in terms of their interconnectivity within the product. Figure 10-7 shows two engine components with extreme levels of component modularity.

11 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 175 Figure 10-7 Two engine components with the low and high levels of connectivity Modularity is important because managers should consider the connectivity of components with other components when making important design decisions such as outsourcing or redesigning product components. For example, we found that those components of the engine that were more (directly and indirectly) connected to transmit forces (an important engine functional requirement) to other components were the ones that exhibited higher levels of component redesign, whereas those components that were more connected due to spatial consideration (an important design constraint) were the ones that exhibited lower levels of component redesign. Hence, the modularity of a component in a complex product can be associated with both high and low levels of component redesign. Managers can use the knowledge of linkages among components to propagate design decisions or to avoid redesigning some components to prevent propagating design constraints that could disrupt certain functional requirements of the product (Baldwin and Clark 2000; Sosa, Eppinger, and Rowles 2007a). In addition to understanding how process networks and networks of components come together in designing complex products such as an airplane or automobile, managers also have to understand how the organization actually coordinates the technical interfaces between the components they design (Allen 1977), as considered in the next section. The Informal Communication Network of Design Teams Communication among design teams working on specific product components is crucial to success, as can be illustrated by two cases. In 1999, the Ford Explorer went from being the number one sport utility vehicle (SUV) sold in USA to the least desired one due to quality problems associated with the suspension system of the Ford Explorer

12 176 THE NETWORK CHALLENGE and the design of its Bridgestone/Firestone tires. Ford and Bridgestone/Firestone lost billions of dollars after their failure to coordinate the vehicle design of the Ford Explorer with the design of its tires (Pinedo, Sehasdri, and Zemel 2000). Similarly, Airbus s development of the A380 superjumbo suffered major delays and cost overruns because of late-emerging incompatibilities in the design of the electrical harnesses of various sections of the plane s fuselage. In this case, the electrical harnesses team in Germany and its counterpart team in France, which were responsible for different sections of the fuselage, were not properly communicating about their design interface specifications (Gumbel 2006). These mistakes likely contributed to the resignation of CEOs and the loss of other senior executives jobs at both Ford and Airbus. Although attention to technical interfaces is crucial for successful product development, teams typically ignore (or pay marginal attention to) a number of interfaces during the development process (Sosa, Eppinger, and Rowles 2004). Some level of neglect is perhaps unavoidable given the cognitive and resource limitations of teams (Simon 1947). Although lack of attention to noncritical or standardized interfaces may not be significant (Sosa, Eppinger, and Rowles 2004), the neglect of critical interfaces can have serious negative consequences (Henderson and Clark 1990). To address this challenge, we need to examine both the architecture of the product and the informal organizational structure. The technical interfaces among product components define the coordination requirements, and technical communication among design teams constitutes one of the primary coordination mechanisms. Figure 10-8 shows a network of technical interfaces between four components and a network of technical communications between six teams, four of which are in charge of designing these components and two others of which are in charge of integration activities (Sosa, Gargiulo, and C. Rowles 2007). Figure 10-8 Hypothetical networks of components and design teams

13 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 177 By superimposing the maps of product interfaces onto the technical communication structure, we can understand where communications links are missing or may be unnecessary. Managers can identify not only the technical interfaces that are matched by technical team interactions (links a, b, and c) but also the cases of mismatches of component interfaces and team interactions. There are two types of mismatches: unmatched interfaces, also called unattended interfaces, such as link d in Figure 10-8, in which a technical interface is not attended by technical communication between corresponding design teams; and unmatched interactions such as link e in Figure 10-8, in which teams communicate for technical reasons even though the system architects had not identified technical interfaces between their components. Finally, there are also external interactions that occur when teams that are not directly responsible for the design of a component interact with teams designing components. This may be the case with teams that are in charge of overseeing the integration among different aspects of the design but are not responsible for designing any specific component, as is the case with teams 5 and 6 in Figure Most of the complex development projects we have studied in the automobile and aerospace industries exhibit this quasi-direct mapping of product architecture and organizational structure; that is, component is designed by team with a few system integration teams in charge of evaluating product-level requirements (for example, the fuel economy of an automobile or the weight requirements of an airplane). In some projects such as software development, however, mapping the architecture and organization is far from one-to-one. (In such cases, we can still adapt the approach described in this chapter; refer to Sosa 2008 for details.) Although Figure 10-8 shows a simple example, overlaying the actual maps of product and organizational interfaces for a product such as the Pratt & Whitney engine we have studied is a daunting task (see Figure 10-9). As a result, we use a matrix representation to compare complex product and organizational networks, as illustrated in Figure Figure 10-9 Network maps of product and organizational networks of the PW4098 engine

14 178 THE NETWORK CHALLENGE Figure A structure approach to map product and organizational structures In this case, a design interface matrix is a square with labels corresponding to the 54 engine components while its nonzero cells correspond to the 569 design interfaces among them. In the organizational domain, a similar team interaction matrix captures how the product component teams represented in the rows request technical information from the teams represented in the columns. Note that both matrices are sequenced in a similar manner so that the component labeling row i (and column i) in the design interface matrix has its corresponding design team labeling row i (and column i) in the team interaction matrix. Finally, to systematically identify matches and mismatches of interfaces and interactions, we overlay the design interface matrix and team interaction matrix to obtain the alignment matrix. Because both design interface and team interaction matrices are binary matrices, a cell in the alignment matrix has to be a matched interface, an unmatched interface, an unmatched interaction, or a lack of interdependence. (The original team interaction matrix was of size 60 because it included six integration teams, but we excluded these teams from the comparisons of mismatches. We did, however, take these integration teams into account when analyzing the reasons why mismatches occurred.) As shown in Figure 10-10, 90% of the cases in the alignment matrix were expected cases (either matched interfaces or lack of interdependences), yet the 10% of mismatched cases are important. Of the 569 design interfaces, 39% of them were unattended by team interactions; of the 423 team interactions, over 17% of them were not

15 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 179 associated with design interfaces. Sosa, Eppinger, and Rowles (2004) analyzed the product and organizational factors associated with the systematic occurrence of these mismatches and found that both interface criticality and group boundary matter significantly. Most of the unattended interfaces uncovered in the alignment matrix were lowcriticality interfaces. The unmatched interfaces and interactions between team boundaries were at higher risk of being both unattended by team interactions and unidentified by system architects. Sosa, Eppinger, and Rowles (2007b) discuss the managerial implications of this approach in more detail. By taking a closer look at design interfaces for specific components, we observed that some components had 100% of their design interfaces attended by team interactions while others exhibited less than 40% of their interfaces attended. Why are some teams better than others at attending the technical interfaces of the components they design? Is it because of attributes of the components they design, or because of the structure of the communication networks with other teams in the organization, or both? Sosa, Gargiulo, and C. Rowles (2007) found that after controlling for component and team attributes, both the connectivity of product components and the structure of the communication network of design teams matter. Interestingly, these network properties matter in different ways depending on whether the focal team acts as a provider or receiver of technical information. Components appear to have an impact because teams working on highly indirectly connected components have trouble paying attention to technical requests from others because such teams are the ones more likely to suffer excessive and unforeseeable workload due to heavy design iterations. The team s communication network structures also have an effect because, on one hand, teams with sparse communication networks were more likely to search and acquire the technical information about the interfaces of the components they design, and, on the other hand, those teams that were surrounded by a more cohesive communication network structure were the ones that exhibited higher capability to attend the technical requests from other design teams in the network. (This is presumably because such teams enjoyed the benefits of the collaborative environment associated with close and cohesive networks.)

16 180 THE NETWORK CHALLENGE Conclusions and Future Directions As Simon (1981) suggested, complex systems are difficult to understand because the behavior of the whole depends in nontrivial ways on how its elements interact. This chapter has outlined how a network view of processes, products, and organizations can help us understand how complex product development systems draw together components that form complex systems such as automobiles or aircraft engines. By considering processes not as a sequential set of activities but instead as a web of tasks, some of which can be highly interdependent, we have uncovered the reason design iterations occur. By modeling complex products as networks of interconnected components, we have learned how to cluster components into modules in a more efficient way to make complex systems nearly decomposable systems (Simon 1981). In addition, by taking a network approach to analyzing complex products, we can then consider structural properties of product components that are defined by the patterns of technical interfaces with other components. Finally, by mapping the network of components that form a product with the communication network of teams that design such components, we have been able to evaluate systematically why some interfaces are at higher risk of being unattended than others. Only by taking a network perspective have we been able to uncover these findings and insights. Yet there is more to learn. Two promising areas in product development that would certainly benefit from a network perspective are product-organizational dynamics and innovation networks. To study the coevolution of product and organizational structures, our current research efforts focus on examining open source software development (Sosa, Browning, and Mihm 2007). One of the advantages of studying the architecture of software products is that their architecture is relatively easy to capture because it is properly codified in their source code (Sangal et al. 2005; MacCormack, Rusnack, and Baldwin 2006). In addition, software products are complex and fast-evolving, which makes them our ideal fruit flies to investigate how complex systems evolve over time. Understanding creativity is imperative for effective innovation management. Creativity is no longer considered an individual attribute but a social activity, yet we are just beginning to understand the role of social networks in the creative process (Fleming, Mingo, and Chen 2007; Sosa 2007). Which attributes of the knowledge exchanged in organizational networks like the ones discussed in this chapter influence creative outcomes? Are more talkative teams more likely to generate more novel and useful ideas than less talkative teams? These are some of the questions innovation managers need to address as they also embark on the challenge of understanding the social networks they are managing.

17 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 181 Finally, as pointed out by Nambisan and Sawhney in Chapter 9, Network-Centric Innovation: Four Strategies for Tapping the Global Brain, different models for network-centric innovation require different types of coordination and communication. Whether the process is more centralized (such as the Orchestra model) or more decentralized (such as the Global Bazaar model) will determine the type of interfaces that are needed in the network of design teams, the level of creativity that is desired, and the types of communication flows. As product development increasingly depends on networks of design teams, network thinking will be a useful capability for managers in building more successful product development organizations. The frameworks presented in this chapter offer valuable tools for understanding and improving how these networks are structured, communicate, and evolve. References Allen, T. J Managing the Flow of Technology. Cambridge, MA: MIT Press. Baldwin, C. Y., and K. B. Clark Design Rules: Volume 1: The Power of Modularity. Cambridge, MA: MIT Press. Browning, T. R Applying the design structure matrix to system decomposition and integration problems: A review and new directions. IEEE Transactions on Engineering Management 48 (3), Chen, L., Z. Ding, and S. Li A formal two-phase method for decomposition of complex design problems. ASME J. Mech. Des. 127, Clarkson, P. J., C. S. Simons, and C. M. Eckert Predicting change propagation in complex design. ASME Journal of Mechanical Design 126 (5), Eckert, C. M., P. J. Clarkson, and W. Zanker Change and customization in complex engineering domains. Research in Engineering Design 15 (1), Eppinger, S. D Innovation at the speed of information. Harvard Business Review. Eppinger, S. D., D. E. Whitney, R. P. Smith, and D. A. Gebala A model-based method for organizing tasks in product development. Research in Engineering Design 6 (1), Fleming, L., S. Mingo, and D. Chen Brokerage and collaborative creativity. Administrative Science Quarterly 52:

18 182 THE NETWORK CHALLENGE Freeman, L Centrality in social networks. Conceptual clarification. Social Networks 1, Galbraith, J. R Designing Complex Organizations. Reading, MA: Addison-Wesley Publishing. Gershenson, J. K., G. J. Prasad, and S. Allamneni Modular product design: A lifecycle view. Journal of Integrated Design and Process Science 3 (4), Gumbel, P Trying to untangle wires. Time, October 16 (European edition), Henderson, R., and K. Clark Architectural innovation: The reconfiguration of existing product technologies and the failure of established firms. Administrative Science Quarterly 35 (1), Jarratt, T., J. Clarkson, and C. Eckert Engineering Change. In Design Process ImprovementA Review of Current Practices, MacCormack, A., J. Rusnack, and C. Baldwin Exploring the structure of complex software designs: An empirical study of open source and proprietary code. Management Science 52 (7), Michelena, N., and P. Y. Papalambros A network reliability approach to optimal decomposition of design problems. ASME Journal of Mechanical Design 117 (3), Mihm, J., C. Loch, and A. Huchzermeier Problem-solving oscillations in complex engineering projects. Manag. Sci. 46 (6), Pimmler, T. U., and S. D. Eppinger Integration analysis of product decompositions. ASME Conference on Design Theory and Methodology, in Minneapolis, MN, Pinedo, M., S. Sehasdri, and E. Zemel The Ford-Firestone case. Teaching case. Department of Information, Operations, and Management Sciences, Stern School of Business, NYU. Pisano, G BMW: The seven series project. HBS case Sangal, N., E. Jordan, V. Sinha, and D. Jackson Using dependency models to manage complex software architecture, Proceedings of the 20th Annual ACM SIG- PLAN Conference on Object Oriented Programming, Systems, Languages, and Applications, in San Diego, CA.

19 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 183 Sharman, D., and A. Yassine Characterizing complex products architectures. Systems Engineering 7 (1), Simon, H. A Administrative Behavior: A Study of Decision-making Processes in Administrative Organizations. Chicago, IL: Macmillan. Simon, H. A The Science of the Artificial. 2nd ed. Cambridge, MA: MIT Press. Smith, R. P., and S. D. Eppinger. 1997a. A predictive model of sequential iteration in engineering design. Manag. Sci. 43 (3) Smith, R. P., and S. D. Eppinger. 1997b. Identifying controlling features of engineering design iteration. Manag. Sci. 43 (8) Sosa, M. E Where do creative interactions come from? The role of tie content and social networks. INSEAD working paper 2007/49/TOM. Sosa, M. E A structured approach to predicting and managing technical interactions in software development. Research in Engineering Design 19(1) Sosa, M. E., T. Browning, and J. Mihm Studying the dynamics of the architecture of software products. Proceedings of the 19th ASME Design Theory and Methodology Conference. Sosa, M. E., S. D. Eppinger, and C. M. Rowles Identifying modular and integrative systems and their impact on design team interactions. ASME Journal of Mech. Design 125 (2), Sosa, M. E., S. D. Eppinger, and C. M. Rowles The misalignment of product architecture and organizational structure in complex product development. Management Science 50 (12), Sosa, M. E., S. D. Eppinger, and C. M. Rowles. 2007a. A network approach to define modularity of components in complex products. ASME Journal of Mechanical Design 129 (11), Sosa, M. E., S. D. Eppinger, and C. M. Rowles. 2007b. Are your engineers talking to one another when they should? Harvard Business Review, November. Sosa, M. E., M. Gargiulo, and C. Rowles Component connectivity, team network structure, and the attention to technical interfaces in complex product development. INSEAD working paper 68/TOM/OB. Steward, D The design structure matrix: A method for managing the design of complex systems. IEEE Transactions on Engineering Management EM-28 (3),

20 184 THE NETWORK CHALLENGE Thompson, J. D Organizations in Action. New York: McGraw-Hill. Ulrich, K. T The role of product architecture in the manufacturing firm. Res. Policy. 24, Ulrich, K. T., and S. D. Eppinger Product Design and Development. 3rd ed. New York: McGraw Hill. Wasserman, S., and K. Faust Social Network Analysis. New York: Cambridge University Press.

21 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 185

22 186 THE NETWORK CHALLENGE

23 CHAPTER 10 COORDINATION NETWORKS IN PRODUCT DEVELOPMENT 187