the limits of design and engineering outsourcing ... · the limits of design and engineering...

The limits of design andengineering outsourcing:performance integration and theunfulfilled promises of modularity

Francesco Zirpoli1 and Markus C. Becker2

1Department of Management, Universita Ca’ Foscari Venezia, Fondamenta San Giobbe, 873Cannaregio, 30121 Venezia, Italy. [email protected] Organization Design Unit, University of Southern Denmark, Campusvej 55, DK-5230Odense M, Denmark. [email protected]

Outsourcing design and engineering tasks in product development is increasingly popular.However, firms that outsource design and engineering tasks often experience problems. So far,no satisfactory answer exists regarding the question to what extent design and engineeringtasks can be outsourced before negative consequences occur. We address this gap. This paperidentifies the limits of design and engineering outsourcing in product development, and thesources of these limits. To do so, it investigates the organizational challenges that a majorEuropean automotive manufacturer faced when it decided to adopt an extreme form of designand engineering outsourcing. Based on an in-depth case study, we identify the sources ofproblems with outsourcing design and engineering tasks in product development, and shed lighton the limits of design and engineering outsourcing in product development.

1. Introduction: the advantages and limitsof design outsourcing

Outsourcing design and engineering tasks inproduct development is increasingly popu-

lar. From the early nineties, the innovation litera-ture promoted involving suppliers in productdevelopment, emphasizing that they could playa key role in successfully developing complexproducts (Womack et al., 1990; Clark and Fuji-moto, 1991; Wheelwright and Clark, 1992). Thefocus of attention of this research was on thedevelopment practices of Japanese firms, whosesuccess in terms of product development was seenin large part due to the heavy involvement ofsuppliers in the new product development process(henceforth ‘NPD’) (Clark, 1989; Nishiguchi,

1994; Bensaou, 1999). Considered best practices(Imai et al., 1985), they became models, whichwere imitated by Western firms (Womack et al.,1990), and the object of study of early supplierinvolvement (‘ESI’) (Helper, 1991; Smitka, 1991;Lamming, 1993; Nishiguchi, 1994; Helper andSako, 1995; Sako, 2004).2

In many complex product industries, pressuresfor involving external sources of innovation haveincreased due to changes in external conditions(Sturgeon, 2002); the evolution of markets fortechnology and technological development ser-vices (Arora et al., 2001) has resulted in a general-ized tendency toward vertical disintegration,modularization, outsourcing, and networking inproduct development (Langlois, 2002; Ches-brough and Crowther, 2006; Howells et al.,

R&D Management 41, 1, 2011. r 2010 The Authors. R&D Management r 2010 Blackwell Publishing Ltd, 219600 Garsington Road, Oxford, OX4 2DQ, UK and 350 Main St, Malden, MA, 02148, USA

mailto:[email protected]




2008). It is very difficult for one individual firm tomaster all the knowledge required to designcomplex products, because the sources of indus-try expertise are so widely dispersed, and theknowledge bases that firms need to draw on fordesigning and producing complex products arerapidly expanding (Freeman, 1991; Powell et al.,1996; Grandori and Kogut, 2002; Christensen,2006). Thus, relying on suppliers enables firms totake advantage of the specialist knowledge thatsuppliers possess. Drawing on suppliers facili-tates spanning the wide range of different tech-nological domains required, and drawing on deepspecialist knowledge in each.3 Outsourcing de-sign and engineering tasks to suppliers becameone popular way of involving suppliers in pro-duct development so as to draw on their specialistknowledge.

The idea of modularity played an importantrole regarding the implementation of design out-sourcing. In particular, Sanchez and Mahoney’s(1996) paper had a massive impact on how toorganize innovation, focusing primarily on pro-duct architectures as the main lever for managingdesign and engineering outsourcing. There areseveral definitions of modularity (Ulrich, 1995;Sanchez, 1997; Baldwin and Clark, 2000). Bald-win and Clark (2000), define modularity as adecomposition scheme that assumes indepen-dence between modules, with interdependenciesconfined within module boundaries. Modulestherefore interact only across standardized inter-faces (Baldwin and Clark, 2000). Ulrich (1995)provided not only a somewhat different but alsoinfluential definition of modularity. In his defini-tion, architectures are modular if there is a one-to-one mapping from functional elements to thephysical components of the product, which spe-cifies de-coupled interfaces between components(Ulrich, 1995: p. 422).4 The reason why the idea ofmodular product architectures was linked toefforts of design outsourcing is that modularproduct architectures provide advantages thatare very powerful when design and engineeringtasks are outsourced. Modular product architec-tures enable parallel development of moduleswithout the need to coordinate such development– the fit between the different modules is providedbecause the modules conform to a standardizedformat of their interfaces. This makes it botheasier and more feasible to allocate tasks outsidethe boundaries of the firm (Siggelkow and Le-vinthal, 2003; Ethiraj and Levinthal, 2004). San-chez and Mahoney (1996: p. 73) went one stepfurther and argued that ‘the creation of modular

product architectures . . . enables the design ofloosely coupled, flexible, ‘modular’ organizationstructures.’ Design outsourcing that leverages theadvantages of modular product architecturetherefore became wide-spread, in the attempt toleverage the benefits of involving external sourcesof innovation in the product developmentprocess.

Yet, despite the advantages that design andengineering outsourcing promise, empirical re-search shows that many firms developing com-plex products have incurred negative effects whenimplementing design and engineering outsour-cing. A first limit seems to arise from industryspecificities that restrict the degree to which theproduct architecture can be modularized. Indus-tries such as the PC and other electronic productsseem particularly prone to modular architectures,and there are few indications that firms experi-ence problems in organizing their innovationactivities (Baldwin and Clark, 2000; Sturgeon,2002). This does not necessarily hold in othercontexts. In the automotive industry, for exam-ple, the beneficial effects of modular productarchitectures in product development haveturned out to be far fewer than expected (not-withstanding benefits in manufacturing and as-sembly) (Takeishi and Fujimoto, 2003;MacDuffie, 2008). The product architecture ofthe automobile seems to be characterized bypersistent integrality (MacDuffie, 2008). Second,the literature that has followed Sanchez andMahoney (1996) has been criticized for havingneglected knowledge-related aspects. Scholarshave argued that alignment between productarchitecture, knowledge, and task partitioning isnot always a given fact (Brusoni et al., 2001;Chesbrough and Kusunoki, 2001; Takeishi,2001). The reason is that the knowledge held byfirms is the consequence of learning by doingopportunities connected to the allocation of de-sign and engineering tasks along the supply chain(Fine, 1998; Lincoln et al., 1998). This critiqueidentifies a precise organizational task that firmshave to address when leveraging external sourcesof innovation: to maintain a knowledge base thatis broader than the immediate knowledge re-quired for the development of the products andservices produced (Brusoni et al., 2001). Buildingon these insights, the literature on system inte-gration5 has developed advice on how to organizeby taking into account the organizational issuesarising from modular product architectures andthe problems of knowledge erosion triggered bymodular product architectures (Brusoni and

Francesco Zirpoli and Markus C. Becker

22 R&D Management 41, 1, 2011 r 2010 The AuthorsR&D Management r 2010 Blackwell Publishing Ltd

Prencipe, 2001; Mikkola, 2003, 2006; Ernst, 2005;Frigant and Talbot, 2005; Miozzo and Grim-shaw, 2005; Staudenmeyer et al., 2005).6 Thisdebate, too, cautions against relying on modularproduct architectures as a guide of how toimplement design outsourcing. There is, thus, ashared belief that relying on external sources ofinnovation is a necessary condition for managingcomplex product innovation. How to implementthe integration of external sources of innovationin the development process, however, has turnedout to be a complex issue in the case of productswhose architecture is integral (MacDuffie, 2008).Empirical evidence shows that, in this case, firmshave problems with implementing the integrationof external sources of innovation in the develop-ment process, and that there seem to be inherentlimits to outsourcing, beyond which, outsourcingproduces negative consequences.

Most of these negative consequences relate tocompetence accumulation problems. Pisano andTeece (2007: p. 294) highlight this point whenthey write, ‘vertical disintegration sharpens theneed and enhances the difficulties of systemsintegration, as it requires integrating the activitiesof parties when there is no common ownershiplink. Interface standards and modularity, ofcourse, facilitate outsourcing and thereby shar-pen requirements for integration. Failure at in-tegration in turn destroys any benefits associatedwith outsourcing in the first place. Systemicinnovation of course tends to render prior inter-face standards obsolete, and favors vertical in-tegration. Possession of the systems integrationcapabilities gives high-tech firms outsourcingchoices . . .With respect to complex systems,system integration capabilities could indeed be-come the bottleneck asset.’ In this respect, extantliterature has highlighted that the main problemwith extreme design and engineering outsourcingis that it can weaken firms’ ability to understandthe components of a product (Lincoln et al.,1998; Becker and Zirpoli, 2003). This, in turn,can weaken the understanding of the ways inwhich components are integrated into systemsand how to manage systems integration, that is,the firm’s architectural knowledge (Hendersonand Clark, 1990). One of the most importantrisks of extreme outsourcing, hence, is the ero-sion of architectural knowledge and loss of con-trol over product performance. This riskproduces a strong conflict between the benefitsof design and engineering outsourcing that arethe motivation to outsource and its drawbacks(Fine, 1998). On this aspect, the literature indicates

that the link between task partitioning (who doeswhat) and knowledge partitioning (who knowswhat) cannot simply be managed by relying onmodular product architectures (Brusoni, 2005),i.e., as a mechanistic consequence of a givenproduct decomposition scheme. The link ismuch more complex, and to manage it is a keyorganizational challenge for firms that developcomplex products. It thus becomes important tounderstand the causes of such complexity. AsTakeishi (2002) pointed out, the complexity de-rives from the way in which OEMs7 manage thedevelopment of architectural knowledge: productarchitecture and the related knowledge (Hender-son and Clark, 1990) cannot be controlled with-out underlying component specific knowledge(Takeishi, 2001). Takeishi’s work has contributedto direct scientific attention to the types of knowl-edge – component specific vs architectural – thatfirms should retain in house, and to the conse-quences that relying on external sources of in-novation has for the competences of OEMs.However, empirical evidence on whether OEMscan successfully retain architectural knowledgewhen they rely on external component knowledgehas, so far, been mixed (Takeishi, 2002). Ourknowledge of the precise interaction of this ap-proach to design outsourcing with the firm’sknowledge base remains incomplete (Brusoni etal., 2001; Mahnke, 2001).

In this paper, we tackle these issues by explor-ing why firms that outsource the development ofcomplex products often experience problems inimplementing this strategy. As we have seenfrom the review of prior research, while thereare insights into some of the problems, firms stillcontinue to incur negative consequences whenoutsourcing design and engineering tasks. Identi-fying the sources of these problems is also im-portant in order to better understand how largefirms should organize to successfully implementan open innovation strategy (a question specifi-cally identified by Chesbrough et al., 2006). Asrecent contributions show (e.g. Brusoni and Pre-ncipe, 2006), the detailed understanding of thecomplex organizational processes involved in im-plementing design and engineering outsourcingholds a key to developing our understanding ofwhat distinguishes successful forms of R&D or-ganization.

The article is structured as follows: Section 2presents the method, followed by the empiricalfindings in Section 3. We then turn to discuss thefindings in Section 4 and draw our conclusions inSection 5.

The limits of design and engineering outsourcing

r 2010 The AuthorsR&D Management r 2010 Blackwell Publishing Ltd

R&D Management 41, 1, 2011 23

2. Method

The research design we adopted was determinedby the nature of the research question we tackle.In our review of prior research, above, we sawthat existing theory does not yet offer a satisfac-tory answer to the question why firms that out-source the development of complex productsoften experience problems in implementing thisstrategy. While extant research has identifiedsome of the factors involved, the complex pro-cesses that generate the negative performanceconsequences of design and engineering outsour-cing are not yet fully understood. As qualitativedata are particularly suited for offering insightsinto complex social processes (Eisenhardt andGraebner, 2007), and more generally, for ‘why’questions (Eisenhardt, 1989; Pettigrew, 1990; Yin,1994), we chose to carry out an in-depth qualita-tive case study in order to contribute to fill thegap.

Our empirical observations have been gatheredon the NPD process of a technology-intensivefirm developing complex products. In particular,we focused on: (1) the decisions concerning theoutsourcing of design and engineering tasks tosuppliers; (2) the consequences of such outsour-cing for the knowledge of the firm and its suppli-ers; and (3) the firm’s organization for productinnovation (organizational structure, NPD pro-ject management, inter-firm and intra-firm coor-dination mechanisms). In the subsequent sections,we report respectively on how we selected ourcase, on the data sources and data collection, andon the data analysis process we used.

2.1. Case selection

In selecting the case, we used a theoretical sam-pling approach (Eisenhardt and Graebner, 2007).We carried out case selection in three steps. First,we selected the automotive industry. The auto-motive industry is one of the most complexindustries in terms of technologies and playersinvolved in innovation processes (Maxton andWormald, 2004). Moreover, the automotive in-dustry offers many opportunities to study therelationship of product architecture and the divi-sion of innovation tasks, and how such tasks arecoordinated (Takeishi and Fujimoto, 2003).Furthermore, the automotive industry is alsoone of the industries where the theoretical dis-cussion concerning the role of modularity as acoordination device in inter-firm cooperation

occurs (MacDuffie, 2008: p. 42). Second, weselected the focal firm to be studied. We choseAlpha, a multi-brand auto manufacturer whoseproduct range covers all market segments, fromluxury to small cars, from trucks to Formula 1racing cars. One of the attractive features ofAlpha is to provide the opportunity to comparedifferent degrees of design and engineering out-sourcing: Alpha had shifted quite radically frombeing a fully vertically integrated company (as faras design tasks are concerned) previously to anextreme outsourcer of design, before it subse-quently decided to once more reverse its taskallocation scheme. These changes were observa-ble within a time-span of only 10–15 years.8

These clear changes in the allocation of designtasks provide a good opportunity for an in-depthanalysis of the triggers and consequences ofdifferent ways of dividing design tasks, andthus, for casting light on the research question.Using theoretical sampling, we thus deliberatelyselected a case that was ‘very special in the senseof allowing one to gain certain insights that otherorganizations would not be able to provide’(Siggelkow, 2007: p. 20). Third, the two researchcenters of Alpha, as well as eight first-tier sup-pliers belonging to Alpha’s value chain, wereincluded in the field work. We selected supplierson the basis of the following criteria: (1) rele-vance in terms of contribution to Alpha’s devel-opment activities, (2) heterogeneity of theirindustry, technologies, dimension, ownership,and nationality, and (3) their independencefrom Alpha. The objective of this third step wasto observe the same units of analysis from thedifferent angles of the auto manufacturer, itsresearch centers and its suppliers. This seemsappropriate for a study of networked innovation,which by definition comprises the interactionsbetween different actors.

2.2. Data collection

We collected multiple types of data from differentsources to ensure an accurate representation andto be able to triangulate our findings betweendifferent types and sources of data. We collected(a) industry publications, (b) archival data andcompany documents, and (c) carried out inter-views with employees of Alpha, its research cen-ters, and eight first-tier suppliers.

(a) The study of industry publications wasmainly aimed at obtaining a solid understandingof recent developments in the industry (such as



technological developments characterizing the in-dustry, history of the industry, etc.) in order to beable to understand the situation Alpha faced aswell as its actions, and in order to formulateprecise questions that our interviewees couldrelate to easily.

(b) Our purpose in collecting archival data andcompany documents was to obtain a comprehen-sive overview of the formal procedures regulatingthe NPD process at Alpha, and the tools andprocesses Alpha uses for managing the involve-ment of suppliers in the product developmentprocess. We collected about 2,000 pages of officialOEM documents. They included norms and pro-cedures, which range from the description ofengineering solutions for technical problem sol-ving, over procedures concerning the organiza-tion of NPD, to the definition of contracts withexternal sources of innovation, and the segmenta-tion and classification of suppliers.

(c) Finally, we carried out interviews at Alphaand its suppliers. The interviewing process oc-curred as follows. First, we developed an inter-view guideline that comprised theoreticalvariables of interest that had emerged from aprevious review of the scientific literature. Sec-ond, company advisors at Alpha supported thedefinition of the interview agenda and helped usgain access to Alpha’s top management (as well asto archival sources). We drew up a list of inter-viewees we were interested in. The interviewees onour list were selected according to the relevance oftheir roles in the innovation process at Alpha andits first-tier suppliers. Table 1 provides an over-view of the interviews, which were carried out in2006.9 We deliberately involved people in chargeof strategic decisions as well as personnel withmore operative roles, in order to capture theperspectives of top management as well as thedetails provided by people involved in the execu-tion of the NPD process. We interviewed theChief Technology Officer, the Senior Vice Pre-sident of Human Resources, the Vice President ofProduct Portfolio Management (all three mem-bers of Alpha’s top-level steering committee), andthe Director of Vehicle Concept & Integration(i.e., the manager responsible for systems integra-tion for chassis and vehicle), four of the fivevehicle line executives (i.e., the engineers respon-sible for the development of cars in the small (A–B), medium (C), and upper (D–E), as well as thecommercial vehicle, segments), and the staff func-tions of the Design and Engineering division (theHuman Resources Manager and the DivisionController). We thus covered most of the top

managers in charge of the product developmentprocess. This set of interviews provided us with acomprehensive picture of Alpha’s perspective onthe questions of interest. Regarding the eightsuppliers involved in the 2006–2007 interviews,we interviewed ‘account managers’ (responsiblefor the commercial relationship with Alpha fromthe pre-offer phase until the end of the project)and ‘project managers’ (responsible for compo-nent or system development). In some cases, wealso interviewed the supplier’s CEO (Table 1).

From the overall interview guideline, we se-lected the questions that each interviewee wassupposedly most knowledgeable about. Finally,we carried out 80 hr of interviews. They weresemi-structured, guided by individual interviewguidelines. On average, interviews lasted for2.3 hr. Many of the interviews were carried outby both authors, but one of us was present duringall the interviews. All interviews were recordedand transcribed. At each field visit, field noteswere also taken.

2.3. Data analysis

Data collection and analysis were two iterativeprocesses. We started analyzing industry publica-tions and company documents before carryingout the interviews. However, after having com-pleted a first round of interviews and havinganalyzed them, we went back to re-analyze archi-val sources and eventually asked for additionalarchival data and information.

(1) The industry publications that we collectedhave been analyzed in order to identify newtechnological possibilities and challenges, newindustry trends, the strategic and operationalopportunities and threats facing Alpha, and Al-pha’s internal strengths and weaknesses. (Wesubsequently consulted industry experts to dou-ble-check our understanding.) This provided uswith a better understanding of the concrete situa-tion Alpha was in when we started the interviews,enabling us to break down and frame the theore-tically inspired research question in a way that wasclose to the everyday reality of our interviewees.Moreover, it provided us with concrete questionsfor our interview guideline, such as questionsabout specific industry events, participants, andso on, which contributed to better operationalizeour more abstract research questions.

(2) We systematically analyzed the archivaldata and company documents we had collec-ted at Alpha, generating from these detailed




documents an overview of (i) the formal systemAlpha had in place for structuring, managing, andgoverning the NPD process, and (ii) the formalsystem that Alpha had in place for dealing with itssuppliers. In order to do so, we built up a gridwith the items we intended to observe (e.g. sup-plier segmentation, the timing of supplier involve-ment in the NPD process, the design and

engineering activities that were outsourced, etc.)and the archival data (e.g. Alpha’s NPD manual,Alpha’s NPD projects reports, suppliers’ docu-mentation, etc.), mapped the contents of docu-ments into our categories and verified theconsistency of different data sources. Also, thisprocess was iterative as we double checked duringthe interviews also that, beyond the reliability of

Table 1. Interviews (period January 2006–December 2007)

Companyname

Product/role People interviewed Date ofinterview

Totallength ofinterviews(hrs)

Alpha Cars (European) VP Investor RelationsVP Product Portfolio ManagementVP Human ResourcesBusiness Development ManagerDirector of Vehicle Concept andIntegrationManufacturing DirectorVP Design & Engineering (CTO)Vehicle line executive segment A–BVehicle line executive segment CVehicle line executive segment D–EVehicle line executive segment CommercialVehiclesHR Director for Design & EngineeringDirector of Engineering&DesignInnovation&Pre-Program Concepts

8_02_20069_05_200623_06_200614_07_200611_07_200713_12_2007

28

AlphaResearchCentre

Research Center CEOBusiness Development DirectorTechnologies Division

8_02_200622_03_2006

5

Company A Sealing systems/supplier Plant General Manager, Engineering &Design Technical Director AssistantQuality Manager

21_02_200607_06_2006

9

Company B Brakes/supplier Business Development DirectorProduct Engineering R&D Manager BrakeSystems

28_03_2006 3

Company C Car design development,turnkey developmentprojects/supplier

Business Strategy Development ManagerProject ManagerTechnical Division ManagerCustomer ManagerProject Leader

23_03_200615_05_2006

10

Company D Chassis control (ABS –ESP, etc), power train, carmultimedia/supplier

Manager Automotive Technology ProductPlanning and MarketingCross Functional Project Manager

29_03_2006 4

Company E Car interiors, seats/supplier

CEOSenior Program ManagerAlpha Account Manager

9_02_200623_03_2006

5

Company F Safety systems (airbags,seat belts, brakes, chassiscontrol, ABS – tractioncontrol systems, etc.)/supplier

Account Director, Manager Programs &Application Engineering InflatableRestraint Systems

9_02_200623_03_2006

5

Company G Stamped parts in metal/supplier

Plant Manager 3_02_2006 5

Company H Thermal systems/supplier Sales & Marketing General Manager,Alpha Sales Manager, R&D ThermalSystems Division Manager

3_04_2006 6



the source, our classification of data was correct,and we eventually revisited it. This process helpedus to fine tune the questionnaire and contributedto ask specific questions about the formal instru-ments and mechanisms for how Alpha guided,monitored, and managed the NPD process, andthe involvement of its suppliers in that process. Itwas also crucial for being able to understandwhen interviewees’ descriptions actually did notconform to the formal picture, which in turnenabled us to systematically pursue such diver-gences in the following interviews. Often, suchquestions were crucial for describing the organi-zation as it was really implemented in practice.Moreover, the description of the formal organiza-tion of NPD enabled us to identify organizationalchanges in the formal organization, and relatethem to external events and internal decisions.

(c) As far as the analysis of the interviews isconcerned, we generated two types of documentsfrom the interviews: interview transcripts andfield notes with observations from the field,which extended beyond the conversation of theinterview to include our own reflections andremarks, as well as occasional observations, forinstance about the environment where the inter-views occurred, or objects such as prototypes thatwe were shown. We created a case study database(Yin, 1994) where we stored the interview guide-lines, the interview audio files, the interviewtranscripts, field notes, and separately from thedata, all documents that pertained to our inter-pretation and analysis (explained in more detailbelow). Regarding the field notes, immediatelyfollowing each of the field visits both authorscompared their individual field notes and dis-cussed their impressions of the field visit. As forthe interviews, we analyzed them as follows.Once the transcripts were available, we sharedthem and carefully reviewed each transcript in-dividually, each author for himself. In doing so,each of us did two things: First, we summarizedthe interview, to render what each of us thoughtwas the gist of the interview. These summariesserved to build up a case description, with regardto the aspects we were interested according to theresearch question (Yin, 1994). Second, we as-signed codes to passages in the text, categorizingthem according to topics they provided informa-tion on. We focused attention on data thatseemed to be particularly useful for casting lighton the research question (Yin, 1994). Based onthis coding of the text, each author then identifiedthe answers that seemed most interesting withregard to the overarching research question. The

overarching research question was then brokendown in many ways in the interview guideline. Inthe process of identifying the answers, we thussummarized and translated the detailed answersto individual questions in the interview back tothe overarching research question. Having com-pleted the individual review, we then comparedand discussed both our summaries of the inter-view. This served to check our understanding ofthe content of the interview. Where we did notagree, we considered the discrepancies in what wethought was the gist of the interview, until wearrived at a common understanding. We thendiscussed our coding of the interview, and whateach considered the most interesting content ineach category that we had used for coding theinterview. Discussing the meaning of the inter-views for answering the overarching researchquestion, we implemented our analytical strat-egy, i.e., to build an explanation by identifyingsets of causal links (Yin, 1994). It led to theidentification of causes of phenomena that wehad either asked about directly or discovered inthe interviews (for instance, the causes of lowproject performance or the reasons for reorgani-zation or a change in a relationship with asupplier). It also led to formulating provisionalpropositions, which we would pick up in subse-quent interviews. Those where we found nocontradicting evidence but where supporting evi-dence accumulated, later crystallized into themain findings. As the outcome of this processof discussing an interview, one of us wrote a notewith the result of this discussion, which wesubsequently shared. We repeated the process,thus generating interview summaries, coded ver-sions of the transcripts, and notes that capturedthe condensed result of our discussion of theanalysis of each interview. In the next step, wethen compared, summarized, and identified the‘big lines’ in the responses over all the interviewswhere there was consistence, and identifyingparts of the story where we could not identifyconsistence. From these ‘big lines’ of the data, wethen developed the answers to the research ques-tion by iterating among the case data, emergingtheory, and literature (Eisenhardt and Graebner,2007). Having identified the preliminary answersto the research question from the interviews, wethen engaged in triangulation. In particular, wetriangulated between different respondents, andbetween different types of data. First, we usedarchival data to reconcile diverse views we ob-tained through the interviews (we used the afore-mentioned grid to perform this task). In this




respect, we extensively used the rich documenta-tion of its NPD process that Alpha provided uswith. In the NPD process handbook, for exam-ple, we found both technical norms (e.g. how acomponent should be engineered, what compe-tences and knowledge bases were Alpha’s prior-ity, etc.) and organizational procedures (e.g.company structure, processes milestones, sup-plier segmentations, type of contracts and re-sponsibilities of suppliers, etc.). We constantlyverified the consistency of information gatheredfrom these two types of sources (company docu-ments and interviews). Second, we triangulateddata by systematically comparing the informa-tion gathered from staff belonging to differentorganizations. The baseline for comparison wasestablished by asking the same questions on thesame unit of analysis. Given the type of researchquestion, confronting the suppliers’ and OEM’sviews on the allocation of component specificknowledge, architectural knowledge, and theirdevelopment over time was fundamental tobuilding a comprehensive and articulate repre-sentation of reality. In fact, if we had confinedour analysis to Alpha’s perspective, we wouldnot have achieved a comprehensive representa-tion of reality. In this respect, the possibilityof gathering and triangulating data from eightdifferent suppliers was of paramount importance.This allowed us to obtain a more precise andarticulate picture of the strategy Alpha has actu-ally implemented in practice, as far as the alloca-tion of design activities along the supply chain isconcerned.

Our method is subject to limitations. Oursample could be biased by the fact that we onlyinterviewed companies located in one country,and belonging to one industry. However, the vastmajority of companies in the sample are localbranches of multinational corporations. More-over, technological heterogeneity somewhatcounterbalances industry specificity. As shownin Table 1, the companies analyzed belong tocompletely different sectors (from pure mechan-ical engineering to electronics, engineering con-sultancy, and rubber). Exposure to multipletechnological domains, product developmentpriorities, communities of practice, technical com-plexity, and system, component and module in-tegration characteristics during the researchprocess provided a source of learning and con-tributed to conclusions that are well informedand empirically grounded (although they can,of course, be neither normative nor generallyapplicable).10

3. Empirical findings

In this section, we first describe the evolution ofAlpha’s engineering and design strategy and howits implementation were organized, then turn toidentify the consequences produced by this strat-egy and by how it was implemented.

3.1. The evolution of Alpha’s verticalstructure for innovation

3.1.1. Phase 1: supply base rationalization (1987–1993)Around the beginning of the 1990s, Alpha’ssupply base was essentially limited to the domes-tic automotive components industry, and Alphawas still a highly vertically integrated company.Very few if any suppliers were involved in thedesign process: about 3,450 of the 3,500 technicaldrawings that make up the design of a car werecarried out by Alpha’s engineers. Moreover, Al-pha dealt with more than 3,000, mostly quitesmall, first-tier suppliers. In those years, rationa-lization needs were a priority and many effortswere dedicated to building a local supply basethat was competitive in terms of quality andproduction costs.11

3.1.2. Phase 2: toward extreme design outsourcing(1993–2001)Until the mid-1990s, supplier involvement inAlpha’s NPD was still limited to the phase ofindustrialization and production of componentsand systems. With the re-engineering of the NPDprocess in 1996, Alpha’s outsourcing strategygained speed, however. Alpha decided to movefrom outsourcing manufacturing tasks to suppli-ers (a practice already consolidated at that time)to outsourcing the design and engineering ofcomponents and systems. At the same time,Alpha began to frame suppliers’ contributionalso in terms of strategic partnerships to developcomplementary capabilities and to outsourcecomponents design. Alpha’s target for the endof 1990s was to outsource complete systems ofcomponents, and finally, complete pre-assembledmodules. The aim was to deal with just two typesof suppliers during the NPD phase: systems andmodule suppliers. Alpha did indeed reach anexceptional level of outsourcing: up to 85% ofthe total value of a car was engineered by suppli-ers at the beginning of the 1990s. By doing so,Alpha could leverage on a newly shaped tieredsupplier structure and was able to find suppliers



to build and pre-assemble modules. Between 1996and 2001, Alpha became one of the firms with thehighest degree of outsourcing of design engineer-ing in the automotive industry, becoming mostprobably the one which pushed design outsour-cing further than any other OEM in the industry.

Why did this happen? In the same way as othercar makers did, in those years Alpha needed tocope with new exogenous12 technologies. At thesame time, the group Alpha belongs to did not havesufficient resources to invest in the auto division.Moreover, at least at the beginning of the out-sourcing implementation, Alpha started appreciat-ing the benefits of increased strategic flexibility,reduction of development costs and lead time, andquality improvement yielded by the early involve-ment of suppliers in the NPD process. Ironically,for top management this confirmed the idea that nonew investments in the auto business were required,reinforcing a vicious circle the consequences ofwhich only became clear later on.

3.1.3. Phase 3: a new pattern toward in-sourcing(2002–2006)When we interviewed the manager at Alpharesponsible for product development in 2001, headmitted that Alpha had lost its competence todesign dashboards, suspensions, and occupantsafety systems. In the interview, he also reported,however, that Alpha had started a process of re-building some competences in house, whichwould have taken an estimated 5 years. Ourinterviews in 2006 confirmed this information:

When I arrived [in 2005] the situation wasdisastrous from the point of view of technicalcompetences and from an organizational pointof view. The business units were completelyout of touch. Through a very strange strategyof outsourcing, the firm had systematicallydestroyed the technical heart of the firm. Theengineering division was just another engineer-ing supplier that by accident was part of thefirm. Nothing more, nothing less.(Chief Technology Officer, 2006)

Our 2006 interviews, moreover, allow us to tracehow the recovery strategy was put into action. Ithad two important stages. First, Alpha realizedthat learning from suppliers had to become anobjective in itself, and a justification for involvingsuppliers in the product development process (i.e.,the main objective was to learn, rather than havesupport in designing a particular component orsystem). Suppliers were selected on the basis of

their competence and with an explicit agreementof sharing knowledge.13 In this respect, the de-creasing emphasis on cost aspects was a realnovelty for Alpha’s managers. Second, Alphastarted hiring staff knowledgeable in the areas inquestion, and to enable internal development andlearning (the most important areas in whichAlpha started acquiring competences that werelost previously were dashboards, suspensions,occupant safety systems, and virtual developmenttools). At the moment, Alpha has engineers thatpossess all the necessary competences to designand engineer a whole new car. It currently out-sources 50% of the design and engineering of newsystems, down from 85%. Note that 50% isconsidered ‘natural’ for the auto industry byAlpha’s managers – it being standard industrypractice to outsource the design and engineeringof components whose technology is mature (i.e.,the calliper for a brake), or not within the scope oftheir activities (i.e., electronic hardware).

Our interviews, however, show that not all theproblems in acting as a system integrator relatedto the level of outsourcing. Indeed, the problemswere not solved simply by increasing the numberof design tasks carried out in house. One of themain consequences of the outsourcing strategydescribed above, in fact, was that Alpha founditself in the very difficult situation of competenceerosion. Apparently, it had pushed outsourcingtoo far. The interesting question is: Precisely,which problems were triggered by too high adegree of engineering outsourcing? To cast lighton this, the following sub-section describes howsystems integration was organized at Alpha. Thisprovides an occasion to ‘read off’ the challengesraised by going beyond the limit of outsourcing.

3.2. Organizational aspects of systemintegration

3.2.1. The scope of the knowledge baseAccording to the managers we interviewed atAlpha, the main reason why Alpha’s systemintegration strategy failed was a considerablelack of technological competence in key areasand the way Alpha interpreted system integration.This observation is further substantiated by aconcise statement made by the Director of VehicleConcept and Integration:

It is naıve to believe you can integrate a systemwithout holding an in depth and detailedknowledge of the components that are going




to affect the performance of the whole car.Managing each system performance does not,in fact, automatically result in effective systemintegration. The performance is the ultimateobjective, not systems. (Director of VehicleConcept and Integration, 2006)

The Chief Technology Officer also underlined that:

. . . what matters is the cost of performance,not the cost of systems. (Chief TechnologyOfficer, 2006)

An illustration of the difference between integratingsystems and performances and of the role of specificcomponent knowledge is provided by the followingquote from an interview at a first-tier supplier ofsafety systems (airbags, seat belts, brakes, chassiscontrol, ABS – traction control systems, etc.):

Before the integration of the occupant safetysystem was outsourced to us, despite the factthat we did not control the design of all the(sub-)systems involved. In fact, we were notresponsible (or even competent) for the designof the chassis, the engine layout, and packa-ging, i.e. of components and systems that affectthe performance of the occupant safety system.After the successful frontal crash test of a keyvehicle for Alpha which obtained the maxi-mum score on the EuroNCAP test, we metwith Alpha people in order to consolidate thelessons learnt and draw some best practices toextend to future projects. In the meeting wecould not point to the reasons for successbecause neither Alpha nor we fully dominatedthe whole system performance, i.e. the interac-tions of all the components. After this, Alpharealized that they could not leave the fate of thenext occupant safety system developments toserendipity. Alpha re-internalized the respon-sibility for managing the overall OccupantSafety System. As a consequence, we havebeen relieved of being responsible for thewhole system performance and, now, developonly parts and components of the system.(Alpha Account Director at the supplier, 2006)

This example shows to what extent Alpha hadoutsourced system integration, and with it, fullcontrol of key vehicle performances. Alpha’s man-agers came to realize that acting as a systemintegrator without underlying component-specificknowledge was just not possible: without thisunderlying component-specific knowledge, systems

integration competence was difficult to achieve. Itwas precisely this kind of knowledge, however,which had been lost by focusing – a little too muchit seems – exclusively on the competence of systemsintegration. As a consequence, this affected itsability to reach given vehicle performances in areasconsidered highly relevant for customers (dash-board design or safety-NCAP test).

3.2.2. The organization of NPDOne of the basic problems was that due to theoutsourcing of certain design and engineeringtasks, there were simply no longer people in-house with competences to design dashboards,suspensions, and occupant safety systems at thelevel that was required.

To appreciate the situation, it is useful to look atthe changes in the internal structure adopted byAlpha in 1996–2001. Alpha had gradually adaptedit to fit its outsourcing strategy. Functional units(where component and system technologies weredeveloped) lost many engineers that were perma-nently staffed at the ‘platforms’ (in Alpha jargon,‘platforms’ are organizational units whose task is todevelop vehicles, all the way from concept toproduction ramp-up – not to be confused with theusual meaning of ‘product platform’). Platformsbecame the most important units of the company.They performed most of the design and engineeringof the vehicle, heavily leveraging on suppliers’competences, and were responsible for developmentprojects’s execution. The design and engineeringdivision accordingly became very ‘light-weight.’ Inthe words of the Chief Technology Officer:

Engineers in the company just delegated designand engineering to somebody else, usually outsidethe company. This was not acceptable for atechnology firm. (Chief Technology Officer, 2006)

The assumption underlying delegation was thatthe role of Alpha’s engineers was to put togetherthe systems developed by competent suppliers.The work of Alpha’s engineers – as they inter-preted it – was, hence, basically to coordinatesuppliers and manage the development projects.Such an interpretation did not lack a certainconsistency with a ‘light-weight’ design and en-gineering division (although that might or mightnot have been intended). This task consistedmainly in assigning (and monitoring) systems/components performances to suppliers, to beachieved in a specified time schedule at givencosts. In many cases, the level of specification ofsystems/components characteristics did not go far



beyond the setting of target price and perfor-mances. There was a problem, though. As themanager responsible for system integration put it:

In so doing, [Alpha] was losing the ability toset performance targets to suppliers and moni-tor their work. Most importantly, [Alpha] waslosing the ability to manage performancetrade-offs. Managing each system performancedoes not, in fact, automatically result in effec-tive system integration. (Director for VehicleConcept and Integration, 2006)

The managers we interviewed on the issue justi-fied the lack of competences in managing perfor-mances trade-offs at the systems and componentslevel as being the direct consequences of notcarrying out design activities concerning thosesystems and components any more. In particular,the managers we interviewed confirmed that it isdifficult (if not outright impossible) to integratesystems without mastering the technology under-lying each system in depth. Moreover, the grow-ing importance of the ‘platforms’ within theorganization, together with the need to coordi-nate external suppliers, contributed to congestingmany development projects. In a recent interview(2006), a vehicle line executive told us:

Before [period until 2005], you had to be a‘magician’. Everything was under the controlof the manager responsible for the vehicle. Itwas just impossible to cope with all the aspectsof product development, from technical toeconomic issues.

(Vehicle Line Executive, 2006)

The problem was that platform managers wereresponsible both for the economic and project

management aspects, and at the same time, for allthe technical coordination and responsibility forthe engineering solutions. The latter task includedsystems integration. All this was simply too much.Interestingly, the reason why people at Alpha didnot foresee, and hence, avoid the problem wasthat they were convinced that the involvement ofcompetent suppliers would have eased the needfor technical coordination. In reality, economicand project management aspects are strictly inter-twined with technical coordination issues.

And, in fact, this example shows that theconsequences of extreme outsourcing also af-fected the efficiency and effectiveness of projectmanagement and the organization. The loss ofcontrol of the important pre-development phase(Figure 1) and Alpha’s peculiar interpretation ofco-design14 are both relevant consequences of thechoice to implement a networked innovationstrategy that deserves further attention. We nowturn to analyzing them.

Owing to the lack of manpower in some areas,and of the level of engineers’ competences indesigning particular systems, Alpha chose to in-volve suppliers in the pre-development phase inorder to let them carry out large parts of it. Forexample, suppliers started to assist Alpha also inthe analysis of what component technologies andtechnical solutions could better suit the vehicletargets, including the definition of key perfor-mance attributes. Involving and governing suchsupplier involvement are not trivial, however.Because of the lack of competences, it had pro-blems for instance in setting precise componentspecifications (interview with manager responsi-ble for systems integration, July 14, 2006). More-over, suppliers were given the responsibility for(and the task of organizing and carrying out) in-tegrating sub-systems (defining main component

Figure 1. Pre-development and development phases.




targets and specifications). This process was not‘explicit,’ in the sense that Alpha continued to settargets and specifications. The point, in fact, wasthat the design solutions and systems perfor-mances were not fully under Alpha’s control.This is why, implicitly, suppliers gradually tookover parts of the pre-development phase. More-over, the pre-development phase was not orga-nized in the best way possible, resulting inbottlenecks in the decision process. As the man-ager responsible for system integration observed:

When system integration is carried out in the‘development’ phase, the overall product per-formances are tested at the end of the process:there remains little time for fine tuning and anychange is costly and may result in productquality problems. (Director for Vehicle Con-cept and Integration, 2006)

This is the result of black-box sourcing: suppliers incharge of component concept development (pre-development phase) hand over the component toAlpha when necessary for the physical integrationin the vehicle, i.e. in the late stages of development.

We turned to modules as a means to movefrom a situation in which we had to manage5000 components to a situation in which, oncethe interfaces had been designed, we couldleave everything to 5 system suppliers. Oncethe interfaces were defined, suppliers weresupposed to develop the best systems. In realitythe best was the best for them. We experiencedan increase in costs. In fact, suppliers did notdevelop the best components for what weneeded, but supplied the best available compo-nents. We did not have the lenses to see insidethe module.(Alpha Innovation and Methodol-ogies Manager, 2007)

It is worth noting that the loss of control occur-ring during the pre-development phase is particu-larly important: the pre-development phasedecides on the ‘amount’ and difficulty of trade-offs that necessarily will occur down the line inthe development phase. They are ‘programmed’in the pre-development phase. Not dominatingthat phase but letting suppliers take importantdecisions (with a focus on their sub-systems), andnot focusing attention on this phase sow the seedsfor a whole string of problems in the developmentphase. When solicited on this issue in order togather information on how they decided to copewith the problem, Alpha’s managers reported that

they acted on two levers. Beyond the tendencydescribed above to increase the amount of in-house design, Alpha started differentiating theinvolvement of suppliers in its NPD process inorder to re-gain control of the pre-developmentphase. In particular, Alpha increased the amountof in-house design during the pre-developmentphase, reversing the black-box sourcing strategyas it was carried out before. This also implied achange in the type of skills that Alpha’s engineersare requested to have. In this respect, it is im-portant to report that one of the main concernsexpressed by the manager of human resources ofthe division in charge for products engineeringand design was a particular shortage of staff withskills in virtual simulation technology. Theseskills are key for performing pre-developmentactivities efficiently (with as few prototypes aspossible) and effectively (with reliable knowledgeof the performance the vehicle will have once inproduction). The Chief Technology Officer con-firmed that this shortage was a serious limitationfor organization design; because such staff werefew, it was impossible to establish decentralizedvirtual simulation groups in the various organiza-tion units where virtual simulation was needed.Rather, there was little choice but to have acentral group where all virtual simulation wascarried out complicating the re-focusing on thepre-development phase. The following quotedrawn from an interview with Director of ‘In-novation & Pre-Program Concepts’ in the Engi-neering & Design Division exemplifies this point:

We realized that technical interdependencesmust be tackled at the beginning of the process,not at the end. Before we integrated the vehicleat the end of the process with inevitable andcostly re-design. This was a consequence of theway we outsourced design activities and of thebalance within the firm of design responsibil-ities. At the moment my division carries outthe pre-development for all the vehicles underdevelopment. This has changed our organiza-tion for NPD substantially relieving productplatforms and suppliers of most pre-develop-ment activities.

4. Discussion

Our study was designed to cast light on thequestion why firms that outsource the develop-ment of complex products often experience



problems in implementing this strategy. To an-swer the question, we investigated the conse-quences of design and engineering outsourcingon the firm’s competences and knowledge do-mains, in order to identify the sources of pro-blems with outsourcing design and engineeringtasks in product development. We also analyzedhow the way in which design outsourcing isimplemented in practice (organizational processesand structures) can alleviate or worsen problemsarising from design outsourcing.

Our data, moreover, add new insights into thechoices concerning the balance between architec-tural and component specific knowledge and onhow to maintain and develop the knowledge basenecessary to leverage external sources of innova-tion. These issues seem to be among the mostimportant operational details that require atten-tion in innovation management. At the sametime, they also seem to be the operational detailsthat have the most important strategic conse-quences.

4.1. Incomplete decomposability ofproduct performance and itsconsequences

One of the key insights that emerge clearly fromthe case study is the crucial importance of thedifference between the integration of physicalsystems and the integration of the performanceof such systems (a process known as ‘performancemanagement’). Simply speaking, a car is designedin order to provide a certain performance (hand-ling, fuel consumption, certain crash test para-meters, and so on). This performance is generatedby physical components and systems (such as theoccupant safety system composed of brakes, air-bags, seats, seat belts etc.). The practical problemengineers have to solve is to design a vehicle thatcan systematically generate a certain level ofoverall performance (such as, for instance, 5 starsin the NCAP crash test, handling characteristics,noise, etc). This task is accomplished by designingindividual physical components and systems.What really matters, though, is the performanceof the vehicle as a whole. Importantly, however,performance cannot necessarily be decomposed inthe same way as the components. The reason isthat some performances are generated by morethan one system (Sosa et al., 2003). The occupantsafety system is a good example. Brakes, seatbelts, etc. are important in determining the safetycharacteristics of a car. In a frontal crash, how-

ever, the position, weight, and structure of theengine, and the chassis characteristics, will alsoinfluence the impact absorbed by the vehicle andthe consequences on the driver. Vehicle-levelperformances, thus, are not fully decomposableand different aspects of vehicle-level performancecannot always be attributed completely to parti-cular components and systems. In our example, inorder to design a car so that it has high perfor-mance values regarding occupant safety, it is notsufficient to design just a good occupant safetysystem. From this insight, it now becomes clearthat the automobile is a persistently integralproduct (MacDuffie, 2008). Another limit to thedecomposition of performances is posed by multi-ple performance dimensions (e.g. speed, noise,vibration, harshness, etc.), which are interdepen-dent in the overall vehicle-level performance. Forthese two reasons, there remain reciprocal inter-dependencies between the contribution of theindividual components and systems to the overallperformance (Sosa et al., 2003). As a conse-quence, there are limits to what extent one canfully specify the contribution of an individualcomponent or system to overall vehicle-levelperformances ex ante. Extant research on searchunder complexity (e.g. Levinthal, 1997) showsthat in such situations, finding the combinationwith the global performance optimum is not aminor issue.

The existence of reciprocal technical interde-pendences between components, component spe-cific performances and the overall performance ofthe product thus force managers to considerperformance trade-offs. This is precisely whatwe saw was a major challenge in this case: asthe manager in charge of systems integrationexplained, the key challenge in system integrationtherefore is to manage performance trade-offsbetween the various systems.

4.2. The limits of leveraging modularproduct architecture for achievingcoordination

As seen in the literature review section, modular-ity is a central concept in the scholarly debate onorganizing networked innovation. What is therole of modularity in organizing the developmentof complex products? As described above, fromthe mid-1990s onwards, Alpha attempted to pur-sue a system-integration strategy with the aim ofoutsourcing whole modules. The analysis of thecase clearly shows that modular product design is




not the most appropriate way to deal with theissue of integrating performances – even though itis appealing for physical integration. The reasonis that the benefits attributed to modularity (San-chez, 1997) are not able to address the problem ofintegrating performances. Modular product de-sign is beneficial in solving the task of coordinat-ing suppliers as they independently developcomponents and systems that need to be inte-grated physically (thanks to standardized inter-faces). For this task, modular product design iseffective, as it diminishes the coordinative effortsrequired to coordinate with suppliers. As seen,this is the case when it is possible to both definethe interfaces between elements of the whole exante, and to assign the development of a specificpart to a supplier. Coordination then wouldfollow as a natural consequence. The interfacedefinition, in fact, would embed all the necessaryinformation for the parties as Sanchez and Ma-honey (1996) predicted. However, our case studyshows that for purposes of designing vehicle-levelperformances, it is necessary either to reduce thereciprocal interdependencies between the perfor-mances of the different components and systemsex ante, or to specify them. There are limits to theformer, and in order to do the latter, component-specific knowledge is required. Defining standar-dized physical interfaces does not mean standar-dizing the performance contribution of a module.It does not, therefore, diminish reciprocal inter-dependencies between component- and systems-performances.

This is why firms need to tackle performancetrade-offs. And in tackling performance trade-offs, standardized interfaces simply have no trac-tion. In other words, even if a one-to-one map-ping between performance and component isachieved (see for example Ulrich, 1995), a whitespot remains due to the fact that the coordinationproperties implicit in standard definitions ofmodularity do not apply to the case of perfor-mances that cannot be decomposed in the sameway as the components. Modular product designas an ex ante integration mechanism is not, there-fore, always effective for the integration of per-formances. This is an important addition and limitto the consequences of modular product designthat is not usually mentioned in the influentialliterature on modular product design (e.g. San-chez and Mahoney, 1996; Baldwin and Clark,2000).

Consequently, the upshot is that modular pro-duct architecture does not necessarily lower thecoordination cost among different parties in-

volved in developing complex products (for simi-lar evidence, see Brusoni, 2005). The reason isthat modular product architecture simply cannotdirectly address the dimension that is important,i.e. performance. This becomes clear once perfor-mance, rather than the physical dimension thatgenerates such performance, is the focus of atten-tion. The hopes placed in modular product archi-tecture to ease the involvement of external sourcesof innovation in the development of complexproducts might therefore be largely misplaced.On a final note, one might apply a coordinationcost perspective on the involvement of externalsources of innovation. Such a perspective woulddecide how many of such sources to involve (andwhich ones) based on coordination cost, driven bycoordination challenges. Our argument in thissection is that modular product architecture can-not lower the coordination cost in the context ofperformance integration at all. Moreover, thedrivers of coordination cost in the context ofperformance integration are very different frommodular product architectures, i.e., learning bydoing processes.

4.3. Component-specific knowledge andarchitectural knowledge

Our empirical evidence indicates that for makingperformance trade-offs, a profound knowledgeand understanding of the interaction between thesubsystems (e.g., seat belts, airbags, ABS system,engine, body etc. in a frontal crash) is indispen-sable. This is neither surprising nor new. It is aninsight well established in the literature, both incomplex product systems more generally and inNPD more specifically. Such knowledge is some-times termed ‘architectural knowledge’ (Baldwinand Clark, 2000). Our empirical contribution isto identify the prerequisites for acquiring pro-found knowledge and understanding of the in-teraction between the subsystems. As describedin Section 4, one of the main causes of Alpha’sdifficulties were problems in setting cross-systemfunctional requirements. Problems in settingsuch requirements, in turn, were caused byinsufficient knowledge of the underlying systems.Previous research has argued that knowledge ofthe underlying systems is required to identify theconsequences of different trade-offs and makethe best decision regarding overall product per-formances (Brusoni et al., 2001; Takeishi, 2001).According to this argument, component-specificknowledge is a prerequisite for architectural



knowledge. This is why component-specificknowledge has such an important role for de-signing the performances of complex products.This importance has been recognized also be-yond the specific context of development ofcomplex products. In their work on knowledgerecombination, for instance, Taylor and Greve(2006) reach a conclusion that is fully consistentbut even stronger. One of their conclusions froman analysis of innovation in the comic bookindustry is that combining knowledge requiresa deep understanding of knowledge, rather thanjust information scanning or exposure (Taylorand Greve, 2006: p. 735). Such findings from adifferent context raise additional questions(pointing to matters of great interest for opera-tional implementation). For instance, to whatdegree can shadow engineering, listening posts,and the monitoring of technological advancesfulfil the requirement to ‘keep abreast’ of thedevelopments of component-specific knowledge?Taylor and Greve’s (2006) finding indicates thatunderstanding, not just possessing the informa-tion, is required. The evidence in our case corro-borates this idea. At Alpha, we have seen thatcomponent-specific knowledge fulfils a very pre-cise function in solving performance trade-offs.The evidence showed very clearly that to fulfilthat function, a certain depth of understanding isrequired. Depth of understanding technical spe-cificities (for instance, pertaining to component-specific technology) holds the key to the compe-tence of taking performance trade-offs. Thus, thelevel of knowledge of component technologiesrepresents a limit to design and engineering out-sourcing.

As it turns out, such depth of understandingappears best provided by learning by doing.Several instances in the Alpha case provide sup-port for the idea that actively carrying out designtasks is crucial for maintaining design compe-tences, through learning by doing. This came tothe fore clearly in the case in several instances: forexample, in the pre-development phase, whereAlpha had relinquished its deep involvement inmany technical discussions; in the case of thesafety system supplier, where it became clearthat no party had a real understanding of theperformance attained; and most importantly, inthe loss of capability of taking performance trade-offs. The evidence of the Alpha case thereforesupports the argument that loss of learning bydoing beyond the degree required to maintaincomponent-specific knowledge represents a limitto design and engineering outsourcing.

Our empirical evidence also supports the argu-ment established by previous research that com-ponent-specific knowledge is a complement to thefirm’s architectural knowledge (Takeishi, 2002).At the same time, our evidence adds the insightthat component-specific knowledge is also ameans to strengthen architectural knowledge andprovides the opportunity to maintain it even inthe face of technological change (Brusoni et al.,2001). Our empirical evidence goes beyond pre-vious research by indicating that maintainingcomponent-specific knowledge in important areasin-house can hold the key to the successful in-volvement of external sources of innovation in thedevelopment of complex products. The empiricalevidence supports the idea that it will be difficult,if not impossible, to maintain systems integrationcapabilities – for which performance integrationis key – without mastering the underlying compo-nent-specific knowledge. Interestingly, masteringsuch knowledge is impossible without going intooperational details such as the organization ofcomponent-development tasks. In fact, asemerged from our interviews, the problems withperformance integration that we described did notmanifest themselves right from the start, i.e. whenthe outsourcing strategy was being implementedat the beginning of the 1990s. The reason wassimply that Alpha’s engineers had only justhanded over components and systems engineeringto suppliers. At that point of time, their knowl-edge of underlying systems was still intact, andthey could still easily guide the engineering workof suppliers, also during the pre-developmentphase. Over the next couple of years, however,these competences steadily eroded. By the end ofthe nineties, they had become almost non-exis-tent, at least for some systems.

The arguments for the importance of compo-nent-specific knowledge we referred to above helpto better understand what happened, and theimplications. They therefore help to understandthe sources of limits in design and engineeringoutsourcing.

First, because component design was out-sourced, Alpha’s engineers did not have accessto learning opportunities any more. They were cutoff from learning by doing in component design.Above, we have argued that understanding,rather than just information about componentsand how they work is required, and that learningby doing is a powerful mechanism that can fosterunderstanding (Levitt and March, 1988; Gavettiand Levinthal, 2000). The case supports theidea that learning by doing opportunities are




important for developing understanding. Cuttingengineers off from learning by doing opportu-nities, meant that their understanding of compo-nent specific knowledge started to decay.

Moreover, the case also provides interestingindications on the question to what extent learn-ing by doing opportunities can be substituted.Consider the following: during the pre-develop-ment phase, suppliers (in particular suppliers ofimportant systems) were actually co-located atAlpha’s design and engineering division, provid-ing the occasion for intense communication, forbuilding trustful and personal relations, and fortransferring tacit knowledge and competences. Inthe literature, co-location (Lamming, 1993) is seenas conducive to knowledge transfer and absorp-tive capacity (Cohen and Levinthal, 1990). How-ever, despite such favorable conditions in somesystems, the ability of Alpha’s engineers to dom-inate the pre-development phase eroded. Cuttingoff Alpha’s engineers from both componentsunderlying technology and from learning bydoing negatively impacted their ability to designoverall vehicle performance in the pre-develop-ment phase. The important insight is that lack oflearning by doing can weaken the firm’s absorp-tive capacity, and subsequently, the ability tointegrate external knowledge (in this case pro-vided by the suppliers) into its own productdevelopment process. The absence of learningby doing opportunities therefore has a doublenegative consequence.

The example also provides a powerful indica-tion that learning by doing seems to be verydifficult to substitute. Learning by doing seemsto be particularly able to assure the maintenanceof specific design competences over time. Ourdata show that delegating all component devel-opment work to suppliers weakened the OEM’sability to take design decisions early on in thedevelopment process.

In conclusion, our empirical evidence indicatesthat some component development activitiesshould be carried out in-house. The reason isthat doing seems to be the most important meansfor acquiring and maintaining component-specificknowledge. In turn, such knowledge plays a keyrole for deciding performance trade-offs, whichare crucial for the development of complex pro-ducts. Once again, our empirical evidence pointsto operational details (providing guidance on howto implement in practice), which hold the answersto questions of great strategic importance. Towhat extent, however, component-specific knowl-edge has to be retained in house is a critical issue.

The next section presents the indications on thisquestion that we derived from our field work.

4.4. Implications for firm boundaries

As shown, component-specific knowledge plays acrucial role for being able to make integrationmechanisms work. This insight leads to newquestions, however. If component-specific knowl-edge is crucial and designing and engineering in-house components cannot be easily substituted asa means for acquiring and maintaining the rela-tive knowledge, which component-specific knowl-edge should be maintained in-house (by keepingcomponent development tasks in-house)? Ourempirical evidence provides an answer to thisquestion – a new criterion (beyond that alreadycited in the literature) as to what componentspecific knowledge to retain in house. The analy-sis of our empirical evidence indicates a two-foldcriterion of what type of knowledge firms thatdevelop complex products should retain in house:develop in house all the specific component tech-nologies that (1) have a direct impact on keyproduct performances and (2) present a highdegree of reciprocal interdependences with thekey technologies contributing to the overall pro-duct performances. The first criterion refers to therelevance of the component or subsystem, thesecond indicates when the knowledge concerninghow to design and engineer that component orsubsystem should be retained in house in order toachieve system integration efficiently and effec-tively. OEMs can choose which component tech-nology to invest in according to their assessmenton what the overall performances that mattermost for their customers are.

An example drawn from our observations canclarify this point. In the development of a sportscar, ‘handling’ is usually one of the key perfor-mance dimensions. Our first criterion would leadAlpha to develop and maintain in-house compo-nent-specific knowledge connected to the ‘hand-ling’ of sports cars. It would not be possible, infact, to master a sports car architecture (i.e., tohave the correct architectural knowledge) withouta full command of the components and systemsaffecting the handling performances. However,these performances are determined by numerouscomponents (e.g. tires, suspensions, steering sys-tem, etc.). Having assessed the importance ofhandling for the overall product performanceachievement (first criterion), our second criterionwould suggest that Alpha acquires component-



specific knowledge only for the componentswhose performance present a high degree ofinterdependence with the rest of the product (inthe case of low interdependence, it is possible torely on black box sourcing, it being possible tospecify the interface between the component andthe rest of the product and manage the integra-tion of performances either ex ante, throughstandard (modular) interfaces, or ex post, afterminor adjustments). With reference to handling,in fact, Alpha re-acquired some component-specific knowledge about suspensions and notabout tires.15

In our view, this argument adds another, moregeneral, criterion that goes beyond the criterionindicated by Takeishi (2002). The key criterion fordeciding on which components firms should de-velop component specific knowledge, accordingto Takeishi, is ‘the nature of component develop-ment project in terms of technological newness’(Takeishi, 2002: p. i).16 Our criterion includesTakeishi’s notion but indicates that knowledgepartitioning demands overlaps between Alphaand the supplier not only in the case of technolo-gical newness but also in all the cases in whichknowledge about the component is required formanaging complex technical interdependences. Inthis latter case, as in the case of technologicalnewness, the outcomes of component integrationwithin the product are uncertain and difficult tospecify ex ante. This is not only due to thesupplier’s lack of knowledge, as suggested byTakeishi in the case of technological newnessbut also due to the intrinsic complexity of overallproduct performance integration. We have thusbeen able to indicate, based on the empiricalfindings, an operative criterion for where todraw the boundary of the firm’s knowledge(thus contributing to casting light on the mechan-isms by which product architecture and firmboundaries influence each other, Fixson et al.,2005). This operative detail holds the key tounlocking (or not) important strategic conse-quences.

4.5. The role of organizational decisionson limits of outsourcing

Our empirical evidence points to in-sourcing (orkeeping in house) component-specific knowledgeas the key to the ability to integrate overall vehicleperformances. So what insights and advice do wehave to offer on how firms can organize in order

to successfully maintain component-specificknowledge and learning opportunities?

As seen in Section 3, Alpha was forced to re-organize the NPD activities on the basis of a newcriterion for allocating design responsibilities tosuppliers and a different structure of the internalNPD process. This is why the case provides suchstrong and clear indications for our conceptualframework. Even after re-acquiring componentspecific knowledge, focusing organizational ef-forts on the integration of physical systems andcomponents was not a sufficient condition forintegrating overall systems performance. Thisforced Alpha to thoroughly re-organize its NPDactivities. This re-organization revolved aroundthe distinction between integrating physical sys-tems vs integrating systems performances. Theassumption Alpha started with was the following:in designing performances on the level of theoverall vehicle, trial-and-error and experimenta-tion with the vehicle as a whole is indispensable.17

(Such an assumption makes sense on the basis ofresearch such as Pisano, 1994 and Gavetti andLevinthal, 2000). We can now appreciate whyexperimentation and the use of virtual simulationstarted to play such an important role. Withoutsuch experimentation with the vehicle as a whole,there is no guarantee that reciprocal interdepen-dences between the individual performances ofsystems and components are addressed comple-tely. In such a situation, having a tight hold onthe design of the overall product performance isdifficult (Sosa et al., 2003). This point links backto the incomplete decomposability of overallproduct performance, and the impossibility tofully identify the contribution of each individualcomponent and system to overall performance.Because most of the vehicle performance involvesreciprocal interactions between many compo-nents and systems that are usually developed bydifferent suppliers, rich interaction and ongoingcoordination with suppliers are required. Ourfindings thus support the literature in this respect(Sako, 2003; Takeishi and Fujimoto, 2003).Moreover, because ongoing coordination, richinteraction, and component-specific knowledgeare required, performance integration needs tobe recognized as an important organizational taskin its own right. This in turn involves, for in-stance, a job position responsible for accomplish-ing it, an organizational unit dedicated to systemsintegration, important resources, or at the veryleast making it a dominating criterion in structur-ing the firm. While our findings are consis-tent with recent articles on systems integration




(Brusoni and Prencipe 2006 and the citationstherein), they go beyond the level of detail withwhich the organizational implications are spelledout. A further organizational decision that hasimportant strategic consequences is the point oftime at which integration efforts occur. Thereason is that the negative consequences of aninappropriate and untimely management of thekey performance interdependencies increase asthe design process progresses and more specifica-tions become more concrete. In the later stages ofa project, in fact, design and engineering con-straints grow as the propagation costs of anycomponent and system re-design increase.18 An-ticipating the design and definition of the decom-position scheme into the pre-development phasetherefore enables coordination mechanisms andefforts to intervene at a stage where interdepen-dencies are less strong. Consequently, interdepen-dencies can be dealt with at a point of time whenthey are less strong than later on. The simpleconclusion is that it makes sense to intervene earlyon in the process. The earlier the problem istackled, the lesser the need for late re-design tomatch expected performances (Thomke 1998a, b;Thomke and Fujimoto, 2000). Obviously, this is amatter of interest only in the presence of severetime and cost constraints.

5. Conclusion

This paper has provided a description of thereasons why firms that outsource the developmentof complex products often experience problems inimplementing this strategy. We have identifiedwhat limits Alpha, as a manufacturer of a com-plex product, encountered: the erosion of compo-nent-specific knowledge led to the loss of thecapability to take performance trade-offs regard-ing performance of the product as a whole. Themost important source of the loss of component-specific knowledge was the lack of learning bydoing.

Identifying the most important source of limitsto design and engineering outsourcing enablesderiving insights regarding how to deal with thechallenges raised by design and engineering out-sourcing. The main insights in this regard are two.

First, given the incomplete decomposability ofcomplex products, architectural knowledge andthe related competence of taking performancetrade-offs are achieved if the OEM retains somecomponent specific knowledge in-house. In thisrespect, our finding shows that the reliance on

modular product architectures cannot be a sub-stitute for maintaining in-house componentknowledge development. This result, by itself,shows that there can be intrinsic limitations tothe extent to which firms can pursue design andengineering outsourcing. We thus provide a cri-terion according to which firms can choose whatcomponent specific knowledge should be held inhouse. This insight is of relevance both for theoryand for practice. The case study provides supportfor the importance of learning by doing formaintaining competences, and for the comple-mentary role of component-specific and architec-tural knowledge. Managers cannot assume thatthe firm is able to develop architectural knowl-edge independently from investments in compo-nent-specific knowledge.

Second, we show that even for a given bound-ary of the firm, i.e., when the extent of design andengineering outsourcing is defined, there are stillorganizational decisions (such as the timing ofsupplier involvement, the allocation of engineer-ing resources on different phases of the productdevelopment process, the use of new technologiesin product development, etc.) that have an impacton the effects of outsourcing design and engineer-ing tasks. Management can benefit from a sys-tematic assessment of how and whyorganizational decisions might influence, repre-sent an obstacle or even make it impossible toimplement the strategic choices concerning designand engineering outsourcing. The implication isthat in order to reap the benefits of leveragingexternal sources of innovation in the developmentof complex products, how the outsourcing ofdesign and engineering tasks is organized is es-sential. In practice, as far as the extent to whichthe drawbacks of outsourcing are concerned, itmakes all the difference whether the outsourcingfirm continues to be involved in learning by doingregarding component design or not. These deci-sions can be at least as important – if not far moreimportant – than decisions on product architec-ture and might contribute to restrict the availablestrategic options (i.e., make or buy choices).

These contributions stimulate further researchaiming at a systematic connection and integrationof strategic aspects of innovation managementand its operational aspects. Of course, our find-ings are somewhat specific to the industry weexamined. The most relevant specificities arethat cars are not fully decomposable complexsystems and that, in the automotive sector, thereis a substantial lack of common industry stan-dards or standard architectures for most of the



systems involved in a car (MacDuffie, 2008). Ourinterviews show that in some cases, suppliers haveeven been forced to change the basic design of acomponent just because the testing protocol wasdifferent from that of the OEM for which thecomponent was originally designed: with differenttesting procedures, the component would nothave been approved although it delivered theexpected performances. This makes the issue ofsystem integration more idiosyncratic to eachcompany, and the strategic concern of controllingthe industry architecture via a dominating plat-form (Jacobides et al., 2006) less relevant, at leastfor the time being. As a consequence, our conclu-sions cannot necessarily be applied to contextswhere industry standards play an important rolein both the development of product architecturesand components (e.g. the PC or the telecommu-nication industry). However, our results contri-bute to show that much still remains to beincluded in current theories, particularly in anintegrated theory that covers both strategic andorganizational aspects. It is also highly relevantfor innovation management practice, as glossingover dimensions and factors that matter can haveserious consequences.

References

Arora, A., Fosfuri, A. and Gambardella, A. (2001)Markets for Technology: The Economics of Innova-tion and Corporate Strategy. Cambridge MA: TheMIT Press.

Baldwin, C.Y. and Clark, K.B. (2000) Design Rules:Volume 1. The Power of Modularity. Cambridge,MA: MIT Press.

Becker, M.C. and Zirpoli, F. (2003) Organizing knowl-edge integration and co-ordination in New ProductDevelopment. International Journal of AutomotiveTechnology Management, 3, 1–2, 30–46.

Bensaou, M. (1999) Portfolios of buyer-supplier rela-tionships. Sloan Management Review, 40, 35–44.

Bidault, F., Despres, C. and Butler, C. (1998) Thedrivers of cooperation between buyers and suppliersfor product innovation. Research Policy, 26, 719–732.

Brusoni, S. (2005) The limits to specialization: pro-blem-solving and coordination in modular networks.Organization Studies, 26, 12, 1885–1907.

Brusoni, S. and Prencipe, A. (2001) Unpacking theblack box of modularity: technologies, productsand organizations. Industrial and Corporate Change,10, 1, 179–205.

Brusoni, S. and Prencipe, A. (2006) Making designrules: a multi-domain perspective. OrganizationScience, 17, 2, 179–189.

Brusoni, S., Prencipe, A. and Pavitt, K. (2001) Knowl-edge specialization, organization coupling, and theboundaries of the firm: why do firms know more thanthey make? Administrative Science Quarterly, 46, 4,597–625.

Chesbrough, H. (2003) Open Innovation. New York:Free Press.

Chesbrough, H. and Crowther, A.K. (2006) Beyondhigh tech: early adopters of open innovation in otherindustries. R&D Management, 36, 3, 229–236.

Chesbrough, H. and Kusunoki, K. (2001) The mod-ularity trap: innovation, technology phases shifts andthe resulting limits of virtual organisations. In: Non-aka, I. and Teece, D. (eds), Managing IndustrialKnowledge. London: Sage Press, pp. 202–230.

Chesbrough, H., Vanhaverbeke, W. and West, J. (2006)Open Innovation: Researching a New Paradigm. Ox-ford: Oxford University Press.

Christensen, J.F. (2006) Wither core competency forthe large corporation in an open innovation world?In: Chesbrough, H., Vanhaverbeke, W. and West, J.(eds), Open Innovation: Researching a New Paradigm.Oxford: Oxford University Press, pp. 35–61.

Clark, K.B. (1989) Project scope and project perfor-mance: the effect on parts strategy and supplierinvolvement in product development. ManagementScience, 35, 1247–1263.

Clark, K.B. and Fujimoto, T. (1991) Product Develop-ment Performance. Boston, MA: Harvard BusinessSchool Press.

Cohen, W.M. and Levinthal, D.A. (1990) Absorptivecapacity: a new perspective on learning and innova-tion. Administrative Science Quarterly, 35, 1, 128–152.

Davies, A., Hobday, M. and Prencipe, A. (2005)Systems integration: a core capability of the moderncorporation. Industrial and Corporate Change, 14, 6,1109–1143.

Eisenhardt, K. (1989) Building theories from case studyresearch. Academy of Management Review, 14, 4,532–550.

Eisenhardt, K.M. and Graebner, M.E. (2007) Theorybuilding from cases: opportunities and challenges.Academy of Management Journal, 50, 1, 25–32.

Enrietti, A., Follis, M. and Whitford, J. (2002) Im-proving performance at the second tier of the auto-motive supply chain. Supply Chain Governance andRegional Development in the Global Economy,University of Wisconsin, September 10.

Ernst, D. (2005) Limits to modularity: reflections onrecent developments in chip design. Industry andInnovation, 12, 3, 303–335.

Ethiraj, S.K. and Levinthal, D.A. (2004) Modularityand innovation in complex systems. ManagementScience, 50, 159–173.

Fine, C.H. (1998) Clockspeed: Winning Industry Con-trol in the Age of Temporary Advantage. Reading,MA: Perseus Books.




Fixson, S., Ro, Y. and Liker, J.K. (2005) Modularisa-tion and outsourcing: who drives whom? A study ofgenerational sequences in the US automotive cock-pit industry’. International Journal of AutomotiveTechnology & Management, 5, 2, 166–183. Specialissue on ‘Knowledge and Task Partitioning in theAuto Industry: Coordination, Governance andLearning in New Product Development’.

Freeman, C. (1991) Networks of innovators: a synthesisof research issues. Research Policy, 20, 499–514.

Frigant, V. and Talbot, D. (2005) Technological deter-minism and modularity: lessons from a comparisonbetween aircraft and auto industries in Europe.Industry and Innovation, 12, 3, 337–355.

Gavetti, G. and Levinthal, D. (2000) Looking forwardand looking backward: cognitive and experientialsearch. Administrative Science Quarterly, 45, 1,113–137.

Grandori, A. and Kogut, B. (2002) Dialogue on orga-nization and knowledge. Organization Science, 13,224–231.

Helper, S. (1991) How much has really changed be-tween U.S. automakers and their suppliers? SloanManagement Review, 32, 15–28.

Helper, S.R. and Sako, M. (1995) Supplier relations inJapan and the United States: are they converging?Sloan Management Review, 36, 77–84.

Henderson, R.M. and Clark, K.B. (1990) Architecturalinnovation: the reconfiguration of existing producttechnologies and the failure of established firms.Administrative Science Quarterly, 35, 9–30.

Howells, J., Gagliardi, D. and Malik, K. (2008) Thegrowth and management of R&D outsourcing: evi-dence from UK pharmaceuticals. R&DManagement,38, 2, 205–219.

Iansiti, M. and Levien, R. (2004) The Keystone Advan-tage. Boston: Harvard Business School Press.

Imai, K., Nonaka, I. and Takeuchi, H. (1985) Mana-ging the new product development process: howJapanese learn and unlearn. In: Clark, K.B., Hayes,R.H. and Lorenz, C. (eds), The Uneasy Alliance:Managing the Productivity-Technology Dilemma.Boston: Harvard Business School Press, pp. 337–376.

Jacobides, M., Knudsen, T. and Augier, M. (2006)Benefiting from innovation: value creation, valueappropriation and the role of industry architectures.Research Policy, 35, 8, 1200–1221.

Lamming, R. (1993) Beyond Partnership. London:Prentice Hall Europe.

Langlois, R. (2002) Modularity in technology andorganization. Journal of Economic Behavior andOrganization, 49, 1, 19–38.

Levinthal, D.A. (1997) Adaptation on rugged land-scapes. Management Science, 43, 934–950.

Levitt, B. and March, J. (1988) Organizational learn-ing. Annual Review of Sociology, 14, 319–340.

Lincoln, J.R., Ahmadjian, C.L. and Mason, E. (1998)Organizational learning and purchase-supply rela-

tions in Japan: hitachi, matsushita and toyota com-pared. California Management Review, 40, 241–264.

MacCormack, A.D., Rusnak, J. and Baldwin, C.Y.(2008) Exploring the duality between product andorganizational architectures: a test of the mirroringhypothesis. Scancor/DRUID Conference, StanfordUniversity, Palo Alto, CA, March 27–28.

MacDuffie, J.P. (2008) Technological and Organiza-tional Barriers to Modularity: Persistent Integralityin the Global Automotive Industry. Wharton: Mimeo.

Mahnke, V. (2001) The process of vertical dis-integra-tion: an evolutionary perspective on outsourcing.Journal of Management and Governance, 5, 353–379.

Maxton, G. and Wormald, J. (2004) Time for a ModelChange: Re-Engineering the Global Automotive In-dustry. Cambridge: Cambridge University Press.

Mikkola, J. (2003) Modularity, component outsour-cing, and inter-firm learning. R&D Management, 33,4, 439–454.

Mikkola, J. (2006) Capturing the degree of modularityembedded in product architectures. Journal of Pro-duct Innovation Management, 23, 2, 128–146.

Miles, M.B. and Huberman, A.M. (1994) QualitativeData Analysis: An Expanded Sourcebook. ThousandOaks, CA: Sage Publications.

Miozzo, M. and Grimshaw, D. (2005) Modularity andinnovation in knowledge-intensive business services:IT outsourcing in Germany and the UK. ResearchPolicy, 34, 9, 1419–1439.

Nishiguchi, T. (1994) Strategic Industrial Sourcing.New York: Oxford University Press.

Pettigrew, A.M. (1990) Longitudinal field research onchange: theory and practice. Organization Science, 1,3, 267–292.

Pisano, G.P. (1994) Knowledge, integration, and thelocus of learning: an empirical analysis of processdevelopment. Strategic Management Journal, 15, 85–100.

Pisano, G.P. and Teece, D.J. (2007) How to capturevalue from innovation: shaping intellectual propertyand industry architecture. California ManagementReview, 50, 1, 278–296.

Powell, W.W., Koput, K.W. and Smith-Doerr, L.(1996) Interorganizational collaboration and thelocus of innovation: networks of learning in biotech-nology. Administrative Science Quarterly, 41, 116–145.

Puranam, P. and Jacobides, M.G. (2006) The Dynamicsof Coordination Regimes: Implications for Organiza-tional Design, Mimeo, London Business School.

Sako, M. (2003) Modularity and outsourcing. Thenature of co-evolution of product architecture inthe global automotive industry. In: Prencipe, A.,Davies, A. and Hobday, M. (eds), The Business ofSystems Integration. Oxford: Oxford UniversityPress, pp. 229–253.

Sako, M. (2004) Supplier development at Honda,Nissan and Toyota: comparative case studies of



organizational capability enhancement. Industrialand Corporate Change, 13, 2, 281–308.

Sanchez, R. (1997) Modular architectures in the mar-keting process. Journal of Marketing, 63, 92–111.

Sanchez, R. and Mahoney, J.T. (1996) Modularity,flexibility, and knowledge management in productand organization design. Strategic ManagementJournal, 17, 63–76.

Siggelkow, N. (2007) Persuasion with case studies.Academy of Management Journal, 50, 1, 20–24.

Siggelkow, N. and Levinthal, D.A. (2003) Temporarilydivide to conquer: centralized, decentralized, andreintegrated organizational approaches to explora-tion and adaptation. Organization Science, 14, 650–669.

Smitka, M.J. (1991) Competitive Ties. New York:Columbia University Press.

Sosa, M.E., Eppinger S.D. and Rowles, C.M. (2003)Identifying modular and integrative systems andtheir impact on design team interactions. Journal ofMechanical Design, 125, 2, 240–252.

Staudenmeyer, N., Tripsas, M. and Tucci, C. (2005)Interfirm modularity and its implications for productdevelopment. Journal of Product Innovation Manage-ment, 22, 4, 303–321.

Sturgeon, T.J. (2002) Modular production networks: anew American model of industrial organization.Industrial and Corporate Change, 11, 3, 451–496.

Takeishi, A. (2001) Bridging inter- and intra-firmboundaries: management of supplier involvement inautomobile product development. Strategic Manage-ment Journal, 22, 403–433.

Takeishi, A. (2002) Knowledge partitioning in theinter-firm division of labor: the case of automotiveproduct development. Organization Science, 13, 321–338.

Takeishi, A. and Fujimoto, T. (2003) Modularizationin the car industry: interlinked multiple hierarchies ofproduct, production, and supplier systems. In: Pre-ncipe, A., Davies, A. and Hobday, M. (eds), TheBusiness of Systems Integration. Oxford: OxfordUniversity Press, pp. 254–278.

Taylor, A. and Greve, H.R. (2006) Superman or thefantastic four? Knowledge combination and experi-ence in innovative teams. Academy of ManagementJournal, 49, 723–740.

Teece, D.G. (1986) Profiting from technological inno-vation: implications for integration, collaboration,licensing and public policy. Research Policy, 15, 285–395.

Thomke, S.H. (1998a) Simulation, learning and R&Dperformance: evidence from automotive develop-ment. Research Policy, 27, 55–74.

Thomke, S.H. (1998b) Managing experimentation inthe design of new products. Management Science, 44,6, 743–762.

Thomke, S.H. and Fujimoto, T. (2000) The effect of‘front-loading’ problem-solving on product develop-

ment performance. Journal of Product InnovationManagement, 17, 128–142.

Ulrich, K. (1995) The role of product architecture inthe manufacturing firm. Research Policy, 24, 419–440.

Wheelwright, S. and Clark, K. (1992) RevolutionizingProduct Development. New York: Free Press.

Womack, J.P., Jones, D.T. and Ross, D. (1990) TheMachine that Changed the World, Rawson Ass, NewYork.

Yin, R.K. (1994) Case Study Research: Design andMethods. Thousand Oaks/CA: Sage.

Notes

1. Research funding by the Italian Ministry of HigherEducation and Research (MIUR) under the PRIN2004 program (project 2004135057_004) and by theAgence Nationale de Recherche (ANR), France(‘Jeunes Chercheuses et Jeunes Chercheurs’ pro-gram, grant no. JC05_44029) is gratefully acknowl-edged. For purposes of formal assignment,Sections 1, 4, and 5 were written jointly, FrancescoZirpoli wrote Section 2.1 – case selection, 2.3 – dataanalysis and Section 3.2, and Markus Becker wroteSection 2.2 – data collection and Section 3.1.

2. For a comprehensive review of the advantages ofinvolving suppliers in the NPD process, see Bidaultet al. (1998).

3. Chesbrough (2003) has synthesized and popular-ized the superiority of business models that hingeon the contribution of external sources of innova-tion (‘open innovation’). Innovating firms are ad-vised to invest in their capabilities of drawing onexternal sources of innovation. In the same vein,Iansiti and Levien (2004) observe that the sustain-ability of a firm’s profitability is linked to thesuccess of the ecosystem it belongs to. Firms thusshould attempt to achieve an important (‘key-stone’) position within the ecosystem. Iansiti andLevien (2004) concur with Chesbrough (2003) thatfirms should adapt their business models in orderto make use of external resources and competences.Expanding the seminal contribution of Teece(1986), Pisano and Teece (2007) add to the litera-ture on strategic aspects of innovation managementby pointing to the importance of value appropria-tion conditions as a guide for a profitable networkinnovation strategy.

4. In this article, we follow Baldwin and Clark’s(2000) definition.

5. As Davies, Hobday and Prencipe write, systemsintegrators are firms that ‘bring together high-technology components, subsystems, software,skills, knowledge, engineers, managers, and techni-cians to produce a product in competition withother suppliers’ (2005, p. 1,110). This requires‘design[ing] and integrat[ing] systems, while mana-




ging networks of component and subsystem sup-pliers’ (Davies et al., 2005, p. 1,109).

6. Sanchez and Mahoney’s (1996) idea that organiza-tion structure follows product architecture has alsobeen criticized as deterministic. Sako (2003: p. 230)argued that there is ‘no simple deterministic linkbetween the type of product architecture andorganization architecture.’ Puranam and Jacobides(2006), in the same vein, have criticized the ‘carry-over of ideas’ on technological architecture (includ-ing interfaces) to organizational architecture.

7. OEM stands for Original Equipment Manufac-turers. Examples of OEM companies in the auto-motive industry, the focus of the empirical workpresented in this paper, include firm such as Gen-eral Motors, Ford, and Toyota. In some industries,such as electronics, OEMs build products or com-ponents used in products sold by another company(often called a value-added reseller, or VAR). Inother industries, they are identified as OriginalDesign Manufacturer. Here, we refer to the OEMas the leader of its value chain, i.e. as the finalsystem integrator.

8. The case, therefore, offers at least as much insightinto industry evolution as the electronics industry –the paradigmatic example of an industry wherechanges are observable in a relatively short timespan (Fine, 1998). This point is a matter of interestin itself and makes the case intriguing for analyzingindustrial and organizational change. For thisreason, we believe our sampling choice seizes, asgood single-case research does, the ‘opportunitiesto explore a significant phenomenon under rare orextreme circumstances’ (Eisenhardt and Graebner,2007, p. 27).

9. One of the authors has been carrying out researchon Alpha and its suppliers since 1997. The inter-views and data-gathering activities carried outbetween 1997 and 2006, hence, provided a solidstarting point for a more fine-grained and in-depthanalysis in the empirical work we present in thispaper. Moreover, this background allowed us totrace back the evolution of the OEM’s strategy,organization, and competences for product devel-opment according to the evolution of its designoutsourcing strategy.

10. The intrinsic limitations of case study researchmore generally do, of course, also apply (seeMiles and Huberman, 1994, for a comprehensivediscussion.)

11. Especially between 1990 and 1992, the OEM ex-perimented with so-called driven growth pro-grammes. Suppliers, which demonstrated thepotential, in terms of quality and cost of theirproducts, to comply with the new OEM standard,were provided with continuous managerial supportfrom the OEM together with tailored contractualagreements, such as long-term contracts and steadyincrease of volumes purchased. In exchange, these

suppliers had to respect an improvement schedule(Enrietti et al., 2002).

12. Thai is, exogenous to the automotive industry.13. Most often, the purpose of knowledge sharing was

knowledge acquisition on the part of the OEM.14. Co-design was interpreted as ‘black box’ sourcing

(Lamming, 1993) and not as a form of jointdevelopment. In the development of a new vehicle,two major phases can be distinguished: (1) thepre-development phase: the vehicle is ‘set up,’including the definition of component and systemcharacteristics (design architypes and expectedperformances), and (2) the development phase:the design and engineering of the vehicle is spe-cified in detail. Between the two phases lies thefreeze of the design, and the go-ahead for thefull set of investments required in order to indus-trialize the vehicle with those particular designparameters.

15. Please note that for sports cars, tires are not acompletely standard option as could be intuitivelythought. An extreme case is the need for tightintegration between the tires and the rest of thevehicle in Formula 1, an example of how importantthe component-specific knowledge on tires couldbe.

16. For regular projects, it is more important forautomakers to have a higher level of architecturalknowledge (how to coordinate various componentsfor a vehicle) than of component-specific knowl-edge, which is supposed to be provided by suppli-ers. However, when the project involves newtechnology for the supplier, it is important for theautomaker to have a higher level of component-specific knowledge to solve unexplored engineeringproblems together with the supplier. In innovativeprojects, effective knowledge partitioning seems todemand some overlaps between an automaker anda supplier, rather than efficient and clear-cutboundaries (Takeishi, 2002: p. i).

17. In order to see why, take the example of anautomobile and try to put together suspensions,chassis, engines, etc. and drive the car. The carwould work, but the handling would requirefurther rounds of trial and error and integrationactivities to reach the handling that is desired(handling can be defined as the dynamic beha-vior of a vehicle on the road and the relateddriving experience this behavior generates for thecustomer).

18. Propagation cost identifies the percentage of sys-tem elements that can be affected, on average,when a change is made to a randomly chosenelement (MacCormack et al., 2008:p. 12). Ourdata confirm that the cost in terms of design andengineering hours (and eventual delay on theproject schedule) that would follow the change ina component or system are by far higher in the latestages of a project.



Francesco Zirpoli is an Associate Professor ofManagement at the Department of Business Eco-nomics and Management at Universita Ca’ Fos-cari Venezia and a Research Associate at theInternational Motor Vehicle Program. He re-ceived his PhD in management from CambridgeUniversity and from Universita Federico II diNapoli. His research focuses on the strategicorganization of innovation, make or buy strate-gies, and supply chain management with a specificfocus on the NPD process. His works haveappeared in Research Policy, Journal of Eco-nomic Behavior and Organization, EuropeanManagement Review, International Journal ofTechnology Management, International Journalof Operations and Production Management,Journal of Analytical and Institutional Econom-

ics, and International Journal of Automotive andTechnology Management.

Markus C. Becker is a Professor at the StrategicOrganization Design Unit, University of South-ern Denmark, Odense. He received his PhD inManagement from Cambridge University. Hisworks have appeared in Cambridge Journal ofEconomics, Industrial and Corporate Change,International Journal of Automotive and Tech-nology Management, International Journal ofOperations and Production Management, Jour-nal of Business Research, Journal of EconomicBehavior and Organizations, Journal of Manage-ment Studies, Research Policy, and others. Hiscurrent research focuses on strategic organizationof innovation and organizational routines.




the limits of design and engineering outsourcing ... · the limits of design and engineering...

Documents