Linking modularity with problem solving and coordination efforts

MANAGERIAL AND DECISION ECONOMICS

Manage. Decis. Econ. 29: 443–457 (2008)

Published online 29 February 2008 in Wiley InterScience

(www.interscience.wiley.com) DOI: 10.1002/mde.1402

Linking Modularity with Problem Solvingand Coordination Efforts

Paulo J. Gomesa,* and Nitin R. Joglekarb

aFaculdade de Economia, Universidade Nova de Lisboa, Lisboa, PortugalbBoston University School of Management, Boston, MA, USA

We explore the relationship between process architecture decisions, problem solving and

coordination efforts during distributed product development, i.e., when development work isdispersed across organizational boundaries. Process architecture refers to the manner in which

the tasks and interfaces within a project are organized so that a project can be executed in an

efficient manner. The theoretical foundation for our investigation draws upon the information

processing (IP) view of product development and transaction cost economics. The IP view callsfor manipulation of the architecture by making problem-solving tasks modular, such that

reducing task interdependencies minimizes the development time. The transaction cost view

calls for transactional efficiency, for example, reduction in the coordination burden for each

productive task. We present several measures of modularity based on a design structurematrix (DSM) mapping of the development task structure. Then, we analyze the relation

between these measures and transactional efficacy and task completion times. Our empirical

evidence comes from 71 tasks carried out in 11 software development projects. Data analysesshow that the improvement in the transactional efficacy is associated with increase in task

modularity. Our results establish that increasing modularity reduces the development time and

the coordination effort. However, these results also suggest trade-offs: modularity measures

do not contribute equally to this gain in efficiency and increasing modularity isnegatively associated with the technical problem-solving efforts. Copyright # 2008 John

Wiley & Sons, Ltd.

INTRODUCTION

In several industrial settings, ranging from com-puter hardware and software development (Bald-win and Clark, 2000) to automotive development(Clark and Fujimoto, 1991; Takeishi, 2002),product development effort is no longer concen-trated in the focal development firm. We refer tothis phenomenon as distributed product develop-ment. Many streams of research have explored theorganizational issues underlying product develop-ment practices (see for example, review articles by

Brown and Eisenhardt, 1995; Krishnan andUlrich, 2001). Within this context, the twodominant theories for explaining product devel-opment decisions are the information processing(IP) view and transaction cost economics (TCE).

The IP view calls for a process architecture thatminimizes the development time. The term archi-tecture refers to manner in which the tasks within aproject are organized: decomposed, sequenced andintegrated (von Hippel, 1990). Modularity is ameasure of task interdependence for a givenarchitecture. That is, increasing modularitythrough architectural choices represents decreas-ing interdependence between tasks (Baldwin andClark, 2000). Increasing modularity is the

*Correspondence to: Faculdade de Economia, UniversidadeNova de Lisboa, Lisboa, Portugal. E-mail: [email protected]

Copyright # 2008 John Wiley & Sons, Ltd.

conventional prescription for gaining IP efficiency(Baldwin and Clark, 2000). On the other hand, theTCE theory calls for examination of governancechoices for improving production efforts, whilereducing the allied coordination burden, in theface of uncertainty. In the product developmentsetting, production effort is focused on technicalproblem solving. Hence, the terms problem-solving effort and production are used inter-changeably throughout this paper.

Recognizing the interplay of governance modesand process architecture decisions is critical forbetter management of development processes. Thepurpose of this paper is to compare and contrastIP and TCE, the two dominant views on resolutionof uncertainty in the context of distributed productdevelopment. There are several opportunities tointegrate these views on uncertainty resolution.We focus on modularity, task completion timesand transactional efficiency (improving problemsolving while reducing allied coordination efforts),the central set of constructs within these two viewsand address the following research question: ‘Howdoes task modularity affect transactional efficiencyand completion times during distributed productdevelopment projects?’

Our work defines and measures task modularitybased on the design structure matrix (DSM)methodology (Steward, 1981), a mapping of taskinterdependences used extensively in the engineer-ing design literature. We focus on the choice ofprocess architecture and the resulting map of taskinterdependence. Multiple measures of modularitycan be established for a given design structuremap. We explore the extent to which each of thesemeasures relates to observed production andcoordination efforts, and completion times.

Our empirical evidence comes from 71 taskscarried out in 11 software development projects.Many of these tasks are either fully or partiallyoutsourced. Completion of these tasks involvesboth internal and external coordination reflectinginformation dependencies within the boundary andacross the boundary of the firm, respectively. Weassess modularity using alternate measures: de-pendence, visibility and a combination of both.Our results show that an increase in taskmodularity is associated with transactional effica-cies, in terms of reduced coordination effort andshorter completion time, ceteris paribus. Visibilityis the measure that provides the largest explana-tion for variation in the transaction efficacy.

Moreover, the elasticity of external coordinationeffort, problem-solving effort and the completiontime varies with respect to the modularity con-struct. Implications of our findings relate to thedegrees of freedom available for design of tasksand selection of interfaces among these tasks. Ourresults establish a managerially relevant pattern}increasing modularity reduces the developmenttime and the coordination effort. These results alsosuggest some trade-offs}modularity measures donot contribute equally to this gain in efficiency.

Engineers and managers work on architectingtheir tasks into modular entities ex ante, so thatthe completion time and the coordination burdenobserved ex post, i.e., after completion of thesequence of development tasks, are minimized.The contributions of this paper lie in establishingmodularity measures from multiple theoreticalperspectives and in documenting the associationbetween the ex ante choice (modularity), and theex post performance (production and coordinationefforts and completion time).

The rest of paper is organized as follows. In thenext section, we review various models of theproduct development processes based on twotheoretical perspectives, IP and TCE. In the thirdsection, we analyze the organizational choicesregarding task execution and resulting coordina-tion structure in light of modular decompositionof projects and develop our linkage hypotheses.Fourth section describes the data collectionprocedure and the resulting sample featuring 71development tasks from 11 software developmentprojects. In the fifth section, data analysis andregression results are presented. Managerial andresearch implications for our results are discussedin the sixth section before offering concludingremarks.

TWO THEORIES FOR EXPLAINING

PRODUCT DEVELOPMENT DECISIONS

We begin by reviewing the IP view and introducethe idea of product development modularity usingthe DSM methodology in the section ‘InformationProcessing View of Product Development’. Wedescribe the transaction cost view as it pertains toproduct development processes in the section‘Transaction Cost Perspective on the ProductDevelopment Process’. We then summarize the

P. J. GOMES AND N. R. JOGLEKAR444

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

similarities and differences between these views inthe section ‘A Comparative View’ and argue thatthe gaps between these two views ought to bereconciled.

Information Processing View of Product

Development

The central idea of the IP view was postulated byNewell and Simon (1963): given a set S, to find anumber of sub-set of S having specified propertiescalled the goal set G. Within the product develop-ment context, S represents a set of tasks attributesand the goal G is typically taken to be theminimization of development time. Two coreissues underlie the IP view of the productdevelopment process. Firstly, the recognition thatdevelopment tasks are fraught with uncertainty.Completion of tasks requires significant amountsof information, ranging from market feedback totechnical know-how (Souder and Moenaert, 1992;Moenaert et al., 1995; Tatikonda and Rosenthal,2000). This information is not available ex ante(Galbraith, 1973), resolving uncertainties requiresgathering, transferring and integrating informa-tion (Allen, 1977; Schrader et al., 1993). Thisresearch stream has produced several models ofthe development processes that emphasize organi-zation of work based on efficient internal andexternal communication, and problem-solvingstrategies (Tushman and Adler, 1980; Brown andEisenhardt, 1995).

Secondly, development tasks are characterizedby some degree of interdependence. A central ideaunderlying information-based models is that com-plex systems can be decomposed into sub-systemsor modules or tasks (Simon, 1969) in a way thateach module becomes a black box, hiding designdetails from other modules. The outputs of sometasks are inputs to other tasks, and iterations mayoccur due to recursive dependence on task out-puts. This literature distinguishes between visibleinformation, that modular systems allow to inter-act outside a module, and hidden information thatshould remain within the module development(Baldwin and Clark, 2000). Good modular systemsdecouple visible and hidden information to avoidlong iterative cycles (Yassine et al., 2003). Still,interdependence creates requirements for informa-tion sharing and transfers, and managers need tounderstand how uncertainty arises from the timing

of information release, and the associated degreeof information completion.

Other analytical models focus on how develop-ment work should be organized given the expectedimpact of task interdependency. These modelsassume the nature of interdependence, and em-phasize the reduction of development time throughconcurrency, i.e., overlapping of product develop-ment tasks while relying on information releasesand iterations (Alexander, 1964; Krishnan et al.,1997; Loch and Terwiesch, 1998; Terwiesch et al.,2002). The level of uncertainty faced by down-stream tasks, the cost and duration of iterations(Krishnan et al., 1997; Terwiesch et al., 2002), thespeed and timing of uncertainty resolution (Krish-nan et al., 1997; Terwiesch and Loch, 1999)influence the optimal degree of concurrency.

The dependence structure affects the optimalfrequency, amount and type of upstream anddownstream technical communication (Loch andTerwiesch, 1998). Alternative coordination andcommunication strategies have been suggested inthe literature to take advantage of the IP needs ofa development process (Morelli et al., 1995; Sosaet al., 2002). In sum, analytical models suggest thatthe level of task interdependence and the IPcharacteristics of tasks determine the optimalcoordination strategy.

Design structure matrix. The DSM is a mappingmethodology that captures information dependen-cies between development tasks through the use ofa square matrix where each cell captures thedependency between two tasks (Steward, 1981).The DSM has been used extensively to analyzeconcurrency strategies in complex product systemswith high interdependence (McCord and Eppin-ger, 1993; Smith and Eppinger, 1997, 1998;Browning and Eppinger, 2002). In Figure 1, weshow a DSM for the design of a laptop computer.Each row, and respective column, corresponds to aspecific development task.

The information exchange between any two cells(marked with x on the left-hand side of the figure)is implicit. For clarification, we show the informa-tion exchange details associated with a pair ofcells on the right-hand side of the figure. Arrowsbetween two specific cells (a,b) in the designmatrix means that task b depends on informationreleased by task a. If task a, precedes task b, thesituation would represent a feed-forward depen-dency, otherwise it would represent a feedback

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 445

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

dependency. In the example, the computer hasbeen decomposed into four major sub-systems,with highly intricate development tasks inside thesub-system, and fewer dependencies between sub-systems. The diagonal cells represent the produc-tion, or technical problem-solving effort, while theoff-diagonal marks represent requirement forcoordination between tasks.

The DSM provides a mapping of productarchitecture, or the underlying development pro-cess architecture (see Browning, 2001, for a reviewof use of DSM in product and task representa-tion). The DSM mapping of task interdependencesshows the information flows that result fromarchitectural choices, which we may characterizeas unidirectional or bi-directional informationflows, and feed-forward or feedback informationflows depending on the task sequence.

Sharman et al. (2002) define two constructs thatfurther characterize interdependence, i.e., modu-larity, based on the DSM representation ofinformation flows. Visibility represents the impactof the rule set determined by a task on theremaining tasks; it represents information genera-ted at the task level flowing to both downstreamand upstream tasks. Dependence refers to thebounding rule set to which a task is subject; itrepresents information inputs from upstream ordownstream tasks that a specific task needs toprocess. It is possible to define feedback depen-dence based on dependence arising from down-stream tasks. In the fourth section, we describe theuse the DSM methodology for collection ofinformation on task interdependences and then

deploy these data to develop measures of taskmodularity.

Transaction Cost Perspective on the Product

Development Process

TCE is a theory that seeks to explain why firmschoose to ‘make rather than buy’ requiredproduction inputs based on key predictors of thedifferential between the transaction costs asso-ciated with each alternative (Coase, 1937; William-son, 1985). Transaction costs include the ex antecosts of negotiating a contract and the ex postcosts of monitoring the performance and enforcingthe behavior of the parties, while the keypredictors include the uncertainty surroundingthe transaction, the requirement to make idiosyn-cratic investments and the frequency of transac-tion between the parties (Williamson, 1985).

Uncertainty has a central role among theconditions that influence the governance structurefor a transaction. Uncertainty not only creates aninability to write an a priori comprehensivecontract but also increases the costs of adaptingcontractual arrangements. Fear of opportunisticbehavior, i.e., agents seeking ‘self-interest withguile’ (Williamson, 1985), leads agents to protectagainst uncertainty. In the TCE literature,uncertainty is usually decomposed into environ-mental uncertainty, which arises from unpredict-ability (for example, uncertainty associated withmarket or technology that affects the inputs tothe development process), and performanceuncertainty, which arises from the difficulty in

. x x x x xx . xxxxxxxxxx x . xxxx x x . x x x x x x xx x . x

x x x . x x xx x x . x x

x x x . xxxxx x x . x x x x x

x x x . x x xx x x x x x

x. x x x x x

x x x x . xxx x x x x x . x x x

x x x . xx x x . x x x

x x x x . x x x xx x x . x xx x x x . x x x

x x x x x x x . x x xx x x . x

x x x x . x x x xxxx . x x x x

x x x x x . x x xxxxx . x xxxxxx . x x

x x x x . x xx x x x x .

x x x x x .

Packaging

Drive System

MainBoard

LCDScreen

a

bFeedforward

UpstreamTask

Feedback

DownstreamTask

x

x

x

Figure 1. A design structure matrix for tasks of a computer development project

(adapted from Baldwin and Clark, 2000).

P. J. GOMES AND N. R. JOGLEKAR446

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

monitoring the behavior or exchange partners(Williamson, 1985). Alchian and Demsetz (1972)have articulated the relevance of considerationsregarding the monitoring the behavior and in-dividual outputs in team production to the choiceof governance mode.

Applying TCE theory to explain the organiza-tion of product development is a recent line ofexploration (Argyres, 1996; Ulrich and Ellison,2005). A few studies have attempted to link TCEwith the IP perspective. Azoulay (2003) studiessourcing decisions for clinical trials in the drugdevelopment process as a function of task infor-mation requirements. He finds that knowledge-intensive projects are more likely to be assigned tointernal teams, as incentives for knowledge anddata production can be better kept in balanceinternally. Novak and Eppinger (2001) show thatdesign complexity, based on component interfacesdictated by product architecture, has a significanteffect on the decision to outsource productcomponents. Novak and Stern (2003) show thattechnological complementarities between compo-nents impact sourcing decisions for those compo-nents, placing the emphasis on product componentinterdependences.

Baldwin and Clark (2002) provide an engineer-ing design-based perspective on the sourceof transaction costs, emphasizing the role ofdevelopers in designing system architecturesthat reduce transaction costs. They argue that

not all the necessary transfers that occur ina production system can be transactions requiringstandardizing, counting and compensating forwhat is being transferred. System decompositionshould occur where the transaction costsof creating interdependence are at a minimum.As a result, common information needed on bothsides of the transaction is minimized and thedivision of labor is carried out in a cognitivelyefficient manner.

In sum, empirical studies have shown therelevance of architecture and interdependence tothe choice of governance mode for design andproduction of components. Managers should de-sign the product development process to reducetransaction costs (Baldwin and Clark, 2002), whileallowing for a division of labor that takes fulladvantage of specialization.

A Comparative View

Table 1 presents a summary of key issuesassociated with product development from theTCE and IP perspectives. We separate keyissues into those pertaining to production andthose pertaining to coordination. In terms ofprocess modeling objectives, the emphasis ofTCE studies is on the managing costs (productionand coordination), while the emphasis of engineer-ing design studies is on development time andproduction efficiency.

Table 1. Two Views on Product Development Process

Task type Transaction cost economics Information processing

Objectives ObjectivesProduction, i.e., technicalproblem solving

Minimization of managing costs Production efficiency and minimization ofdevelopment time

Key predictors Key predictorsScale and governance Architectural modularity (Baldwin and Clark,Asset specificity (product complexity) 2000; Browning and Eppinger, 2002)Environmental uncertainty(Williamson, 1985)

Concurrence (Krishnan et al., 1997)

Coordination Objectives ObjectivesEconomize on transaction costs Minimization of rework

Key predictors Key predictorsEnvironment uncertaintyPerformance uncertainty (Alchian andDemsetz, 1972)

Asset specificity (product complexity)

Planned information exchanges (Krishnan et al.,1997)

Frequency of communication (Krishnanet al., 1997; Loch and Terwiesch, 1998)

(Williamson, 1985) Type of communication (Sosa et al., 2002)

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 447

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

Analytical models of the developmentprocess based on the IP perspective predict thatarchitecture choices have a significant impact ondevelopment cost and project completiontime (Browning and Eppinger, 2002). However,a majority of these models have focused oninternal development contexts, a recurrent issuein the product development literature (Gerwinand Barrowman, 2002). Studies of inter-organiza-tional development do not provide enoughdetail on coordination strategies to enablean understanding of how process architecturechoices and costs of managing the developmentprocess are associated. One exception is the studyof Sosa et al. (2004), who found that teaminteractions were less coupled with designinterdependences across organizational bound-aries than within organizational boundaries.The authors justify the mismatch between designinterfaces and development team interactionsbased on the reduced awareness about depen-dences across organizational boundaries. Theyalso find that these hindering effects of organiza-tional boundaries are compounded in thecase of modular systems. They have not exploredwhether the coordination of development tasksacross organizational boundaries challenged thecoupling of design interfaces and technical com-munication.

Key performance measures for TCE-basedstudies arise from traditional constructs such asasset specificity and uncertainty. Recent studiestend to incorporate engineering dimensions,such as complexity and technology interdependen-cies as proxies for asset specificity. The TCEperspective is that interdependence per se shouldnot translate into higher costs of coordination if

the pattern of interdependence is stable and fixed(Williamson, 2000). The role of task uncertaintyassociated with process architecture choices hasnot been explored.

We end this discussion by pointing out thatthese two views differ not only in their choice ofobjective function and key predictors but also inthe time scales for the managerial decision making.For instance, modularity decisions are made byengineers and managers while architecting theirtasks ex ante, so that the completion times and thecoordination burden observed ex post, i.e., aftercompletion of the sequence of development tasks,are minimized. In the next section, we explore thelinkages between these key constructs.

AN INTEGRATED PERSPECTIVE

The mapping of information dependencies to-gether with the task ownership decision provides abasis for understanding the coordination require-ments of distributed development projects. Thetask ownership decision consists in the choice of agovernance structure for task execution. Thetask execution can be assigned to the develop-ment group, other development or functionalgroups within the firm, or to external suppliers.In Figure 2, we present a stylized DSM thatcombines information on task interdependenceand task ownership.

The execution of a development task hasassociated two types of effort: technical problemsolving and coordination effort, i.e., themanagement of dependences to ensure unity ofeffort among the participants in the development

a b c d e f

a T P Q R P Coordination within group

b P T R Q Coordination across groups (within firm)

c Q U R Coordination across firms

d U T Technical Work Within Group

e R R R V U

f R V

V Technical Work Within Group for Work Owned Outside Firm

Technical Work Within Group for Work Owned Within Firm (not Within Group)

WithinGroup

Tas

ks

Name

OutsideFirm

Task OwnershipWithinFirm

Figure 2. Stylized DSM for distributed development projects.

P. J. GOMES AND N. R. JOGLEKAR448

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

project. The technical problem-solving effortrequired for each task, which we designate asproduction effort, is represented in the diagonalelements of the DSM. Given a defined taskaggregation, there may be the need to performsome technical work within the developmentgroup even for tasks that are outsourced. Forexample, a task such as specification of softwaresystem requirements can be contracted to anexternal supplier, but a sub-set of this task suchas defining security principles and communicationprotocols may still be defined internally.

The non-diagonal elements represent coordina-tion effort associated with task execution.Three types of coordination will result fromtask ownership decisions: coordination withingroup, such as planning the internal work execu-tion; coordination within firm but across develop-ment groups, such as negotiating agreementon standards; and coordination across firmssuch as resolving conflicts or managing iterationsbetween external partners and internal teammembers. While selecting a particular interface,managers have the choice to either place coordina-tion between development tasks within a produc-tion unit, increasing modularity, or allowcoordination to occur across task boundaries,decreasing modularity. The TCE prediction isthat coordination across boundaries is morecostly to the organization than coordinationwithin boundaries. The conceptual frame-work for linking these constructs is presented inFigure 3.

We define task outcomes. based on the proposedobjectives listed in Table 1, economizing ontransaction costs, production efficiency and mini-mization of development time. Task modularity isconceptualized as an architectural decision thatdefines how project endogenous uncertainty getsresolved. Task ownership decisions impact thedistribution of coordination effort among internalversus external interfaces. The ownership decisionmay moderate the impact of architectural choiceson coordination.

A greater level of task modularity should resultin a lower level of endogenous uncertainty. TheTCE theory conceptualizes uncertainty as a keydriver of transaction costs. In the product devel-opment process, these transaction costs are due tothe need to coordinate the exchange of sticky localinformation (von Hippel, 1998). Similarly, the IPmodels described in the second section considertask interdependence as one of the key determi-nants of the extent of required coordination. Weexpect that task modularity will reduce coordina-tion requirements across both internal interfacesand external interfaces. The following hypothesisis presented:

Hypothesis 1:

The level of task modularity is negatively ass-ociated with (a) external coordination effort,(b) internal coordination effort.

Task modularity also should be a significantpredictor of production efficiency and the timerequired for completing the task. Consistent withresults from the IP-based analytical modelsdescribed in the second section, we expect thattasks with higher level of interdependence will bemore likely to require iterative cycles to resolveuncertainty, which in turn will increase rework,hence production effort and completion time,ceteris paribus. The following hypotheses arepresented:

Hypothesis 2:

The level of task modularity is negatively asso-ciated with technical problem solving effort.

Hypothesis 3:

The level of task modularity is negatively asso-ciated with time for task completion.

Taken together, these three hypotheses address theobjective functions for both the views discussed inTable 1. Since the key constructs underlying thesehypotheses are not identical, these hypotheses arenot competing with one another. Some trade-offs between underlying constructs are possible,depending upon the manner in which the inter-faces are selected during the process of taskmodularization.

We test the same hypotheses using sub-dimen-sions of task modularity based on Sharman et al.’s(2002) definition of visibility and dependence. The

Process

Architecture

Task Modularity: - Combined Modularity

(decreases)

- Visibility (increases)

- Dependence (increases)

Task Outcomes: Internal Coordination Effort

External Coordination Effort

Problem Solving Effort

Duration

Task and

Project

UncertaintyIncreases

Decreases

Controls:- Project Complexity

Figure 3. Conceptual framework.

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 449

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

reader can recall from the second section thatvisibility represents the degree to which informa-tion generated from a particular task affects bothdownstream and upstream tasks. Dependence, onthe other hand, represents the degree to whichinformation from other upstream or downstreamtasks affects a particular task. We expect that eachsub-dimension of modularity will contribute to theoverall predicted effect on the task outcomes. Intheory, both visibility and dependence entailinformation exchanges and communication andshould contribute to the hypothesized effect.

We add project complexity as a control. Devel-opment complexity has been reported as the mostimportant cost driver in software cost estimationmodels (Boehm, 1981; Brooks, 1995; Blackburnet al., 2002). Similarly, we expect that projectcomplexity is positively associated with coordina-tion effort and problem-solving effort. Complexityis expected to be positively associated with taskduration. We test our predictions using empiricaldata from software development. The next sectiondescribes the context for the empirical study andmethodology.

EMPIRICAL EVIDENCE: DECISIONS FOR

DISTRIBUTED SOFTWARE DEVELOPMENT

PROJECTS

Our data came from a sequence of softwaredevelopment projects within the global R&Ddepartment of MedDev, the disguised name of amultinational healthcare corporation. The man-date for this R&D department is to completelyoutsource software coding and other component-level development work. Only system-level designand allied administrative work tasks are kept in-house. Hence, we restricted our attention to therelation between architecture decisions and pro-blem solving and coordination efforts for systemdevelopment tasks.

We have collected data on the entire set ofprojects executed by this R&D group during athree-year period. These projects include thedevelopment of software applications that providestorage, analysis and communication of datacollected by medical devices, software applicationsthat enables uploading of data from hardwaredevices to PC or web-platform, the development ofa commercially viable standard for data transportand integration to and from a category of medical

devices, the development of internal standards fordevice interface, software applications for remotemonitoring and control of distinct groups ofmedical devices, an information managementsystem for critical care testing data at hospitals,and a data management software for healthcareprofessionals.

Data were obtained through structured inter-views with project leaders and project managers atMedDev. In the next section, we identify cate-gories of system development tasks within thesoftware development projects. We also describehow a DSM and allied data were drawn for eachproject that we have observed at MedDev.

Sample

The unit of analysis is the development task. Wehave collected data for 11 projects conductedwithin a three-year horizon at MedDev, represent-ing 71 system development tasks. Detailed com-ponent development tasks were fully outsourced.Their linkages within the project are capturedthrough the coordination effort associated with thesystem level tasks.

An initial review of the work breakdownschedule for one of the projects, involving 250activities, resulted in aggregation into nine types ofsystem development tasks: customer requirementsspecification describes the requirements of theproduct based on market knowledge, customerresearch, inputs from the sales and the experiencewith past products; system requirements specifica-tion defines product technical features based onend user functionality (hardware, software, com-munication platforms, etc.); design software archi-tecture includes the definition of high-levelsoftware architecture (interface between modules,database schema, input/output flows); design ofuser interface refers to the definition of how theuser interacts with the software system, inputs andoutputs; failure mode effects analysis is a studyintended to recognize and evaluate the potentialfailure modes and causes associated with theproduct design; validation protocol is the definitionof plan for testing at the system level; formaltesting is the testing of the software to ensure thesystem functions as specified; human factor testingis the analysis of the product through laws ofergonomics, simplicity and standards for userinterface; and external evaluations is the design ofprotocol to test product with end user, including

P. J. GOMES AND N. R. JOGLEKAR450

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

definition of performance metrics and go/no-gocriteria. The task nomenclature follows the desig-nations used in the firm’s internal R&D flowchart.

The comprehensiveness of the list and validity ofeach task type as an individual category weretested with two senior project leaders at MedDev.We asked the project leaders to identify anyadditional system-level tasks or any lower-leveltasks that did not fit into any of the categoriza-tions. Both managers gave their agreement to thelist provided.

To obtain data on the DSM for each project weinterviewed the respective project leader and theproject manager. The interviews lasted approxi-mately two hours and followed the structuredapproach for building a DSM. For each task, weasked whether it required information from theremaining tasks and what was the strength ofinformation dependence. The DSM for Alphaproject, the first project that we observed, is shownin Figure 4 for illustrative purposes. We presentdata on the system design tasks and seven-component level development tasks.

The strength of dependence could be character-ized by the informants as low (L), medium (M),high (H) or null dependence. Only the anchorswere described with low representing a hands-offcommunication of information, and high a sig-nificant requirement for interaction. We haveassigned weights 1, 4 and 7 to the low, mediumand high dependencies reported by the informants,in order to reflect strength of dependence on a 7-point Likert scale. We have verified, but notshown, that our results remain materially similar,

even if we use alternative (e.g., 5-point) scales thathave been used in the literature. The sequence oftasks presented in the DSM follows the actual startdate. A template was used to record the indica-tions provided by the interviewees. The projectleader and project manager agreed on the strengthof information dependence before data wererecorded.

We have gathered data on the total amount ofengineering problem-solving effort (hours) andcoordination (hours) associated with each devel-opment task, as well as the time elapsed betweenstarting and concluding the task. The total hoursallocated to the project by internal elements isregistered in a project activity tracking system(PATS) database. Since the database only providesthe total hours allocated to a specific task, werelied on the informants, namely the project leaderand the technical leaders, to provide the break-down into production, internal coordination andexternal coordination. Internal coordination in-cludes hours spent interacting with internal teamsworking on different tasks within the project orwith other development groups within the organi-zation. Examples of internal interfaces includeother software projects, hardware development,test stands, marketing and customer care. Externalcoordination includes time spent managingpartners under contract. Examples of externalinterfaces include establishing rules for addressingsoftware bugs or reviewing engineering releases.Coordination refers to MedDev effort only, ashours spent by external partners on coordinationwere not separately billed.

a b c d e f g h i j k l m n o p Visibility Dependence

Customer Requirements Specification a 0.20 0.00System Requirements Specification b h hmhmh 0.67 0.34Design of User Interface c h h h m m h 0.73 0.34Design Software Architecture d h h 0.24 0.13Failure Mode Effects Analysis (FMEA) e h h lmh 0.34 0.25Component Development Partner I f h h hComponent Development Partner II g h h h h h hComponent Development Partner III h h h hComponent Development Partner IV i hComponent Development Partner II j h h h h h h h hComponent Development Partner III k h h h h mComponent Development Partner IV l h h lValidation Protocol m h h h h h h 0.07 0.40Formal Testing n h h h h 0.22 0.27Human Factors Testing o h h l h 0.20 0.21External Evaluations p h h hh h 0.02 0.33

Figure 4. Task-based DSM for Alpha project.

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 451

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

System-level development work outsourced toan external partner for each task is calculated bythe hours billed by suppliers for system develop-ment support available from project documenta-tion. We have also obtained data on the amount ofhours billed by suppliers for component develop-ment work for each project. Data on task start andfinish dates were collected from the final schedules,which were not available for all projects.

Variables

Production effort is measured by the amount oftechnical problem-solving hours assigned to aspecific system development task, including hoursof technical problem solving reported by internalelements and hours billed by external suppliers.Internal coordination effort is measured by thenumber of hours assigned to internal coordinationas specified above. External coordination effort ismeasured by the number of hours assigned toexternal coordination. Task duration is measuredas the number of days elapsed between that taskstart date and the task finish date. The analysis ofcompletion time results has been limited to the 35tasks on which reliable schedule data are available.

We define multiple measures of task modularitybased on the DSM mapping of each project. Thevisibility and dependence measures are determinedusing the formulation presented in Table 2, afterthe work of Sharman et al. (2002). The combinedmodularity is defined as the complement of theratio between the sum of visibility and dependenceweights associated with a development task andthe maximum number of possible weights. We alsodefine a measure of feedback dependence. Thefeedback dependence measure only considers de-pendence from subsequent tasks. The formulationfor these two measures of modularity is alsopresented in Table 2.

We illustrate these measures with examples fromthe DSM depicted in Figure 4. By reading across arow, for instance task a, one obtains informationon how much this task is dependent on informa-tion from other tasks}its dependence. By readingdown a column, also for task a, one obtainsinformation on how much the information itgenerates is used by other tasks}its visibility.Consider tasks a, c and m: visibility is high for taskc, design of user interface, and low for task m,validation protocol, as several tasks depend oninformation from task c while very few depend oninformation from task m. Activities c and m havehigher dependence as they require informationfrom several other tasks, while task a, customerrequirement specification, is characterized by lowdependence. However, task c has high feedbackdependence, as most row dependences are fromsubsequent activities, while task m has low feed-back dependence. Recall that a higher value forthe modularity quotient means a less interdepen-dent structure, while a lower value means a moreinterdependent, integral structure.

In order to control for complexity, we useproject size, as represented by the hours oftechnical problem solving associated with compo-nent development, a project level effect.

RESULTS

Table 3 presents Pearson product moment correla-tion coefficients between the effort and timevariables and the alternative measures ofmodularity. Similar results have been obtained(but not reported here) using the Spearman rankcorrelation, a non-parametric rank correlationprocedure (Neter et al., 1996). Recall from defini-tions in Table 2 that our measure of Combined

Table 2. Alternate Measures of Task Modularity

Visibility ¼P

task column dependences

ðNumber of Tasks� 1Þ�maximum dependence weight

� �

Dependence ¼P

task row dependences

ðNumber of Tasks� 1Þ�maximum dependence weight

� �

Feedback Dependence ¼P

task row dependences from subsequent tasks

ðNumber of subsequent TasksÞ�maximum dependence weight

� �

Combined Modularity ¼ 1�P

task dependences

ðNumber of Task interfacesÞ�maximum dependence weight

� �

P. J. GOMES AND N. R. JOGLEKAR452

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

modularity complement the measures for visibilityand dependence. That is, higher levels of visibility(and/or dependence) imply lower values for com-bined modularity. Naturally, these measures arenegatively correlated as shown in Table 3.

Visibility and dependence are not correlated,while visibility and feedback dependence arecorrelated. In other words, tasks with high (low)visibility also tend to have high (low) dependencefrom downstream tasks, which may result initeration cycles. Moreover, combined modularityis not correlated with either internal or externalcoordination effort or with production effort.Visibility and internal coordination effort arecorrelated, along with visibility and productioneffort. On the other hand, dependence is notcorrelated with production effort nor with coordi-nation effort.

Combined modularity is significantly correlatedwith task duration. While visibility is significantlycorrelated with task duration, dependence has nocorrelation with task duration. This may indicatethat the execution of tasks producing informationwidely used by subsequent tasks tends to beprolonged in time.

In order to test the hypotheses presented in thethird section, we have estimated several modelsusing either the combined or the distinct measuresof task modularity as predictors. The internal andexternal coordination efforts, production effort(i.e., technical problem-solving effort) and taskduration are the dependent variables for Tables 4,5 and 6, respectively. These models were estimatedusing OLS. The highest condition index was withinthe recommended limit of 30 (Belsley–Kuh–Welsch, 1980), and variance inflation factors forthe independent variables were below 10 (Neteret al., 1996), confirming that multicollinearity isnot a problem in any of the models.

Table 4 presents the results for the models thatuse coordination effort as the dependent variable.From model 1 we see that combined modularity isnot associated with internal coordination effort. Inmodel 2, we use the multiple measures of mod-ularity. Only visibility is positively associated withinternal coordination effort. The results from model3 show that combined modularity is negativelyassociated with external coordination effort. Again,only visibility has a significant impact on externalcoordination effort as shown in model 4.

Table 3. Pearson Product Moment Correlation Coefficients (n=71, Except where Indicated)

1 2 3 4 5 6 7 8

1. Visibility 1.02. Dependence �0.05 1.03. Feedback dependence 0.25� 0.66�� 1.04. Combined modularity �0.83�� �0.53�� �0.59�� 1.05. Production effort 0.25� �0.10 �0.12 �0.16 1.06. Internal coordination effort 0.276� �0.131 �0.063 �0.161 0.43�� 1.07. External coordination effort 0.225 �0.066 �0.056 �0.154 0.697�� 0.637�� 1.08. Task duration (n ¼ 35) 0.50�� �0.03 �0.08 �0.40� 0.67�� 0.433�� 0.656�� 1.0

�correlation is significant at 0.05 level, ��Correlation is significant at 0.01 level.

Table 4. Regressions Models for Coordination Effort (Standardized Coefficients)

Internal coordination External coordination

(1) (2) (3) (4)

Visibility 0.326� 0.317��

Dependence �0.076 �0.015Feedback dependence �0.069 �0.072Combined modularity �0.185 �0.209y

Project complexity 0.164 0.191 0.371�� 0.391��

Adjusted R2 0.024 0.078 0.134 0.162F 1.879 2.48� 6.40�� 4.37��

N 71 71 71 71

�significant at 0.05 level, ��Significant at 0.01 level, ysignificant at 0.10 level.

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 453

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

These results lend support to hypothesis 1(a)that task modularity is negatively associated withexternal coordination effort, whereas the supportfor hypothesis 1(b) that task modularity isnegatively associated with internal coordinationeffort is mixed. Coordination across organiza-tional boundaries seems to be more sensitive to theprocess architecture decisions that determinedependencies across development tasks.

Project complexity has a significant impact onexternal coordination effort but it is not significantin the models predicting internal coordination.The use of this control variable ensures that sizecomplexity effects are filtered from the analysis.

The results shown in Table 5 confirm thatcombined modularity (visibility) is negatively(positively) associated with the problem solvingeffort on a task. Thus, hypothesis 2 is supported.We note that visibility provides a larger explana-tory power than combined modularity. Projectcomplexity is also significant, i.e., tasks associatedwith projects with greater component developmentwork also tend to require more technical problemsolving.

Finally, the results shown in Table 6 confirmthat combined modularity (visibility) is negatively(positively) associated with the duration for a task.Thus, hypothesis 3 is supported and visibilityprovides a larger explanatory power than com-bined modularity.

The measure of combined modularity has asignificant impact on task outcomes, with theexception of internal coordination effort. When weconsider multiple dimensions of modularity wefind that task dependence and feedback depen-dence are not significant in any of the models whilevisibility is strongly significant in all of the models.

These results signal the need to measure modular-ity in its multiple dimensions to truly understandhow the design of interfaces and the resultingmodularity impacts task outcomes.

DISCUSSION AND CONCLUSIONS

Our results have shown how task modularityrelates to development task outcomes, namelyproduction and coordination costs, and taskduration. Based on the DSM representation ofthe process architecture we deployed severalmeasures associated with task modularity. Wehave used data from software development pro-jects to argue that both the transactional efficacies,observed in terms of reduction in coordinationeffort and project completion time are associatedwith increase in task modularity.

The managerial implications of our findingsrelate to the degrees of freedom available fordesign of tasks and selection of task interfaces.Our findings reveal that task modularity isnegatively associated with technical problem-sol-ving effort. One explanation for the observedresults might be that the tasks have been struc-tured in order to make the problems well posed,i.e., the designers are exploiting the architecturerather than exploring new issues. Moreover,process architects and managers develop theprocess architecture ex ante, i.e., before carryingthe development tasks. They observe the size of theproduction effort, coordination effort and theduration ex post, that is after the task has beencarried out all the uncertainties associated with thedevelopment effort has been resolved. Confirma-

Table 5. Regressions Models for ProductionEffort (Standardized Coefficients)

(5) (6)

Visibility 0.371��

Dependence 0.026Feedback dependence �0.176Combined modularity �0.214y

Project complexity 0.369�� 0.382��

Adjusted R2 0.134 0.195F 6.42�� 5.24��

N 71 71

�significant at 0.05 level, ��Significant at 0.01 level, ysignificantat 0.10 level.

Table 6. Regressions Models for Task Duration(Standardized Coefficients)

(7) (8)

Visibility 0.582��

Dependence 0.084Feedback dependence �0.238Combined modularity �0.424�

Project complexity 0.176 0.166

Adjusted R2 0.135 0.234F 3.65�� 3.60�

N 35 35

�significant at 0.05 level, ��Significant at 0.01 level, ysignificantat 0.10 level.

P. J. GOMES AND N. R. JOGLEKAR454

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

tion of the three hypothesized associations, at leastin the observed context, suggests a useful patternin which increasing modularity can reduce thedevelopment time and effort. However, the resultsalso suggest some trade-offs: the modularitymeasures do not contribute equally to thisgain in efficiency and increasing modularity isnegatively associated with the technical problem-solving effort. Increasing visibility has a largerelasticity with respect to the outcome variablethan increasing the combined modularity. Ob-served elasticity also varies based on the choice ofthe outcome variable: either problem solving(production) or coordination effort or taskcompletion time.

Our results indicate that depending on theoutcome they seek, managers can come up withdifferent types of task decompositions and inter-faces. These findings are consistent with theprocess architecture view of interface specification.This view argues that interface performance canvary across task and or organization boundaries(Puranam and Jacobides, 2005), and it might notbe sufficient to focus on aggregate measures ofmodularity in order to improve transactionalefficiency.

Our findings have implications for both engi-neering and economic research. We have pointedout in the second section that there is growingbody of engineering process optimization litera-ture that takes an information processing viewand focuses on optimization of the architecturebased on task time minimization (Smith andEppinger, 1997; Browning and Eppinger, 2002).There is also an emerging stream of studies thatreport that on the economics in these settings(Morelli et al., 1995; Novak and Eppinger, 2001;Sriram, 2002; Sosa et al., 2004). Our findingssuggest that the policies generated by the engineer-ing and economic approaches will lead to differentoutcomes. However, the outcomes can be corre-lated and it ought to be possible to extend thisresearch by combining their outcome measures.

Another insight comes from contrasting shortfeedback cycles versus long feedback cycles, whichcan be illustrated with reference to the Alphaproject DSM shown in Figure 4. These cycles canprovide an explanation for why visibility mightprovide more of an explanation for the variancethan dependence. Visibility generates coordinationburden directly. Dependence, on the other hand, islikely to increase the total elapsed time for the

project (but not with the elapsed time for theindividual tasks). For instance, the long feedbackdependence of design of user interface on thesecond phase of component development bringstask uncertainty that may affect a higher numberof activities visible to design of user interface, thanshort feedback dependence with the FMEA task.During post hoc discussion of our results, MedDevmanagers pointed out that they had created anoption to break the dependence cycle or filterfeedback dependencies associated with long cycles.A committee named Change Control Board (CCB)intervened in the project to decide which engineeringchanges based needed to be incorporated into theproduct before its release, and which engineeringchanges could be left to be dealt with during life-cycle management projects.

Our study suggests that unpacking modularity, interms for visibility and dependence of task inter-faces, is a useful line of enquiry for understandingcoordination problems arising during ‘joint-by-interdependence’ development tasks. Often, it isnot possible to make a system completely modularand collective effort will be required to yield non-separable output. Interdependence raises the diffi-culty in metering and controlling performance(Alchian and Demsetz, 1972). This metering pro-blem is particularly relevant in the product devel-opment context. Novak and Stern (2003) providerich descriptions of development cases showing thathard-to-observe effort provision is critical, particu-larly during system management and integrationrather than component development tasks. Hence,task performance assessment must account for thelevel and the type of modularity measures. More-over, even when a development task wasoutsourced, the production work often requiredinternal problem solving, either due to the factthat proprietary knowledge was involved, or toleverage internal competences in defining productarchitecture or testing plans. This decision to ‘makeand buy’ (Harrigan, 1984) combines the problem ofjoint effort arising from interdependences with jointeffort in a production task.

We end this section by identifying two majorlimitations of our work. First, the outcomemeasures (problem-solving effort, coordinationand time duration) are correlated with one anotheras shown in Table 3. Architects are aware of thedegree of this correlation based on their pastexperience with task types and use this knowledgeto trade off coordination effort against the

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 455

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

production effort. An exploration of this aspect ofproblem for our data set is available as a stand-alone paper based on a transaction cost economicsframework (Gomes and Joglekar, 2003). Thisanalysis accounts for the outsourcing fractionsexplicitly, however, it cannot account for theelapsed timed as the outcome variable in a mannerdone in Table 6.

Second, the external validity of the findings maybe limited. Our data come from software develop-ment projects owned by a single firm. There areimportant similarities and differences between themanagement of product and software develop-ment processes (Nambisan and Wilemon, 2000;Joglekar and Rosenthal, 2003). Software develop-ment tends to require more flexible developmentprocesses (MacCormack et al., 2001). Still, taskdecomposition and concurrency, and tracking ofcoordination costs are germane to both theseprocesses. Our definitions of the modularityconstructs could be used in other settings, how-ever, extrapolation of our results into othertechnologies, firms and industry settings remainsa matter for further research.

The organization of development work beyondthe context of a single firm reveals some frailties ofthe current modularity models owing to theframing of objectives (i.e., either for reducingcompletion time based on an IP view or forimproving transactional efficiency based on TCE).While theoretical analyses tend to separate theseobjectives, we have argued that managers tend totake an integrated view of modular developmentefforts. Our study amplifies the importance ofunderstanding and managing modularity andexposes some opportunities for cross-sectionalresearch on the phenomenon of distributed pro-duct development at the intersection of informa-tion processing perspective and transaction costseconomics.

REFERENCES

Alchian A, Demsetz H. 1972. Production, informationcosts and economic organization. American EconomicReview 62: 777–795.

Alexander C. 1964. Notes on the Synthesis of the Form.Harvard University Press: Cambridge, MA.

Allen TJ. 1977. Managing the Flow of Technology:Technology Transfer and the Dissemination of Techno-logical Information within the R&D Organization. MITPress: Cambridge, MA.

Argyres NS. 1996. Evidence on the role of firmcapabilities in vertical integration decisions. StrategicManagement Journal 17: 129–150.

Azoulay P. 2003. Acquiring knowledge within andacross firm boundaries: evidence from clinical devel-opment. National Bureau of Economic ResearchWorking Paper No. W10083.

Baldwin CY, Clark KB. 2000. Design Rules, Volume 1:The Power of Modularity. MIT Press: Cambridge, MA.

Baldwin CY, Clark KB. 2002. Where do transactionscome from? A perspective from engineering.Social Science Research Network Electronic PaperCollection.

Belsley D, Kuh E, Welsch R. 1980. Regression Diag-nostics: Identifying Influential Data and Sources ofCollinearity. Wiley: New York.

Blackburn JD, Van Wassenhove LN, Forselius P. 2002.Brooks’ law revisited: improving software productiv-ity by managing complexity. WP 2002-85, VanderbiltUniversity.

Boehm BW. 1981. Software Engineering Economics.Prentice-Hall: Englewood Cliffs, NJ.

Brooks FP. 1995. The Mythical Man-Month: Essays onSoftware Engineering (Anniversary edn). Addison-Wesley: Reading, MA.

Brown SL, Eisenhardt KM. 1995. Product development:past research, present findings, and future directions.Academy of Management Review 20: 343–378.

Browning TR. 2001. Applying the design structurematrix to system decomposition and integrationproblems: a review and new directions. IEEE Transac-tions on Engineering Management 48: 292–306.

Browning TR, Eppinger SD. 2002. Modeling impacts ofprocess architecture on cost and schedule risk inproduct development. IEEE Transactions on Engineer-ing Management 49: 428–442.

Clark KB, Fujimoto T. 1991. Product DevelopmentPerformance: Strategy, Organization, and Manage-ment in the World Auto Industry. Harvard BusinessSchool Press: Boston, MA.

Coase RH. 1937. The nature of the firm. Economica 4:386–405.

Galbraith J. 1973. Designing Complex Organizations.Addison-Wesley: Reading, MA.

Gerwin D, Barrowman NJ. 2002. An evaluation ofresearch in integrated product development. Manage-ment Science 48: 938–953.

Gomes PJ, Joglekar NR. 2003. The costs of coordinat-ing distributed software development. BostonUniversity School of Management Working Paper.

Harrigan KR. 1984. Formulating vertical integrationstrategies. Academy of Management Review 9: 638–652.

Joglekar NR, Rosenthal SR. 2003. Coordination ofdesign supply chains for bundling physical and soft-ware products. Journal of Product Innovation Manage-ment 20: 374–390.

Krishnan V, Eppinger SD, Whitney DE. 1997. A model-based framework to overlap product developmentactivities. Management Science 43: 437–451.

Krishnan V, Ulrich KT. 2001. Product developmentdecisions: a review of the literature. ManagementScience 47: 1–21.

P. J. GOMES AND N. R. JOGLEKAR456

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde

Loch CH, Terwiesch C. 1998. Communication anduncertainty in concurrent engineering. ManagementScience 44: 1032–1048.

MacCormack A, Verganti R, Iansiti M. 2001. Developingproducts on internet time: the anatomy of a flexibledevelopment process. Management Science 47: 133–150.

McCord KR, Eppinger SD. 1993. Managing the integra-tion problem in concurrent engineering.Working PaperNo. 3594, M.I.T. Sloan School of Management.

Moenaert RK, Souder WE, De Meyer A, Deschoolmee-ster D. 1995. R&D}marketing communication dur-ing the fuzzy front-end. IEEE Transactions onEngineering Management 42: 243–257.

Morelli MD, Eppinger SD, Gulati RK. 1995. Predictingtechnical communication in product developmentorganizations. IEEE Transactions on EngineeringManagement 42: 375–386.

Nambisan S, Wilemon D. 2000. Software developmentand new product development: potentials for cross-domain knowledge sharing. IEEE Transactions onEngineering Management 47: 211–220.

Neter J, Kutner MH, Nachtsheim CJ, Wasserman W.1996. Applied Linear Statistical Models (4th edn).McGraw-Hill: New York.

Newell A, Simon HA. 1963. GPS, a program that simulateshuman thought. In Computers and Thought, FeigenbaumE, Feldman J (eds). McGraw-Hill: New York.

Novak S, Eppinger SD. 2001. Sourcing by design:product complexity and the supply chain. Manage-ment Science 47: 189–204.

Novak S, Stern S. 2003. The impact of technologicalinterdependency on contracting complementarities:evidence from automobile product development.Kellogg School of Management Working Paper.

Puranam P, Jacobides M. 2005. Why interface specifica-tion varies between organizations and why thatmatters. London Business School Working Paper.

Schrader S, Riggs W, Smith R. 1993. Choice overuncertainty and ambiguity in technical problemsolving. Journal of Engineering and Technology Man-agement 10: 73–99.

Sharman DM, Yassine AA, Carlile P. 2002. Character-izing modular architectures. In Proceedings of theASME 2002 International Design Engineering Techni-cal Conferences, 14th International Conference onDesign Theory & Methodology, Montreal, Canada,29 September–2 October, 2002.

Simon HA. 1969. The Sciences of the Artificial. The MITPress: Cambridge, MA.

Smith RP, Eppinger SD. 1997. Identifying controllingfeatures of engineering design iterations. ManagementScience 43: 276–293.

Smith RP, Eppinger SD. 1998. Deciding between sequen-tial and concurrent tasks in engineering design. Con-current Engineering: Research and Applications 6: 15–25.

Sosa ME, Eppinger SE, Pich M, McKendrick DG, StoutSK. 2002. Factors that influence technical commu-

nication in distributed product development: anempirical study in the telecommunications industry.IEEE Transactions on Engineering Management 49:45–57.

Sosa ME, Eppinger SE, Rowles C. 2004. The misalign-ment of product architecture and organizationalstructure in complex product development. Manage-ment Science 50: 1674–1689.

Souder WE, Moenaert RK. 1992. Integrating marketingand R&D project personnel within innovation pro-jects: an information uncertainty model. Journal ofManagement Studies 25: 485–512.

Sriram RD. 2002. Distributed and Integrated Collabora-tive Engineering Design. Sarven Publishers: Glenwood,MD.

Steward DV. 1981. The design structure system: amethod for managing the design of complex systems.IEEE Transactions on Engineering Management EM-

28: 71–74.Takeishi A. 2002. Knowledge partitioning in the interfirmdivision of labor: the case of automotive productdevelopment. Organization Science 13: 321–338.

Tatikonda MV, Rosenthal SR. 2000. Technologynovelty, project complexity, and product developmentexecution success: a deeper look at task uncertainty inproduct innovation. IEEE Transactions on Engineer-ing Management 47: 74–87.

Terwiesch C, Loch CH. 1999. Measuring the effective-ness of overlapping development activities. Manage-ment Science 45: 455–465.

Terwiesch C, Loch CH, De Meyer A. 2002. Exchangingpreliminary information in concurrent engineering:alternative coordination strategies. ManagementScience 13: 402–419.

Tushman ML, Nadler D. 1980. Communication andtechnical roles in R&D laboratories: an informationprocessing approach. Management Science, SpecialStudies: R&D Management 15: 91–112.

Ulrich K, Ellison D. 2005. Beyond make-buy:internalization and integration of design and produc-tion. Production and Operations Management 14:315–330.

von Hippel E. 1990. Task partitioning: an innovationprocess variable. Research Policy 19: 407–418.

von Hippel E. 1998. Economics of product developmentby users: the impact of ‘sticky’ local information.Management Science 44: 629–638.

Williamson OE. 1985. The Economic Institutions ofCapitalism. Free Press: New York.

Williamson OE. 2000. Empirical microeconomics: an-other perspective. University of California at BerkeleyWorking Paper.

Yassine AA, Joglekar NR, Braha D, Eppinger S,Whitney D. 2003. Information hiding in productdevelopment: the design churn effect. Research inEngineering Design 14: 145–161.

LINKING MODULARITY WITH PROBLEM SOLVING AND COORDINATION EFFORTS 457

Copyright # 2008 John Wiley & Sons, Ltd. Manage. Decis. Econ. 29: 443–457 (2008)DOI: 10.1002/mde