This article was downloaded by: [68.181.176.15] On: 03 April 2014, At: 16:46Publisher: Institute for Operations Research and the Management Sciences (INFORMS)INFORMS is located in Maryland, USA
Management Science
Publication details, including instructions for authors and subscription information:http://pubsonline.informs.org
The Misalignment of Product Architecture andOrganizational Structure in Complex ProductDevelopmentManuel E. Sosa, Steven D. Eppinger, Craig M. Rowles,
To cite this article:Manuel E. Sosa, Steven D. Eppinger, Craig M. Rowles, (2004) The Misalignment of Product Architecture and OrganizationalStructure in Complex Product Development. Management Science 50(12):1674-1689. http://dx.doi.org/10.1287/mnsc.1040.0289
Full terms and conditions of use: http://pubsonline.informs.org/page/terms-and-conditions
This article may be used only for the purposes of research, teaching, and/or private study. Commercial useor systematic downloading (by robots or other automatic processes) is prohibited without explicit Publisherapproval. For more information, contact [email protected].
The Publisher does not warrant or guarantee the article’s accuracy, completeness, merchantability, fitnessfor a particular purpose, or non-infringement. Descriptions of, or references to, products or publications, orinclusion of an advertisement in this article, neither constitutes nor implies a guarantee, endorsement, orsupport of claims made of that product, publication, or service.
Please scroll down for article—it is on subsequent pages
INFORMS is the largest professional society in the world for professionals in the fields of operations research, managementscience, and analytics.For more information on INFORMS, its publications, membership, or meetings visit http://www.informs.org
The Misalignment of Product Architecture andOrganizational Structure in Complex
Product Development
Manuel E. SosaINSEAD, Boulevard de Constance, 77305 Fontainebleau, Cedex, France, [email protected]
Steven D. EppingerSloan School of Management, Massachusetts Institute of Technology, Cambridge, Massachusetts 02139, [email protected]
Craig M. RowlesAdvance Engine Program, Pratt & Whitney Aircraft, East Hartford, Connecticut 06108, [email protected]
Product architecture knowledge is typically embedded in the communication patterns of established devel-opment organizations. While this enables the development of products using the existing architecture, it
hinders the organization’s ability to implement novel architectures, especially for complex products. Structuredmethods addressing this issue are lacking, as previous research has studied complex product developmentfrom two separate perspectives: product architecture and organizational structure. Our research integrates theseviewpoints with a structured approach to study how design interfaces in the product architecture map ontocommunication patterns within the development organization. We investigate how organizational and systemboundaries, design interface strength, indirect interactions, and system modularity impact the alignment ofdesign interfaces and team interactions. We hypothesize and test how these factors explain the existence ofthe following cases: (1) known design interfaces not addressed by team interactions, and (2) observed teaminteractions not predicted by design interfaces. Our results offer important insights to managers dealing withinterdependences across organizational and functional boundaries. In particular, we show how boundary effectsmoderate the impact of design interface strength and indirect team interactions, and are contingent on systemmodularity. The research uses data collected from a large commercial aircraft engine development process.
Key words : product architecture; product development organizations; technical communication; designstructure matrix; statistical network analysis
History : Accepted by Karl Ulrich, technological innovation, product development, and entrepreneurship;received July 23, 2002. This paper was with the authors 13 12 months for 3 revisions.
1. IntroductionUnderstanding how organizations manage the knowl-edge associated with the architecture of the productsthey design is a critical challenge for firms developingcomplex products. As highlighted by Henderson andClark (1990, p. 9), “architectural knowledge tends tobecome embedded in the structure and information-processing procedures of established organizations.”Hence, organizations dealing with novel architecturesmust understand how they manage the embeddedknowledge of the products they currently develop.This is especially relevant in complex product devel-opment due to the large number of both physicalcomponents and design participants involved in theprocess. Unfortunately, methods and/or tools avail-able to address this challenge are scarce.Consider the typical job of a design engineer dur-
ing the development of a complex product, suchas an aircraft engine. Usually, design engineers are
part of cross-functional design teams dedicated tospecific components of the product (Robertson andAllen 1992, Pimmler and Eppinger 1994). Duringthe design phase, the team responsible for design-ing an engine component (e.g., the blades of thelow-pressure turbine) needs to balance the technicaldemands from other design teams in addition to man-aging its own design constraints. Usually, demandsfrom other teams depend on the nature of the designinterfaces between their components. For example,when examining the interfaces between the vanes andblades of the low-pressure turbine studied in thispaper, we learned that there is a potential transferof energy (vibration) from the vanes to the bladesthat needs to be avoided. Teams designing those com-ponents are expected to interact to address such aninterface (see Sosa et al. 2003 for further details). Ingeneral, while managing the integration effort acrossdesign teams, managers of complex development
projects typically raise the following questions: Aredesign teams communicating about the right things?If not, why? Are all design interfaces between prod-uct components identified and addressed during thedesign phase? If not, why?This situation highlights the importance of not only
identifying the interfaces between product compo-nents but also evaluating whether or not the corre-sponding teams interact to address those interfacesproperly. Of course, it is not difficult to argue thatif two components share design interfaces, the teamsthat design them need to interact (Thompson 1967,Galbraith 1973). However, in the development ofhighly complex products, it would be naïve to expecta perfect mapping between design interfaces andteam interactions. Hence, we investigate the factorsthat prevent such an occurrence:• Can we expect any significant misalignment of
product architecture and organizational integrationeffort? If so, how can we uncover it?• What factors may impact such misalignment?
More specifically,— Why do some design interfaces between prod-
uct components not correspond to technical interac-tions between the design teams that develop them?
— Why do some technical interactions betweendesign teams take place even though no design in-terface is identified between the components theydesign?Investigating these questions is crucial to under-
stand in what areas of the product and organizationmanagers need to pay particular attention to mod-erate the impact of misalignments. Previous researchhas studied complex development efforts separatelyfrom two important perspectives: the product archi-tecture and the organizational structure. Rather, webring these two perspectives together to examinehow and why interfaces between product componentsmap onto interactions between teams designing them.This paper offers two important contributions. First,
we integrate two separate streams of research to inves-tigate why misalignment of product and organiza-tional structures occur, and hypothesize factors thatimpact such misalignment. This contributes to theexisting literature by enhancing our understandingof technical communication patterns in organizationsdeveloping complex products. Second, we extend ourresearch approach introduced in Sosa et al. (2003)by using a novel statistical network analysis tech-nique (based on p∗ models of Wasserman and Pattison1996) to test hypothesized effects while controlling fordyadic and triadic tendencies typically embedded innetwork data. By doing so, we not only uncover mis-alignment of product and organizational structures,but also properly examine factors that are systemati-cally associated with such misalignment. We provide
some evidence that while certain types of misalign-ment can be beneficial to complex product develop-ment projects, others can be extremely costly, resultingin major rework and customer impact. Hence, it isimportant for managers to anticipate where misalign-ment is more likely to occur—that is, to distinguishwhich areas of the product and organization requirespecial attention to identify critical design interfacesand ensure important team interactions.
2. Design Interfaces and TeamInteractions
In the product architecture domain, we define a designinterface between component i and component j ascomponent i depending on component j for func-tionality. That is, component j either imposes geom-etry constraints or transfers forces, material, energy,and/or signals to component i for component i tofunction properly. In the organizational domain, wedefine team interaction between design team i anddesign team j as team i requesting technical informa-tion directly from team j during the detailed designphase of the development process. Note that our defi-nitions for both design interface and team interactionimply a direction. That is, component i’s functionalityis affected by component j , and technical informationflows from team j to team i.We observe that during the detailed design phase
of a complex development effort, design interfaces arethe primary source of team interdependence (Mihmet al. 2003). Hence, for projects where the task struc-ture is of the form “team i designs component i”(which is typical in complex product development),it is not difficult to argue that the existence (orabsence) of a design interface between componenti and component j should correspond to the exis-tence (or absence) of technical interaction of team iwith team j . These expected cases are representedby the lower-left and upper-right cells of Figure 1.The lower-right and upper-left cells represent theunexpected cases, which are the focus of our study.Unmatched design interfaces correspond to design inter-faces that are not addressed by direct team interac-tions, whereas unmatched team interactions correspondto communication between teams whose components
Figure 1 Mapping Design Interfaces and Team Interactions
NO Unmatched design interfaces Aligned absence ofinterfaces and
Team interactionsInteractions
YES Aligned presence of Unmatched teaminterfaces and interactionsinteractions
do not explicitly share design interfaces. Note thatour variable of interest is whether or not design inter-faces and team interactions are aligned. Hence, we arenot claiming causality, but association. Although webelieve design interfaces drive team interactions forthe most part, we are also open to the possibility ofteam interactions determining some design interfaces.Previous research has largely ignored the signif-
icant existence of unmatched design interfaces andunmatched team interactions (Brown and Eisenhardt1995, Krishnan and Ulrich 2001). However, we believethat considering these cases is important becausetheir existence would indicate that not all knownproduct-related interdependences are addressed bydirect technical communication, and that technicalcommunication (where not expected) may uncoverundocumented product-related interdependences.There are two types of factors that may prevent
alignment of design interfaces and team interactions.First, dynamic factors refer to how previous andfuture development efforts may affect the likelihoodof encountering misaligned cases (Henderson andClark 1990, Adler 1995, Terwiesch et al. 2002).Although dynamic factors are important (see onlineAppendix D available at mansci.pubs.informs.org/ecompanion.html), we focus this study on under-standing static effects. Static factors refer to how boththe current product architecture and organizationalstructure impact the likelihood of misalignment ofdesign interfaces and team interactions.
2.1. Product Architecture PerspectivePrevious research on product architecture has focusedon the product itself. In this view, product archi-tecture is defined as “the specification of the inter-faces among interacting physical components” (Ulrich1995, p. 420). Although previous work in this area hasadvanced our understanding of architectural knowl-edge and its impact on some operational aspects ofthe firm, the explicit link between product architec-ture and organizational structure has been largelyneglected (see reviews by Krishnan and Ulrich 2001,Sosa et al. 2003). In this paper, we extend the prod-uct architecture literature by proposing that althoughmost of the architectural knowledge is explicit andknown by development organizations, some inter-faces between components are unspecified (or evenunknown) and only identified or documented duringthe design process itself. It then becomes importantto determine where (in the product) those unidenti-fied interfaces are likely to be, and how they can beuncovered. By simultaneously analyzing the designnetwork of components and the communication net-work of design teams, we uncover those unknowninterfaces and the factors that influence their occur-rence, which provides us with a more complete viewof the architecture of the product.
2.2. Organizational PerspectiveAdopting the information-processing viewpoint,Brown and Eisenhardt (1995, p. 358) summarizethat “frequent and appropriately structured task com-munication” results in better performing developmentprocesses. Not surprisingly, a large body of researchfocuses on the communication process in devel-opment organizations, much of which has studiedhow factors such as physical distance, organizationalstructures, task structures, and communication mediaaffect technical communication (e.g., Allen 1977,Morelli et al. 1995, Van den Bulte and Moenaert 1998,Sosa et al. 2002). Yet, how product architecture relatesto technical communication remains unaddressed bythis stream of work.Much work on technical communication has fo-
cused on understanding the factors that inhibit tech-nical communication. In addition to distance, bound-aries between distinct organizational groups have alsobeen identified as an important inhibitor to communi-cation (e.g., Allen 1977, Van den Bulte and Moenaert1998). Conversely, there is another line of thought inthe product innovation literature that focuses on teaminterdependence as an important driver of technicalcommunication (e.g., Morelli et al. 1995, Adler 1995,Loch and Terwiesch 1998, Terwiesch et al. 2002). Inthis paper, we not only show how product architec-ture is an essential source of team interdependence,but we also disentangle the hindering effects of orga-nizational boundaries from the motivating effects ofproduct interdependence. This paper also extends theliterature on product innovation by explicitly con-sidering indirect interactions between design teamsas a possible mechanism to handle certain designinterfaces.
3. Understanding the Misalignment ofDesign Interfaces and TeamInteractions
3.1. Effects of System andOrganizational Boundaries
Architectures of complex products are typically de-composed into systems and components. As a result,system boundaries are established to cluster compo-nents so that a significantly larger proportion ofdesign interfaces are within these boundaries (Pimm-ler and Eppinger 1994, Stone et al. 2000, Whitney2004). This may impose architectural knowledge bar-riers that inhibit explicit identification of design inter-faces across systems by the design experts (Hendersonand Clark 1990, Sanchez and Mahoney 1996). Never-theless, to develop working systems, we propose thatcertain design teams need to interact, which results inunmatched team interactions. This argument is con-sistent with the concept of ambiguity associated with
complex engineering projects (Schrader et al. 1993,Pich et al. 2002). That is, due to product ambiguity,defined as the absence of knowledge about designvariables and/or their interfaces, some design inter-faces are not foreseen at the outset of the projectand are only discovered after design teams work onthe systems themselves. We argue that evidence ofproduct ambiguity is more likely to occur across sys-tem boundaries because system barriers prevent theidentification of some existing interfaces. Hence, forcomplex products, we expect a higher likelihood ofencountering unmatched team interactions across sys-tem boundaries.Complex product development also requires struc-
turing the organization into groups of cross-functionaldesign teams to design systems and components. Asa result of this organizational breakdown, organiza-tional boundaries are formed between design teamsthat belong to different groups of teams (Ulrich andEppinger 2004, p. 21). Previous research on R&Dmanagement suggests that organizational boundariesbetween functional groups impose communicationbarriers that inhibit cross-team interactions even inthe presence of collocation (e.g. Allen 1977, Vanden Bulte and Moenaert 1998). People within thesegroups are subjected to organizational bonds that pro-mote the development of a language and an iden-tity inherent to the group in which they belong. Asa result, the greater the degree of group special-ization, the higher the communication barriers areacross them (Tushman and Katz 1980). Accordingly,in complex product development projects, organiza-tional boundaries are expected to significantly reducecross-boundary team interactions. By extension to ourframework, we should expect a significantly largerproportion of unmatched design interfaces acrossboundaries. More specifically, we expect design teamsto exhibit a lower tendency to discuss cross-boundarydesign interfaces than within-boundary interfaces.Hence, we envision a higher likelihood of encoun-tering unmatched design interfaces across organiza-tional boundaries. Considering the effects of systemand organizational boundaries, we posit the followinghypothesis to test:
Hypothesis 1. Misalignment of design interfaces andteam interactions is more likely to take place across systemand organizational boundaries than within boundaries.
3.2. Effects of Design Interface StrengthWhen examining design interfaces between compo-nents of complex products, research in engineeringdesign has distinguished various types of designdependencies (such as spatial, material, and energytypes) and several levels of criticality (such asrequired, indifferent, and detrimental) to character-ize a design interface between any two components
(Pahl and Beitz 1991, Pimmler and Eppinger 1994,Sosa et al. 2003). We extend this taxonomy by defin-ing two levels of strength of a design interface. Wedefine weak design interfaces as those which involvefew types of design dependencies and have lowimpact upon the functionality of the other component,whereas strong design interfaces are those that involveseveral types of design dependencies and have highimpact on the functionality of the other component.To understand the link between design interface
strength and team interactions, we refer to previousresearch on task interdependence. The degree oftask interdependence determines the degree to whichtasks require collective action (Thompson 1967).Moreover, the greater the degree of task interdepen-dence, the greater the information requirements arebetween design teams (Galbraith 1973). This is con-sistent with research that has shown that a greaterdegree of task interdependence leads to greater teaminteraction (e.g., Adler 1995, Smith and Eppinger1997, Loch and Terwiesch 1998). Considering thatin many complex development efforts a significantproportion of the task structure directly maps ontothe product structure under development (i.e., task iis defined as “designing component i”), we expectstrong design interfaces to generate greater teaminterdependence. This should result in higher likeli-hood of team interaction between the correspondingdesign teams:
Hypothesis 2. In complex products, strong designinterfaces are more likely to be aligned with team interac-tions than are weak design interfaces.
Hypothesis 1 posits that organizational bound-aries hinder the alignment of design interfaces andteam interactions, whereas Hypothesis 2 suggests thatgreater component interdependence favors the occur-rence of such alignment. We then ask: Which effect isstronger?When considering the effects of system boundaries,
one might claim that they not only inhibit legacydesign experts from identifying all cross-boundaryinterfaces (Hypothesis 1), but they also inhibit designteams from properly perceiving strong design inter-faces as such. This is particularly relevant in com-plex products due to the simultaneous presence ofseveral types of design dependencies (such as spa-tial, structural, and thermal) associated with the samedesign interface (Pahl and Beitz 1991, Pimmler andEppinger 1994). In addition, organizational researchhas suggested that design teams not only face dif-ficult challenges when they need to search for andtransfer technical knowledge across their organiza-tional boundaries (e.g., Hansen 1999, 2002), but alsotend to simplify and filter certain aspects of exter-nal information to facilitate internal problem solving
(Henderson and Clark 1990). Based on this, one couldargue that, across boundaries, design teams wouldbe more likely to underestimate the impact of certaintypes of design dependencies, and therefore wouldnot be able to distinguish the difference between weakand strong design interfaces.Previous research in development organizations,
which recognizes that teams are selective when inter-acting across boundaries, provides the basis of thealternative reasoning for which we argue. This streamof work suggests that teams engage in cross-boundarycommunication to address critical interdependence(e.g., Tushman and Katz 1980, Ancona and Caldwell1992, Cummings 2004). Moreover, Tushman (1977,p. 592) suggests that specialized gatekeepers “maynot attend to all external communication areas, butmay specialize in those external areas most critical tothe work of their unit.” This observation is consis-tent with recent findings from the telecommunicationsindustry suggesting that teams are more likely tocross communication barriers imposed by geograph-ical separation when they are highly interdependent(Sosa et al. 2002, Cummings 2004). Extending thisinsight to our context, we argue that teams are morelikely to overcome system/organizational boundariesto address strong design interfaces.
Hypothesis 3. Strong design interfaces are more likelyto be aligned with team interactions than are weak de-sign interfaces, even across organizational and systemboundaries.
3.3. Effects of Indirect Team InteractionsWe define indirect team interactions as technical infor-mation flow that takes place between two teamsthrough an intermediary design team. Research insocial networks has long supported the notionof indirect communication via intermediary units(Granovetter 1973). More recently, research aboutknowledge sharing in a multi-unit development orga-nization has also considered the role of indirectrelations to effectively transfer technical informationthrough intermediary teams that are close to the focalteam (Hansen 1999, 2002). Although early work inR&D identified the organizational benefits of hav-ing a gatekeeper who could gather relevant informa-tion from the team’s external environment and passit to the rest of the team (e.g., Tushman 1977, Tush-man and Katz 1980), indirect interactions betweendesign teams have been largely neglected as a coordi-nation mechanism to address their interdependence inproduct development organizations (e.g., Adler 1995,Terwiesch et al. 2002).In this paper, we use the concept of indirect team
interaction to hypothesize that team i, whose com-ponent has a design interface with component j ,may not report direct interaction with team j because
it interacts with an intermediary team (team k, whichalso interacts with team j) which passes the informa-tion (to team i) that would otherwise have floweddirectly from team j to team i. Hence, we expecta higher likelihood of finding unmatched designinterfaces between teams that communicate indirectlythrough intermediary teams:
Hypothesis 4. Two interrelated components are morelikely to have an unmatched design interface when theircorresponding design teams have other intermediary teamsthrough which they can indirectly communicate.
3.4. Effects of Indirect Design InterfacesIn the product architecture domain, we introducethe notion of indirect design interfaces as the indirectimpact of component j over component i through anintermediary component k. This definition considersthe product as a set of interrelated elements (Krishnanand Ulrich 2001). Although the impact in the designprocess due to the propagation of product designdependencies through intermediary components hasbeen investigated (e.g., Whitney 2004, Mihm et al.2003), the effects on the communication patterns dueto unconnected components linked through interme-diary components remains unknown.Similar to the case of indirect team interactions, we
hypothesize that the existence of intermediary ele-ments between two components that do not share adirect design interface increases the likelihood that thecorresponding design teams interact, resulting in anunmatched team interaction. Considering the effectsof indirect design interfaces is important becauseit offers an alternative explanation to our initialargument that unmatched team interactions indicatethe existence of unidentified direct design interfacesbetween two components. That is, design teams mightinteract not only to address direct interfaces that hadnot been identified at the outset of the project (prod-uct ambiguity effect), but also to address indirectdesign interfaces between components not directlyconnected (product complexity effect):
Hypothesis 5. Two design teams are more likely tohave an unmatched team interaction when the componentsthey design share interfaces with a common component.
3.5. Effects of System ModularityBased on how functions map onto physical compo-nents, one can distinguish modular and integral prod-uct architectures (Ulrich 1995). In Sosa et al. (2003),we extend this concept to the system level by intro-ducing a new notion of system modularity basedupon the way physical components share designinterfaces across systems within a complex product.Modular systems are “those whose design interfaceswith other systems are clustered among a few phys-ically adjacent systems,” whereas integrative systems
are “those whose design interfaces span all, or mostof, the systems that comprise the product due totheir physically distributed or functionally integra-tive nature throughout the product” (Sosa et al. 2003,p. 240).To study complex product architectures in terms
of component interfaces, we use the design structurematrix (DSM) tool, an analytical method introducedby Steward (1981) and used by Eppinger et al.(1994) to study interdependence between productdevelopment activities. In Sosa et al. (2003), wedetail our DSM approach to identify modular andintegrative systems in complex products. Althoughthat paper does not explain why misalignment ofdesign interfaces and team interactions occur (whichis the purpose of this paper), it presents limitedempirical evidence showing that the effects of orga-nizational and system boundaries described above(Hypothesis 1) are more severe between modular sys-tems than with integrative systems. In addition, weextend the approach presented by Sosa et al. (2003) byapplying, for the first time, statistical modeling tech-niques based on social network analysis for properhypothesis testing using DSM data.The organizational literature on product innovation
considers products as hierarchically arranged sets ofsubsystems with defined interfaces (e.g., Alexander1964). By examining the impact of the architectureof the product on the innovation process from astrategic viewpoint, this line of research suggests thatthe communication structure of development orga-nizations depends on the type of product architec-ture they design (e.g., Henderson and Clark 1990,Sanchez and Mahoney 1996, Baldwin and Clark 2000).Previous organizational research suggests that devel-opment teams exhibit different strategies to managetheir interdependences across boundaries (Anconaand Caldwell 1992). Because modular systems differfrom integrative systems in the way they share designinterfaces across boundaries rather than within bound-aries (Sosa et al. 2003), we expect modular teamsto exhibit different cross-boundary communicationpatterns than do integrative design teams. That is,given the physically distributed or functionally inte-grative nature of integrative systems (Pimmler andEppinger 1994), integrative design teams are morelikely to cross organizational boundaries than designteams that develop modular systems (Yassine et al.2003). Because Sosa et al. (2003) tested this proposi-tion without controlling for typical nonrandom ten-dencies embedded in DSM data, we posit the follow-ing hypothesis for further testing:
Hypothesis 6. For interfaces and interactions occur-ring across organizational and system boundaries, mis-alignment of design interfaces and team interactions is
Figure 2 Our Research Approach
Interviewingdesign experts
Surveyingteam members
DesignInterfaceMatrix
TeamInteraction
Matrix
AlignmentMatrix
StatisticalNetworkAnalysis
more likely to occur between components that belong to dif-ferent modular systems than with components that belongto integrative systems.
4. Research ApproachThis section summarizes our method of comparingand analyzing the architecture of a product withits development organization. Our approach involvesfour major steps (see Fig. 2):Step 1: Identify design interfaces. By interviewing
design experts who have a deep understanding ofthe architecture of the product, we identify how theproduct is decomposed into systems, and these arefurther decomposed into components. We then askthe experts to identify the types and criticality of thedesign dependencies between all the components. Werepresent this network of component dependencies ina design interface matrix.Step 2: Identify team interactions. We identify the
teams responsible for developing each of the prod-uct’s components. We then survey key members ofeach team to capture the intensity of the technicalinteractions between them. We represent this commu-nication network in a team interaction matrix.Step 3: Map design interfaces and team interactions.
We compare the design interface matrix with theteam interaction matrix and capture this comparisonin the alignment matrix. When each design team isresponsible for the design of only one physicalcomponent, the alignment matrix is obtained byoverlaying the identically sequenced design interfacematrix and team interaction matrix.Step 4: Analyze the alignment matrix. We use statisti-
cal network analysis techniques to rigorously ana-lyze the patterns exhibited in the alignment matrixand test hypothesized effects that may systematicallycause a significant misalignment of design interfacesand team interactions.
5. The StudyWe applied our approach to study the detail designperiod of the development of a large commercial air-craft engine (Sosa et al. 2003), the PW4098 derivativeengine developed by Pratt & Whitney (P&W).
5.1. Identifying Design InterfacesThe engine studied was decomposed into eight sys-tems. Each of these systems was further decomposedinto five to ten components each, for a total of 54components. Six of the eight systems were identifiedas modular systems, whereas the other two systems(mechanical components system and externals andcontrols system) were recognized as integrative systemsbecause of the physically distributed and functionallyintegrative features of their components (Sosa et al.2003).Five types of design dependencies were defined for
the design interfaces between the physical compo-nents, and a five-point scale was used to capture thelevel of criticality of each dependency for the over-all functionality of the component in question. Thesemetrics are discussed at length in Sosa et al. (2003).The type and criticality of design interfaces were usedto assess their strength as follows:
[design interface strength]ij =∑ �cdij �� where
d= dependency type = [spatial, structural, mate-rial, energy, information],cdij = level of criticality for design interface �i� j of
type d= −2�−1�0�+1�+2�.For the 569 nonzero design interfaces documented,
the mean (sd) of design interface strength was 4.41(1.92). Similar to network studies that consider valuedties (Granovetter 1973, Marsden 1990), we define anindicator variable, STRENGTHij , which trichotomizesthe criticality of the design interfaces:
Under this categorization, we determined 319WEAK interfaces and 250 STRONG interfaces. Thisis consistent with other observations of complexproducts in which there are fewer critical interfacesthan less important ones (Smith and Eppinger 1997).Alternative definitions of STRENGTHij resulted in askewed distribution of nonzero design interfaces, andwere somewhat limited in capturing both type andcriticality of the design interfaces. Results of categor-ical data analysis with these alternative definitionswere consistent with the findings reported in thispaper. We mapped the design interface data into atrichotomous design interface matrix (see Figure 3).The off-diagonal entries of the matrix are marked
with either a “W” or “S” to indicate the existence ofa WEAK or STRONG design interface, respectively,between two components (see Sosa et al. 2003 fordetails).
5.2. Identifying Team InteractionsThe organization responsible for the development ofthe aircraft engine was structured into 60 designteams exclusively dedicated to the project. Fifty-fourof these teams were responsible for developing the54 components of the engine, and were grouped intoeight system-design groups mirroring the architectureof the engine studied. The remaining six design teamswere system integration teams, who had no specifichardware assigned to them, and whose responsibil-ity was to assure that the engine worked as a whole.Examples are the rotordynamics and secondary flowteams.We captured the intensity of the task-related tech-
nical interactions between the design teams involvedin the development process (Allen 1977, Morelli et al.1995). Similar to previous studies in technical commu-nication and social networks, we surveyed key mem-bers of design teams about the peak frequency andcriticality of their technical interactions (Allen 1977,Marsden 1990). We surveyed 57 of the 60 teams. Weassumed reciprocal interactions for the teams whoseresponses were missing. Additional analysis with-out these components/teams was consistent with thefindings reported here. We used a six-point scale thatcombines the frequency and criticality of each inter-action into a single metric called interaction intensity.This is consistent with Marsden and Campbell (1984),who found closeness or intensity as best indicators ofunobserved tie strength. More recently, Hansen (1999,2002) combined frequency and closeness into a singlemetric called interunit tie weakness. The criticality com-ponent of our metric allows asymmetry in the interac-tion intensity of each pair of teams. After completingdata purification, we identified a total of 680 nonzerotechnical team interactions within the organization,with mean (sd) intensity of 2.37 (1.42), of which 423interactions were between the 54 component teams.Similar to previous research in technical communi-
cation (e.g., Allen 1977, Van den Bulte and Moenaert1998), we chose the presence or absence of signifi-cant information exchange as the binary variable ofinterest. We define significant information exchange asthose technical interactions that were relevant duringthe design phase due to their criticality and/or fre-quency. Such interactions are captured by a nonzerointeraction intensity in our scale. We organized theinteraction data into a square �60×60 team inter-action matrix (Figure 4), whose off-diagonal cellsmarked “O” indicate each significant team interactionrevealed.
5.3. Mapping Design Interfaces and TeamInteractions
The one-to-one assignment of the 54 componentsto the 54 design teams allows the direct comparisonof the design interface matrix with the team interac-tion matrix. Hence, by overlaying the design interfacematrix with the team interaction matrix, we obtain thealignment matrix exhibited in Figure 5. Note that weomitted the six integration teams from this analysis.These teams interact with almost every componentdesign team in the organization, which prevents usfrom inferring any particular communication patternin which they were involved (see online Appendix Dfor further discussion).The alignment matrix provides the basis for the
analysis completed to test the hypotheses posedabove. Figure 6 exhibits the possible states for eachcell of the alignment matrix. As expected, the majority
of the cases (90% of the cells) show aligned pres-ence or absence of design interfaces and team inter-actions. The unexpected cases accounted for 10% ofthe cells; these were the 220 unmatched design inter-faces (39% of the 569 design interfaces), and the74 unmatched team interactions (17% of the 423 teaminteractions). A descriptive categorical data analy-sis tentatively supports all the hypotheses posed in§3, except Hypothesis 3 (see online Appendix A fordetails). Yet, for proper hypothesis testing we needto control for nonrandom tendencies typically embed-ded in network data.
6. Statistical Network AnalysisSimilar to social network data, in our data seteach component and design team appears as manytimes as they share interfaces or interact with oth-ers, resulting in observations that are clearly not
O O O O * O O O O O O O O O O O O O O O O O O O O O
O O * O O O
O * O O O
CC group(5 teams)
O O * O O O O O
O O * O O O
O O * O O O O
O O O * O
O O O O O * O O O O O O
HPT group(5 teams)
O O O O O O O O * O O O O O O O O O O O O O O O O O
O O O O * O O O O
* O O O O O O
O O O * O O O O O O O
* O
O O O O * O O O O
Modulardesignteams
LPT group(6 teams)
O O O O O *
O O O O O O O O O O O O O O O O O O O * O O O O O O O O O O O O O O O
O O O O O O * O O O O O O O O O O O O O O O O O O
O O O * O O
O O * O O
O O O * O O
O O * O O
Mech. comps.group
(7 teams)O *
* O O O
O O O O O * O O O O O O O O
O O O O O O O O O O * O O O O O O O O O O O
O O O O O O * O O O O
O O O O O O * O O O O O O
O O O O * O O O O O
O O O O O O O O O O O O * O O O O O O O
O O O O O O O O O O O O O O * O O O O O O
O O O O O O O O O * O O O
Integrativedesignteams Ext./controls
groups(10 teams)
O O O O O O O O O O O O O O O O O O O O O O O * O O O O O
O O O O O O O O O O O O O O * O O O O OO O O O O O O O O O O O O O O O * O O O
O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O * O O O
O O O O O O O O O O O O * O O
O O O O O O O O O O O O O O O O O O O O O * O
Systemintegrators(6 teams) O O O O O O O O O O O O O O O O O O O *
O
O
O
independent. By visually inspecting both the designinterface and the team interaction matrices, we canobserve strong tendencies for reciprocation of ties aswell as significant concentration of ties within bound-aries (i.e., clustering of ties). Other tendencies thatcan be present in our data are propensities of com-ponents and teams to generate or attract linkages.Such deviations from randomness embedded in ournetwork data make our statistical analysis problem-atic. We tackle this challenge by considering two sta-tistical network approaches: log-linear p1 and logit p∗
analyses. We also considered quadratic assignmentprocedure (QAP) (Krackhardt 1988), however, giventhe strong tendencies for reciprocation and cluster-ing in our data, we found the use of QAP to be lesssuitable.
6.1. log-linear p1 AnalysisWe built log-linear models of the alignment matrixbased on the p1 distribution introduced by Hollandand Leinhardt (1981). Similar to Van den Bulte andMoenaert (1998), in five steps we build a log-linearmodel for the probabilities of the dyads of our align-ment matrix to test Hypotheses 1 and 6. We thenconstruct additional log-linear p1 models that con-sider discrete design interfaces to test the effects
of design interface strength (Hypotheses 2 and 3).Although this statistical modeling approach well suitsour research problem, its independence dyad assump-tion could be limiting and unrealistic (Wasserman andFaust 1994, Chapter 15). Because p1 models do notexplicitly handle triadic effects, we are not able touse them to test our hypotheses concerning indirectrelations (Hypotheses 4 and 5). Nonetheless, we usedthis analysis to validate the results obtained fromour main statistical approach, the logit p∗ analysis.Details of our log-linear p1 analysis are included inonline Appendix B.
6.2. logit p∗ AnalysisTo address the limitations of p1 models, a new genera-tion of exponential family models, p∗, was developedby Wasserman and Pattison (1996). These models notonly release the independent dyad assumption, butalso allow researchers to formulate them in a stan-dard response-explanatory variables form in which theresponse variable is the log odds (or logit) of the prob-ability that a network tie is present, and the explana-tory variables can be either any hypothesized networkstructure or network actor attribute. We describe, inonline Appendix C, how we build specific membersof the p∗ family to model our alignment matrix and
O O O # # O O # O # O # O O # # # W W O # * # # # # O # # W # # O# O O # # W # * # # # # # # # # # # # O
W # W # O * W W W W O W
O # * W W O
W # # * #
# # * W # W W #
Mech.comps.
W W # W W W W W W W W * W W W W W
W W S W S S S S S S S S S S S S * # # # S S
S O # # # O S * # # # # #
W W # # # S S O S # # S # # # O * # # # # # # #
W O # S # S # # # * # # W # S
W S W W # # # # # # * # # # #
# W # # # * # W #
W W S S S W # # # S W # # # # # # # # # * # # #
# W W # # O # # S # # # # # # # # * O #
W W S S W # # S # # # # # O O * #
Integrative Ext. /ctrls.
# W # # # # O # # # # # O # O # # # # # # # # # *
W#
W: Unmatched WEAK interface; S: Unmatched STRONG interface; O: Unmatched Team interaction; #: Aligned presence of interface and interaction; (Blank):Aligned absence of interface and interaction; ∗: Diagonal elements (meaningless).
test our hypotheses. We complete our logit p∗ analysisin three steps.
6.2.1. Step 1: Define Hypothesized Network Ef-fects. Our logit p∗ formulation includes basic dyadicand triadic effects typical of network data (Andersonet al. 1999, p. 46) for both design interfaces and teaminteractions as well as bivariate effects captured byour alignment matrix. Refer to online Appendix C forparameters and associated network statistics defini-tions.To test our hypotheses, we define structural vari-
ables as ACROSSij and MODULARij to capturewhether tie ij is across boundaries and betweenmodular systems, respectively. Note that by includ-ing ACROSSij into our models, we capture the clus-tering effects due to organizational and systemsboundaries embedded in both design interface andteam interaction matrices. Using these structural vari-
Figure 6 Overall Results
TeamNO (2439) W (150) S (70) (2219)
Interactions YES (423) #W (169) #S (180) O (74)
YES (569) NO (2293)Design Interfaces
ables and the bivariate network effects described inonline Appendix C, we define formal tests for ourhypotheses as follows:
Hypothesis 1. �ACROSS�12<0.
Hypothesis 2. �STRONG�2>�WEAK�2.
Hypothesis 3. �ACROSS�STRONG�2>�ACROSS�WEAK�2.
Hypothesis 4. �221>0.
Hypothesis 5. �112>0.
Hypothesis 6. �ACROSS�MODULAR�12<0.
6.2.2. Step 2: Estimate Parameters by Fitting Ourlogit p∗ Models to Observed Data. Fitting a logit p∗
model to data can be done (albeit approximately) byadopting the pseudo-likelihood estimation strategydiscussed by Wasserman and Pattison (1996), Patti-son and Wasserman (1999), and Robins et al. (1999).This approach assumes that the logits, �ijm, of theconditional probabilities are statistically independent.Hence, maximizing the pseudo-likelihood function isequivalent to fitting a logistic regression model to thelogits, �ijm, using standard computing packages (weused SPSS 11.0). Note that the explanatory variablesin the logistic regressions are the difference networkstatistics, that is, the change in network statistic fromtie �ij�m being present to being absent. Hence, before
fitting any of the models, we need to pre-process theobserved data to calculate the change statistic for eachrelational tie Xijm. �Xijm is the observed tie for pair�i�j of type m, where m=1 for design interfaces, andm=2 for team interactions. We modified SPSS codesto calculate the change statistics of interest. The codesare available from the authors upon request.)Following Anderson et al. (1999, p. 49), we assess
(approximately) the statistical importance of anyexplanatory variable by evaluating the difference inpseudo-likelihood ratio statistics �G2
PL by referringit to the appropriate �2 distribution. We also evalu-ate (approximately) the significance of each parameterby comparing their pseudo-Wald statistics (WaldPLto the appropriate �2 distribution. Table 1 shows theresults of fitting six dichotomous bivariate logit p∗
models to test Hypotheses 1, 4, 5, and 6. Table 2 showsthe results of fitting four trichotomous logit p∗ modelsfor testing Hypotheses 2 and 3. For brevity, Tables 1and 2 exhibit parameters corresponding to alignmentnetwork effects only. (See online Appendix C fordyadic and triadic parameters associated with bothdesign interfaces and team interactions.)
6.2.3. Step 3: Interpret Parameters from LogisticRegressions. In general, a significantly positive pa-rameter indicates a tendency for the associated con-figuration to occur in the network, whereas negativeparameters suggest a lack of presence. In Table 1,Model 1 includes an insignificant exchange parameter��12, which indicates that design interfaces are notlikely to be reciprocated by team interactions (nor viceversa). Most of the improvement in fit of Model 1 is
Table 1 Results of logit p∗ Analysis (Dichotomous Relations)
Parameters Model 1 association Model 2 across Model 3 indirect Model 4 ind. within Model 5 modular Model 6 all
Notes. WaldPL statistics are shown in parentheses. For approximate statistical inference we compare WaldPL against 2. Hence, p<0�1 if WaldPL>2�706.Models 3, 4, and 6 also include lower-order parameters I�12 and O�12. For Models 4 and 6, we define WITHINij to capture whether tie ij is within boundaries.
due to the significantly positive association parameter��12, which indicates a strong general tendency fordesign interfaces and team interactions to be aligned.We add the effects of group boundaries in Model 2,
which shows significantly negative clustering param-eters (�ACROSS�1 and �ACROSS�2 indicating, as expected,a strong tendency for both design interfaces and teaminteractions to be clustered within boundaries. Thethird-order parameter, �ACROSS�12, is significantly pos-itive, which indicates, contrary to Hypothesis 1, thatthe tendency for design interfaces and team interac-tions to be aligned is stronger across boundaries. Sim-ilar to our log-linear p1 results, Model 2 still shows anegative overall effect due to group boundaries. Thatis, Model 2 predicts that the overall probability fordesign interfaces and team interactions to be alignedis lower across boundaries than within boundaries(Robins et al. 1999).Model 3 shows no statistically significant param-
eters associated with indirect effects. Model 4, how-ever, shows that indirect effects are statisticallysignificant within boundaries. More specifically, thesignificantly positive �WITHIN�221 parameter indicatesthat there is stronger propensity for indirect teaminteractions configurations to be present withinboundaries (in line with Hypothesis 4). On the otherhand, the significantly negative �WITHIN�112 parameterindicates that indirect design interface configurationsare much less likely to occur within boundaries thanacross boundaries.
Notes. WaldPL statistics are shown in parentheses. For approximate statistical inference we compare WaldPL against 2. Hence, p<0�1 if WaldPL>2�706.a To test that �STRONG�2>�WEAK�2, we estimate a reduced model with a single parameter ��1�2�, whose G2
PL=2�352�179. Hence, �G2PL=4�360, �df=1, and
p<0�05.b To test that �ACROSS�STRONG�2>�ACROSS�WEAK�2, we estimate a reduced model with a single parameter ��ACROSS�1�2�, whose G2
PL=2�335�637. Hence, �G2PL=0�332,
�df=1, and p>0�1.
Model 5 includes the effects of system modularity.The model suggests that modularity does not directlyinfluence the alignment of interfaces and interactions(i.e., insignificant �MODULAR�12), however, its signifi-cantly negative �ACROSS�MODULAR�12 parameter indicatesthat when considering the cases across boundaries, thepure propensity of design interfaces and team inter-actions to be aligned is significantly lower betweenmodular systems (in line with Hypothesis 6). Thesefindings coincide with our p1 results.Finally, Model 6 includes all the effects together.
All relevant parameters are still significant withthe exception of �ACROSS�MODULAR�12, which becameslightly nonsignificant (i.e., p=0�131). Further analy-sis not included here indicates that �ACROSS�MODULAR�12becomes nonsignificant only in the presence ofindirect design interface effects within boundaries��WITHIN�112). As a result, we conclude that the propor-tion of misaligned cases is significantly greater acrossmodular systems (Model 5), but some of those mis-aligned cases coincide with indirect design interfaces(Model 6). We could not cross-validate this result withour p1 analysis due to its inability to capture triadiceffects.In Table 2, Model 2 includes clustering effects
resulting in significantly negative parameters��ACROSS�WEAK��ACROSS�STRONG, and �ACROSS�2 confirm-ing that both team interactions and design interfaces(at both levels) tend to be clustered within bound-aries. Model 3 includes statistically significantassociation parameters. In line with Hypothesis 2,we found that strong design interfaces are morelikely to be aligned with team interactions than areweak design interfaces (i.e., �STRONG�2 is significantlygreater than �WEAK�2). Model 4 includes third-orderparameters to capture whether there is a significantdifference of the association effect across boundaries.We found that �ACROSS�WEAK�2 and �ACROSS�STRONG�2
are not significantly different, indicating that effectsdue to design interface strength do not dominateover organizational and system boundaries effects(contrary to Hypothesis 3). We obtained similarresults in our log-linear p1 analysis.
7. Discussion of ResultsTo properly test our hypotheses, we built several p1and p∗ models of the alignment matrix. As expected,we found a strong tendency for design interfaces andteam interactions to be aligned throughout the net-work. Even this basic result is tremendously rele-vant, as it suggests that managers should be able toexplicitly examine the product architecture to planfor cross-team interactions when organizing designteams. However, our results also indicate that man-agers need to be wary of factors that may prevent aperfect alignment of interfaces and interactions.When evaluating the effects of boundaries in our
statistical models, we found that clustering effectsare very strong, both in the product and organiza-tional domains. Surprisingly, group boundaries didnot hinder the alignment of design interfaces andteam interactions (as hypothesized in Hypothesis 1)but significantly strengthened such alignment. Yet weobserve a significantly lower proportion of alignedcases across boundaries. The reason for this appar-ently contradictory result is that the effects of organi-zational/system boundaries have two components, aclustering component and a pure alignment component,which when considered jointly result in smaller prob-abilities of finding aligned ties across boundaries. Bydisentangling clustering and pure alignment effectsin our models, we found that the latter is signif-icantly stronger across boundaries. Because cluster-ing parameters capture the capability of product andorganizational structures to group interdependences
within boundaries, the denser the clusters become, thegreater the opportunity for alignment within bound-aries and the lesser the opportunity for alignmentacross boundaries. Thus, the main hindering effectof organizational and system boundaries is to lowerthe expected level of alignment across boundaries. Inour study, 52% of the cross-boundary design inter-faces unmatched by team interactions and 25% ofthe cross-boundary team interactions unmatched bydesign interfaces are actually better than expected,considering such strong clustering effects. As a result,managers should still expect (and prepare for) a signif-icantly greater proportion of misaligned cases acrossboundaries.At Pratt & Whitney, managers made special efforts
to handle cross-boundary interdependences by usingan integration tool called a Component Require-ments Document (CRD). The purpose of this tool wastwofold: to encourage design optimization by break-ing down design requirements to the system level,and to encourage cross-boundary interactions by hav-ing teams regularly update the document. Even withthe use of this tool there were both unmatched inter-actions and unmatched interfaces. For example, ateam in the low-pressure turbine (LPT) group real-ized that they needed to meet with a Fan systemteam to estimate the impact of a Fan test require-ment that would transmit high loads throughout theengine. However, in two other cases teams adheredto the stated requirements and did not feel the needto interact (across group boundaries) to review theirinterfaces. Had they done so, they would have dis-covered additional load transfer interfaces not explic-itly defined in the CRD that were left uncheckedand led to problems later. These examples illustratethe difficulty of managing cross-boundary interde-pendences. On the one hand, teams themselves dis-cover unknown interfaces which are more likely tobe across system boundaries, and on the other hand,known interfaces are more likely to be mismanagedwhen they occur across boundaries. This illustratesour need to better understand which factors moderatethe alignments across (and within) boundaries.We found that the stronger the design interface,
the greater the likelihood that teams would inter-act (Hypothesis 2), which is in line with previousresearch about team interdependence. Although thisresult could be considered as “good news” for man-agers who might believe design interface strengthdrives the alignment of design interfaces and teaminteractions across organizational/system boundaries(Hypothesis 3), we did not find empirical support forthis latter hypothesis. This can be interpreted as “badnews” for managers because even if cross-boundaryinterfaces are critical, the likelihood that they areunmatched by the corresponding interaction may be
the same as if they were noncritical interfaces. Follow-up interviews with engineers in our study qualita-tively corroborated these results. They confirmed thatmany strong cross-boundary design interfaces wereperceived as weak interfaces and, therefore, no plan-ning mechanisms were in place to address them. Thisindicates that managers must identify and managecritical cross-boundary interfaces without relying ontheir level of importance as a mechanism to improvetheir alignment with interactions.We found significant evidence that the effects of
indirect interactions (Hypothesis 4) exist within groupboundaries. This suggests that design teams use otherintermediary teams (most likely within their groups)to obtain relevant technical information. In our study,many design interfaces included spatial dependenciesthat were not supposed to change due to the deriva-tive requirements of the product. Yet while the spatialdependencies were supposed to remain unchanged,those interfaces had other functional design depen-dencies (such as structural or thermal loadings) thatdid change. Teams within organizational boundariesrecognized unplanned functional changes by natureof their “proximity to the action.” They had interac-tions with common teams in their groups in whichthey discovered and effectively reviewed unplannedchanges from other teams that affected them.Follow-up interviews indicated that the effects
of indirect design interfaces (Hypothesis 5) existedacross components of some modular systems (e.g.,combustion chamber (CC) and Fan systems), yet ourresults do not allow us to generalize such a qualitativeobservation throughout the product. However, wefound that the propensity of finding unmatched teaminteractions covering indirect design interfaces withinboundaries is significantly lower than across bound-aries, which coincides with our qualitative observa-tion.When studying the effects of system modularity,
we found evidence that the hindering effects of sys-tem and organizational boundaries are more severebetween modular systems than with integrative sys-tems. This result partially supports the categoricaldata analysis presented in Sosa et al. (2003), becausealthough the moderating effects of system modular-ity are significant when controlled for basic dyad andtriadic effects, they become nonsignificant when con-trolled for the effects of indirect design interfaces.This indicates that some of the unmatched team inter-actions (across modular systems) can be considered“good” misalignment cases because they occurredto resolve system-level dependencies, such as thoserelated to the Fan test requirement. On the other hand,our results also show a significantly larger propor-tion of unmatched design interfaces across modularsystems. This poses an important consideration for
managers developing products that involve modularsystems because it suggests that modularization itselfmay further hinder design teams’ ability to handleinterfaces across boundaries. In follow-up interviewsat Pratt & Whitney, some teams reported to be moreapt at handling integrative rather than modular sys-tem interfaces due to a tendency for those integra-tive interfaces to impact more than one aspect of theirdesign. For example, the Intermediate Case team ofthe low-pressure compressor (LPC) group was highlydependent on detailed definition of the engine oil andsecondary flow systems, for which it interacted regu-larly with the externals and controls team.
7.1. Impact on PerformanceMany design interfaces across boundaries were un-matched by team interactions because they wereeither weak or perceived as weak interfaces. Onereason for these unmatched interfaces is that teamsacross boundaries did not have opportunities for indi-rect interactions to communicate or discover changesassociated with them. We found this to be particularlyrelevant for structural and thermal design dependen-cies. The impact of these missed weak interfaces wastypically a very small reduction in performance ordurability of affected components and systems. Giventhe 25- to 30-year product life expectancy, however,even these small performance deviations may causesignificant warranty or service expense over the lifeof the product. Hence, the need for careful attentionto all cross-boundary interfaces.In contrast, the programmatic impact of missing
strong design interfaces across boundaries could bedramatic. While the PW4098 engine development pro-gram set new industry standards in developmentspeed and cost, there were still major setbacks dur-ing the program. Two of these resulted from designteams from different modular systems who did notcapture strong design interfaces between them. Thecosts associated with the two unmatched interfaceswere related to the time in which it took for the prob-lems to be discovered. One caused excessive loadson assembled hardware in early development tests,resulting in severely distressed hardware and specialdisassembly procedures. This resulted in significantcost and delays in the program to redesign the com-ponents affected and rebuild the test engines. Theother also caused excessive loads and reduced life toa critical engine component, but was not discovereduntil the first engines entered service. This problemcost substantially more to rectify, as it affected enginesboth in production and in development tests.There were 25 unmatched team interactions across
modular systems, many of which corresponded tounidentified design interfaces. Many of these werereportedly related to investigations into possible
engine-level design conditions which manifested inadverse structural or thermal load transmission orinsufficient pressures. Some teams were using theirexperience with prior generation engines to uncovernew direct and indirect design interface character-istics prior to the development of tests where theywould be evaluated. This type of team interaction isalmost universally positive as it serves to improveproduct performance and reduce downstream designiterations.
8. Conclusions and ImplicationsPrevious research has studied product architecturedecisions and technical communication patterns inproduct development from separate viewpoints. Herewe integrated these two perspectives to study andexplain the misalignment of product and organi-zational structures during detailed design of com-plex development efforts. This work contributes tothe product innovation literature, in both productarchitecture and organizational perspectives, by un-covering factors that impact the likelihood that(1) product-related interdependences are not ad-dressed by team interactions, and (2) design teamsinteract despite the absence of a product-related inter-dependence between them.Our results show not only that the likelihood of
misalignment is greater across organizational and sys-tem boundaries, but also that weak and strong inter-faces may be equally affected by boundary effects,that indirect interactions are an important coordina-tion mechanism within boundaries, and that systemmodularity may prevent the alignment of interfacesand interactions across boundaries.From an analysis viewpoint, we illustrate how to
formally build statistical models based on social net-works methods for proper hypothesis testing usingDSM-type data. We use a novel statistical technique(the logit p∗, developed by Wasserman and Pattison1996) to estimate statistical models that control fordyadic and triadic network effects. We also illustratehow the use of p∗ models opens up new avenues forresearchers interested in testing the effects of networkstructures that involve three players. Although the p∗
formulation is very robust from a statistical modelingviewpoint, fitting these models to data is still doneapproximately. We also tested the robustness of ourresults by completing a log-linear p1 analysis. Futureresearch will benefit from ongoing efforts focusing onalternative fitting strategies of p∗ models.As in many other empirical studies that collected
data in a single organization (e.g., Morelli et al.1995, Van den Bulte and Moanaert 1998), we cannotclaim the generality of our findings before completingsimilar studies in other types of products in differ-ent industries. However, we would expect to obtain
analogous results in other projects developing com-plex systems and where teams are organized accord-ing to the product architecture, as we observe to bethe case in automobile and aerospace industries. Thisstudy is descriptive in nature and as such, we avoiddrawing explicit prescriptive conclusions.
8.1. Managerial ImplicationsIn addition to the managerial repercussions of eachresult, as discussed above, this research has impor-tant implications for managers from two different per-spectives. From a strategic viewpoint, Henderson andClark (1990, p. 28) highlighted the fact that “learn-ing about changes in the architecture of the productis unlikely to occur naturally. Learning about changesin architecture—about new interactions across com-ponents (and often across functional boundaries)—may therefore require explicit management and atten-tion.” By documenting the architecture of the productfor every generation of a product family, managerscan identify key differences (i.e., new or removedinterfaces) between old and new architectures. Bybuilding an alignment matrix, managers have a com-pact and visual representation that allows them todiagnose how their organization addresses designinterfaces of the product under development. Fur-thermore, the alignment matrix helps managers pin-point their efforts to align team interactions withdesign interfaces to effectively develop distinct prod-uct architectures.From a project management perspective, our ap-
proach helps managers integrate activities of designteams across organizational and functional bound-aries. This is particularly beneficial in projects ofincremental and modular innovation, in which theproduct architecture is well understood. Our analysissuggests that managers should focus their effortson understanding the causes of unmatched designinterfaces and unmatched team interactions acrossmodular systems. These are the design interfaces mostdifficult to identify or be addressed by the corre-sponding design teams, even if they are critical designinterfaces. For example, some of the 25 unmatchedteam interactions between modular systems in ourstudy were critical design interfaces that had notbeen previously identified by design experts. As aresult of our study, managers learned about theseinterdependencies and established dedicated designteams or formally extended the responsibility of exist-ing teams to explicitly handle these critical cross-boundary design interfaces during the developmentof the next engine. These teams were also held respon-sible for managing the unmatched design interfacesthat resulted in the problems described in §7.1. Forexample, two teams were formed to manage theburner profile effects on downstream components and
the fan blade-out loads throughout the engine. Theimplementation of our approach provided a struc-tured way to identify which design interfaces theseteams would manage in future engine designs.
8.2. Research ImplicationsThis paper opens a new stream of research on theinterface of product architecture and organizationalstructure. By uncovering the existence of unmatchedteam interactions, we provide empirical evidence thatproduct ambiguity exists, and it is more likely to bepresent across organizational and system boundaries�Which components are more likely to have unknowninterfaces? How can managers of complex designefforts discover those unknown interfaces? We alsoprovide evidence suggesting that teams may fail toperceive the actual criticality of their cross-boundarydesign interfaces. What architectural and organiza-tional mechanisms influence teams’ cognitive capa-bilities across boundaries? Our results also indicatethat indirect interactions act as an important coordi-nation mechanism within boundaries. We need to bet-ter understand what types and conditions of indirectinteractions contribute to the performance of complexdevelopment projects, and how they can be promoted.All these questions are important and merit furtherresearch in both engineering design and managementscience domains.We studied the static effects that influence the align-
ment of interfaces and interactions. An interestingmethodological and statistical challenge for futureresearch is to explore the evolution over time of suchalignment. Are alignment matrices in a product fam-ily more likely to exhibit an increasing proportion ofunmatched design interfaces and team interactions asproduct families evolve? Finally, this paper providessome limited examples to illustrate the importance ofcertain kinds of misalignment, however, further sys-tematic research is needed to understand their per-formance implications. To obtain the greatest benefitfrom preemptively changing organizational or prod-uct structures, it is critical to understand what kindsof misalignments are most costly and why. Moreover,under what circumstances is an organizational designthat mirrors the architecture of the product a goodone?An online supplement with the appendices is avail-
able at http://mansci.pubs.informs.org/ecompanion.html.
AcknowledgmentsFunding of this research was provided by the MIT Centerfor Innovation in Product Development. The authors appre-ciate the assistance of the engineers and managers at Pratt &Whitney Aircraft and insightful comments by ChristopheVan den Bulte, Dawn Iacobucci, William Lovejoy, ChristophLoch, Luk Van Wassenhove, the associate editor, and three
anonymous reviewers. The authors also thank PhilippaPattison for insights in data analysis issues.
ReferencesAdler, P. S. 1995. Interdepartmental interdependence and coordina-
tion: The case of the design/manufacturing interface. Organ.Sci. 6 147–167.
Alexander, C. 1964. Notes on the Synthesis of Form. HarvardUniversity Press, Cambridge, MA.
Allen, T. J. 1977. Managing the Flow of Technology. MIT Press,Cambridge, MA.
Ancona, D., D. Caldwell. 1992. Bridging the boundary: Externalactivity and performance in organizational teams. Admin. Sci.Quart. 37 634–665.
Anderson, C., S. Wasserman, B. Crouch. 1999. A p∗ primer: Logitmodels for social networks. Social Networks 21 37–66.
Baldwin, C., K. Clark. 2000. Design Rules: The Power of Modularity.MIT Press, Cambridge, MA.
Brown, S. L., K. M. Eisenhardt. 1995. Product development: Pastresearch, present findings, and future directions. Acad. Manage-ment Rev. 20 343–378.
Cummings, J. 2004. Work groups, structural diversity, and knowl-edge sharing in a global organization. Management Sci. 50(3)352–364.
Eppinger, S. D., D. E. Whitney, R. P. Smith, D. A. Gebala. 1994.A model-based method for organizing tasks in product devel-opment. Res. Engrg. Design 6(1) 1–13.
Galbraith, J. R. 1973. Designing Complex Organizations. Addison-Wesley Publishing, Reading, MA.
Granovetter, M. 1973. The strength of weak ties. Amer. J. Sociology78(6) 1360–1380.
Hansen, M. 1999. The search-transfer problem: The role of weakties in sharing knowledge across organization subunits. Admin.Sci. Quart. 44(1) 82–111.
Hansen, M. 2002. Knowledge networks: Explaining effectiveknowledge sharing in multiunit companies. Organ. Sci. 13(3)232–248.
Henderson, R., K. Clark. 1990. Architectural innovation: The recon-figuration of existing product technologies and the failure ofestablished firms. Admin. Sci. Quart. 35(1) 9–30.
Holland, P. W., S. Leinhardt. 1981. An exponential family of prob-ability distributions for directed graphs. J. Amer. Statist. Assoc.76 33–51.
Krackhardt, D. 1988. Predicting with networks: Nonparametricmultiple regression analysis of dyadic data. Social Networks 10359–381.
Krishnan, V., K. Ulrich. 2001. Product development decisions:A review of the literature. Management Sci. 47(1) 1–21.
Loch, C., C. Terwiesch. 1998. Communication and uncertainty inconcurrent engineering. Management Sci. 44(8) 1032–1048.
Marsden, P. V. 1990. Network data and measurement. Ann. Rev.Sociology 16 435-463.
Marsden, P. V., K. E. Campbell. 1984. Measuring tie strength. SocialForces 63 482–501.
Mihm, J., C. Loch, A. Huchzermeier. 2003. Problem-solving oscil-lations in complex engineering projects. Management Sci. 46(6)733–750.
Morelli, M. D., S. D. Eppinger, R. K. Gulati. 1995. Predicting tech-nical communication in product development organizations.IEEE Trans. Engrg. Management 42(3) 215–222.
Pahl, G., W. Beitz. 1991. Engineering Design, A Systematic Approach.Springer-Verlag, New York.
Pattison, P., S. Wasserman. 1999. Logit models and logistic regres-sions for social networks: II. Multivariate relations. British J.Math. Statist. Psych. 52 169–193.
Pich, M., C. Loch, A. De Meyer. 2002. On uncertainty, ambiguity,and complexity in project management. Management Sci. 48(8)1008–1023.
Pimmler, T. U., S. D. Eppinger. 1994. Integration analysis of productdecompositions, Proc. ASME Design Theory Methodology Conf.,DE-Vol. 68, 343–351.
Robertson, D. C., T. J. Allen. 1992. Managing CAD systems inmechanical design engineering. IEEE Trans. Engrg. Management39(1) 22–31.
Robins, G., P. Pattison, S. Wasserman. 1999. Logit models and logis-tic regressions for social networks, III. Valued relations. Psy-chometrika 64 371–394.
Sanchez, R., J. T. Mahoney. 1996. Modularity, flexibility, and knowl-edge management in product and organization design. Strate-gic Management J. 17 (Winter Special Issue) 63–76.
Schrader, S., W. Riggs, R. Smith. 1993. Choice over uncertainty andambiguity in technical problem solving. J. Engrg. Tech. Manage-ment 10 73–99.
Smith, R. P., S. D. Eppinger. 1997. Identifying controlling featuresof engineering design iteration. Management Sci. 43 276–293.
Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003. Identifying mod-ular and integrative systems and their impact on design teaminteractions. J. Mech. Design 125(2) 240–252.
Sosa, M. E., S. D. Eppinger, M. Pich, D. McKendrick, S. Stout. 2002.Factors that influence technical communication in distributedproduct development: An empirical study in the telecommu-nications industry. IEEE Trans. Engrg. Management 49(1) 45–58.
Steward, D. 1981. The design structure matrix: A method for man-aging the design of complex systems. IEEE Trans. Engrg. Man-agement EM-28(3) 71–74.
Stone, R. B., K. L. Wood, R. H. Crawford. 2000. A heuristic methodfor identifying modules for product architecture. Design Stud.21(1) 5–31.
Terwiesch, C., C. H. Loch, A. De Meyer. 2002. Exchanging prelim-inary information in concurrent engineering: Alternative coor-dination strategies. Organ. Sci. 13(4) 402–419.
Thompson, J. D. 1967. Organizations in Action. McGraw Hill,New York.
Tushman, M. L. 1977. Special boundary roles in the innovation pro-cess. Admin. Sci. Quart. 22 587–605.
Tushman, M. L., R. Katz. 1980. External communication and projectperformance: An investigation into the role of gatekeeper.Man-agement Sci. 26(11) 1071–1085.
Ulrich, K. T. 1995. The role of product architecture in the manufac-turing firm. Res. Policy 24 419–440.
Ulrich, K. T., S. D. Eppinger. 2004. Product Design and Development,3rd ed. McGraw Hill, New York.
Van den Bulte, C., R. K. Moenaert. 1998. The effects of R&D teamco-location on communication patterns among R&D, market-ing, and manufacturing. Management Sci. 44 S1–S19.
Wasserman, S., K. Faust. 1994. Social Network Analysis. CambridgeUniversity Press, New York.
Wasserman, S., P. Pattison. 1996. Logit models and logistic regres-sion for social networks: I. An introduction to Markov graphsand p∗. Psychometrika 61 401–425.
Whitney, D. 2004. Mechanical Assemblies: Their Design, Manufactur-ing, and Role in Product Development. Oxford University Press,New York.
Yassine, A., N. Joglekar, D. Braha, S. Eppinger, D. Whitney. 2003.Information hiding in product development: The design churneffect. Res. Engrg. Design 14(3) 131–144.
