concurrent engineering: research and applications · concurrent engineering: research and...

CONCURRENT ENGINEERING: Research and Applications

Concurrent Engineering and Design Oscillationsin Complex Engineering Projects

Christoph Loch,* Jurgen Mihm and Arnd Huchzermeier

INSEAD, Boulevard de Constance, 77305 Fontainebleau, France

Abstract: Coordination among many interdependent actors is key activity in complex product development projects. The challenge is made

more difficult in concurrent engineering processes, as more activities happen in parallel and interact. This coordination becomes progressively

more difficult with project size. We do not yet sufficiently understand whether this effect can be controlled with frequent and rich communication

among project members, or whether it is inevitable. Recent work in complexity theory suggests that a project might form a ‘‘rugged landscape’’,

for which performance deterioration with system size is inevitable.

This article builds a mathematical model of a complex concurrent design project. The model explicitly represents local component decisions,

as well as component interactions in determining system performance. The model shows, first, how a rugged performance landscape arises

from simple components with single-peaked performance functions, if the components are interdependent.

Second, we characterize the dynamic behavior of the system analytically and with simulations. We show under which circumstances it

exhibits performance oscillations or divergence to design solutions with low performance. Third, we derive classes of managerial actions

available to improve performance dynamics, such as limiting the ‘‘effective’’ system size of fully interdependent components, modularity, and

cooperation among designers. We also show how ‘‘satisficing’’, or a willingness to forego the last few percent of optimization at the component

level, may yield a disproportionally large improvement in the design completion time.

Key Words: complexity, concurrent engineering, design oscillations, engineering change orders, new product development.

1. Introduction

In the design of complex products (such as cars,aerospace systems, software, or industrial equipment),individual components are designed separately, butinfluence one another. Ongoing problem choicesin other components make the requirements for aparticular component inherently unstable [1,50]. Forexample, Allen [2] reported that in the design ofaerospace subsystems, engineers’ preferences for alter-natives (their current guess of the ‘‘best solution’’)changed frequently and quickly, often back and forthand back, as the design evolved. Moreover, it wouldhave been virtually impossible to anticipate the finalchoice at the outset.

The design of such products is an example of acomplex system (e.g., [5,14,18,25,52]), which can bedefined as ‘‘made up of a large number of parts thatinteract in nonsimple ways, . . . [such that] given theproperties of the parts and the laws of their interac-tions, it is not a trivial matter to infer the propertiesof the whole’’ (Simon [41, p. 195]). In particular, a

complex system represent a ‘‘rugged landscape’’, inwhich the highest performance peaks cannot beidentified beforehand and cannot be found with localsearch [18,24].

The above described difficulty in designing suchcomplex systems manifests itself in widespread perfor-mance problems – budget and schedule overruns, missedspecifications (e.g., [36,47,48]), and management frus-tration with ‘‘performance oscillations’’. Consider thefollowing statement by a car engine developmentmanager: ‘‘In the development of a new engine, wetake a design direction and pursue it, but often run intotrouble [as an engine is very complex, this is oftenrelated to some component performance]. So, wego back to the starting point (usually, the previousengine) and try another approach. That also runs intotrouble. In this way, we typically pursue severalapproaches, to different levels of progress, and thefunny thing is that, at the end, we quite often come backto the first approach, where we then set several designparameters to fixed values that we believe to beworking!’’

Concurrent engineering increases the level of paralle-lism and, thus, exacerbates the interactions amongcomponents [29]. For example, Terwiesch and Loch[48] observed the engineering change (EC) management

*Author to whom correspondence should be addressed.E-mail: [email protected]

Volume 11 Number 3 September 2003 1871063-293X/03/03 0187–13 $10.00/0 DOI: 10.1177/106329303038030

� 2003 Sage Publications

+ [25.9.2003–8:45am] [187–200] [Page No. 187] FIRST PROOFS I:/Sage/Cer/Cer11-3/CER-38030.3d (CER) Paper: CER-38030 Keyword

http:\\www.sagepublications.com

http://crossmark.crossref.org/dialog/?doi=10.1177%2F106329303038030&domain=pdf&date_stamp=2016-07-26

process in the final, highly concurrent, phase of thedesign of a car and found that ECs would ‘‘snowball’’from one component to another, in some cases in cycles,causing long resolution times.This article builds a mathematical model of a complex

distributed design project with parallel componentdesign. The model explicitly represents both localcomponent decisions and component interactions indetermining system performance. The model demon-strates first, how easily a nonlinear (rugged) perfor-mance landscape arises, even from simple componentswith single-peaked performance functions, if thecomponents are interdependent.Second, we characterize the dynamic behavior of the

system, arising from the designers making successivelocal component decisions over time. We analyticallycharacterize a slightly simplified system, and wesimulate the complete system to show under whichcircumstances it exhibits performance oscillations ordivergence to design solutions with low performance.Third, we explain why certain managerial actions

improve performance dynamics, such as modularity,and cooperation among designers. We also show how‘‘satisficing’’, or a willingness to forego the last fewpercent of optimization at the component level, mayyield a disproportionally large improvement in thedesign completion time.In the remainder of the article, a brief survey of

relevant literature (Section 2) is followed by thedevelopment of the model (Section 3). Sections 4 and 5describe the analytical and simulation results, whileSection 6 summarizes the implications and concludes thearticle.

2. Literature Review

Our research can be positioned in relation to threeareas of literature. The first is complexity theory, whichderives macro behavior of systems from basic buildingblocks of adaptive agents interacting in a nonlinearmanner. An influential contribution was Kauffman’sNK model of the dynamics of selective evolutionaryprocesses, which has subsequently served as a basisfor many applications in complexity theory [18,19].Several authors have applied the NK model to examinecomplexity of organizational strategy [e.g., 24,25,33,39]. This entire literature stream focuses on organi-zational change and strategy, using complexity meta-phors that are not valid at the micro level of iterationsin NPD.A second stream of literature, concurrent engineering

research, emphasizes that design is inherently iterative[16,21,28,31,40,51,59]. However, these models see itera-tion as exogenous and probabilistic and do not consider

the source of iteration, the NPD search process in anetwork of interacting components.

The third area of literature uses the design structurematrix (DSM) to model iteration. The structure matrixis a dependence graph that represents dependenciesamong components [11,46]. Smith et al. [42] use theeigenvalues and eigenvectors of a DSM based onreiteration probabilities to identify iteration cycles.They emphasize stochastic ‘‘trial and error’’ on theindividual component as a design source of iterations,while our model emphasizes that system interactionscause iterations even if each component finds its bestdesign right away.

It is well established that design oscillations occur andlead to project delays and failures [6,15,20,38].Engineering literature has recognized that system sizeis a problem and has developed methods to intelligentlycut a complex problem into pieces and integrate themagain [4,26,43]. By and large, managing size andcomplexity of an NPD project has not received wide-spread attention in the empirical literature. The fewarticles that exist describe phenomena that our modelcan explain. Clark [7, p. 1260] concludes that ‘‘bringingparts engineering in-house and adding work by doingmore unique parts design adds more engineering hoursthan one would expect from the amount of the increasedworkload,’’ and that ‘‘the impact of scope on lead timeworks through changes in the difficulty of coordinationin the planning process.’’

3. Model Description

The NPD team consists of individual decisionmakers (or ‘‘engineers’’), each working on his owntask within the constraints of the architecture, collec-tively solving a distributed information processingproblem.1 The reader may picture a task as a‘‘component’’, a basic building block of the project,which is determined by functional requirements as wellas by the product architecture. Each team memberoptimizes a ‘‘local’’ performance measure for hiscomponent. But the components are interdependent,requiring a communication process between the engi-neers when making successive design decisions on theirrespective components. At each decision point, theengineer must consider the status of other componentsin the system.

1Even in a hierarchy and with a centralizing architecture, a lot of decisionmaking is often left to individual decision makers. Recent literature hasrecommended decentralized decision making in the form of cross-functionalteams [8]. The resulting interdependence leads to more lateral, localized, andcooperative decision making [25,52,55], for example, using the design structurematrix [1,11,12,46].

188 C. LOCH ET AL.


3.1 Component Performance andInterdependence

At a given decision point, each engineer i has aperformance function Pi for the component he isresponsible for. In the simplest case, performance(typically a mixture of requirement specifications andcost) depends on one decision variable and one uniqueoptimum2 hi as well as on the decision variables {hj} ofother components. We also assume that hi and {hj} arecontinuous. Thus, Pi¼ f(hi, {hj}).

Taking the other components {hj} as constant, perfor-mance as a function of hi alone becomes Pi ¼ f hi, hj

� �� .

We make the following assumptions about Pi, summar-ized in Figure 1 (left hand panel). Virtually all designdecisions reflect tradeoffs. Thus, the optimal designparameter value lies somewhere between the extremes ofthe spectrum of possible values.3 To take a simpleexample, if a middle range car engine designer endows hisengine with very low torque, the car is boring and his taskperformance low. If, on the other hand, he specifies hisengine to have the torque of a F1 racing car, the car is tooexpensive, and task performance is also low.

In general, the specific functional form of Pi can beapproximated by a Taylor series. The simplest approx-imation for Pi displaying the above characteristics is thequadratic. Since our goal is not to model a specificproject but to understand the qualitative behavior ofcomplex projects, we normalize the quadratic approx-imation such that its maximum takes on the value of 1and does not have a fixed offset. Thus, only one fitparameter, di, remains (we take di as positive to assurethe concavity of the quadratic, see the Appendix). As aresult, we obtain Equation (1), where the sum termincorporates the influence of the other components.

Pi ¼ f hi, hj� ��

¼ �di hi �Xn

j 6¼ibijhj

� �2þ1: 1ð Þ

hj is the latest known status of the decision oncomponent j, which component engineer i takes asgiven. The effect of other decision makers j on theperformance of component i is twofold. First, theirdecisions shift the optimal choice for decision maker i.Second, the other decision makers { j} influence the bestperformance reachable by decision maker i.

The first effect translates into the decision variables hjinfluencing the position of the optimal decision for hi.Thus, the summation term

Pnj 6¼i bijhj in Equation (1)

shifts the locus of the optimal hi. Assuming linearityagain represents the simplest possible model of inter-dependency among the components. bij represents theinfluence that hj has on Pi. The direction of shift changeswith the sign of bij (see Appendix). In our simpleexample, the maximal output torque of the enginedetermines the optimal size of the clutch cylinder.

The second interaction effect is caused by the otherdecision makers { j} influencing the best performancereachable by decision maker i. At worst, componentj’s design makes component i’s task very difficultor impossible, reducing its performance to a lowvalue. At best, component j puts no restriction on i,allowing it to achieve its best inherently possibleperformance. At both extremes, a small change in hjmakes little difference for Pi, but at intermediatevalues, a change in hj matters (right hand panel inFigure 1).

If in our simple car example, the engine compartmentis much too small, a good engine design remainsimpossible. If the compartment is close to the sizeneeded by the engine designers, a moderate change insize opens up many design opportunities for the enginedesigners. If the compartment is sufficiently large,additional increases no longer benefit engine perfor-mance. As an illustration from the literature, considerthe interaction of the engine hull geometry and theclimate control ducts and filter in the design of a car.The engine can ‘‘squeeze’’ the filter by claiming toomuch of the scarce space. If the engine hull is smallenough to not invade the dashboard space, it allows thefilter to assume an optimal design (see Terwiesch et al.[49] for additional examples).

This second interaction effect is represented bymultiplying Pi with constraints Iij. They implement theabove described qualitative structure in the form of theerror function, constant at the extremes and with a slopeaij in the intermediate region (Figure 1, right panel).

Iij ¼ clij þ crij � ðclij � crijÞerfðvij � aijhjÞ: 2ð Þ

cli,j is the constant at the far left side of the function, cri,j

is the corresponding right side. We normalize thesevalues, so that both are 2 [0,1]. As the constrainingeffect of component j may run in either direction of hj,we allow the error function to increase or decrease. It ischaracteristic for a complex system that the influences ofthe other components on Pi interact. The simplest wayof modeling this is multiplicative.4 Thus, the totalperformance for component i is obtained by multiplying

2In practice, components often have multiple decision variables and optima,which make the system more complex and exacerbate the instability phenomenadiscussed in this article – see Section 3.4.3For detailed design decisions, engineers also identify ‘‘smaller the better’’ and‘‘larger the better’’ problems ([37] Chapter 5), when no tradeoff is present within‘‘reasonable’’ limits. If we allow such monotonicity of Pi in our simulations, thebehavior of the system does not change (details can be obtained from theauthors).

4The assumption of multiplicative interrelation between complex parts is widelyused, e.g. in evolution biology. Total fitness of an organism is assumed to be theproduct of the fitness contributions of all genetic loci [13,27].

Complexity and Design Oscillations 189


(1) with the constraints from (2) (indicated in the centerof Figure 1):

Pi ¼ Piðhi, hjÞY

j 6¼iIij : 3ð Þ

In addition to the local performance of individualcomponents, we need to specify an aggregate systemperformance. Since the interaction of all individualcomponents is already represented in the local Pis, theperformance of the complete system can be taken as thesum of the individual performances (which does notcause a loss of generality, as any level of complexity canbe produced with the interactions alone [18]). While fora specific project, not all individual tasks can beassumed to be of equal importance to the overallperformance, we are interested in fundamental problemsolving dynamics and therefore consider a symmetricsystem, with equal weights for all components. Thus,total performance is P¼�iPi.

3.2 Decisions and Time

Having defined the static structure of the model, wenow describe how decision making, communication,and performance evolve over time. Each engineerperiodically updates his information about other com-ponents and his decision hit. These updates happenpartially at scheduled review meetings, but also to asubstantial degree at ‘‘random’’ points in time, driven byunscheduled events (such as problem progress, anencounter in the hallway or at the coffee machine, ornew information heard accidentally at a meeting). Wereflect this unscheduled nature of updates by making thedecision times for each decision maker i a Poisson

process, with exponentially distributed time intervalsbetween decisions. In the model, all changes of the deci-sion variable hi are initiated at these decision points.5

Each time the component engineer has initiated adecision update, he takes stock of the latest informationhe possesses on all other components of the system, {hj}.Not all information he possesses may be current. Theengineer finds h�i instantaneously (in a companionpaper, we describe scenarios where the engineers taketime to reach the optimum and communicate ‘‘pre-liminary information’’ [35]).

Instead of optimizing his component all the way, anengineer may be willing to ‘‘satisfice’’, or settle for asolution that is slightly worse than the optimum, inorder to save iterations and time. In the simulationexperiments, we explore the tradeoff between systemperformance and time gained.

We now describe how engineers receive updates onthe decision status of other components. Loch andTerwiesch [28,48] have pointed out that immediatecommunication of design changes in an NPD setting ishelpful because changes become more expensive later inthe project they are undertaken. Therefore, eachcomponent engineer should ideally take his periodicdesign decision based on the most recent state of allother component designs. Yet, this is impossible in mostdesign settings – engineers would be inundated withinformation. In virtually all design organizations at leastsome information is passed on after a delay.

5In addition to capturing the random updates, Poisson decision points make themodel’s evolution asynchronous, that is, the probability that two exchangeshappen simultaneously is zero. In synchronous models, the ordering of theexchanges is arbitrary, which may introduce chaotic system behavior as amodeling artifact [17].

Decision variable of other decision maker hjOwn decision variable hi

Per

form

ance

Pi

Influence of other decision maker

Constraints (Iij, j i)Local Performance

• Local performance function of one variable, with one optimum.

• The optimum is interior, reflecting design tradeoffs.

• The quadratic function is a Taylor approximation of more complex functions.

• The position of the optimum shifts linearly with the change in any other component decision variable hj.

• Component j’s design hj places a multiplicativeconstraint on component i’s performance Pi.

• At the left extreme of hj, the constraint reduces the possible performance Pi to a low value (solid line).

• At the right extreme, the constraint is loose and does not reduce Pi.

• The direction of the influence of hj may also go the other way (dotted line).

• The constraints are piecewise linear.

Figure 1. Local performance function for the individual engineer.

190 C. LOCH ET AL.


Therefore, the engineer communicates informationabout his current design state to each of his peers afterexponentially distributed time intervals. These exponen-tial time intervals of communicating with each colleagueare independent of communication with other collea-gues, and independent of the decision points. We thusdescribe a situation where information is exchanged notonly at scheduled meetings, but also at randomoccasions, as we have explained above. For ease ofexposition, we set the mean of the communicationintervals equal to the mean of the problem solvingintervals (Mihm et al. [35] describe what happens inscenarios where information is indeed broadcast imme-diately).

3.3 Local and Global Optimization Behavior

The performance functions Pi form the basis for thecomponent engineers’ periodic design decisions. At oneextreme, an engineer i may care only about his localcomponent performance Pi (taking hj as given), com-pletely neglecting overall system performance. At theother extreme, the engineer may choose his action hi soas to maximize overall system performance P (againtaking hj as given). One may imagine situations whereengineers attempt to ‘‘second-guess’’ or forecast peer’sfuture actions. However, this is too complex to bepractical in most situations. For these two extremes wecreate two corresponding versions of the model.

The myopic decision maker optimizes the perfor-mance of his component Pi regardless of difficulties hemight inflict on his peers. The optimal choice of the localdecision variable h�i can be characterized as follows (fora proof, see Appendix):

hi ¼Xn

j 6¼ibijhj: 4ð Þ

This linear equation system has only one solution, [0]N

(reflecting our normalization assumption that all Pi inEquation (1) are anchored around zero). This is the onlyfixed point of the system with myopic engineers, inwhich none of them wants to change his design given thedecisions of the others (corresponding to a NashEquilibrium).

In contrast, an overall optimizing ‘‘cooperative’’engineer optimizes system performance, taking intoaccount the impact of his actions on other components.Thus, engineer i chooses his hi to maximize(P_{i}þ�j 6¼ iPj). Although the optimization process inour model involves nonlinear functions, it is possible tofind the optimal choice of hi by searching a well-definedset of candidates. The optimal choice is characterized inthe Appendix. A system with globally acting agents hasseveral fixed points, corresponding to the local perfor-mance peaks of the complex performance function.

This search model creates a multipeaked landscapesimilar to Kauffman’s NK model. Thus, the landscape iscomputationally intractable. However, our variables arecontinuous and our performance functions smooth,which makes the landscapes correlated for points in asmall neighborhood. This maps the situation in NPDbetter than the original NK ruggedness.

In summary, we have made three simplifying assump-tions in our model. The first two, symmetry and singlevariable component performance functions, are restric-tive, but bias the model toward simplicity and fewerinteractions. Real systems in practice are more complexand exhibit the phenomena described here even morestrongly than our model. We believe that our qualitativeconclusions are widely applicable in the design ofcomplex products.

The third assumption is that interactions are smoothand multiplicative (with an error function). In acompanion paper, we have tested piecewise linearinteractions and found that the system performs slightlybetter [35]. Finally, multiplicative interactions are thesimplest case. Exponential interactions would, again,make the system even more complex and nonlinear.

4. Analytical Results

The dynamics of nonlinear systems can generally notbe described in closed form [10]. Thus, most of ourmodel scenarios cannot be analytically treated. We haveto resort to simulation to analyze the dynamic problemsolving behavior. However, for a simple base case, wecan analytically characterize fundamental systemdynamics.

The behavior of a linear system can be described withthe eigenvectors of the system’s Jacobian matrix,Jij¼ @hi/@hj, with hi being the system state vector. Inthe special case where the engineers optimize their localperformance only, the Jacobian becomes an N�Nmatrix. If the decision maker jumps into the optimumright away (�¼ 1), the system becomes linear, and thematrix simplifies to constant elements Jij¼ bij, with zerodiagonal elements.

This Jacobian is asymmetric. Suppose that theinterdependence parameters bij, viewed over a largenumber of projects, are Gaussian random variables withmean 0 and variance �2. Then the ‘‘circular law’’ incontrol theory (see the Proposition in the Appendix),states that as the system size grows large, the largest realeigenvalue increases proportionally to the square root ofthe system size.

We prove in a Theorem in the Appendix that if thecircular law holds, the probability that the norm of itslargest eigenvector is larger than 1 increases with thematrix size N. Moreover, there is overwhelming evidencethat the circular law is valid not only for a Gaussian



distribution of the bij, but also for any distribution with�2>0 – a conjecture called Girko’s law. Moreover, ifthe off-diagonal elements of the Jacobian have nonzeromeans, the largest eigenvalue grows even faster, namelylinearly, with the system size.We have numerically calculated the distribution of the

norm of the largest eigenvalues (making the bijuniformly distributed over [�1,1]) for a sample of250,000 random matrices. The results show clearly thatthe probability of the largest eigenvalue exceeding 1increases from 0 for the 2-component system to 1 for the10-component system. The distribution of the largesteigenvector steadily shifts to the right as system sizeincreases.The above mentioned results have two implications

for the behavior of our NPD project. First, aneigenvector larger than 1 implies that the dynamics ofthe system are unstable: the system becomes less likely toconverge to a solution from which no decision makerthen deviates, but diverges with increasing probability.While all decision makers try to improve their localperformance, decisions become more and more ‘‘radi-cal’’ toward the extremes of the decision spaces,resulting in declining performance. Second, even forprojects that do converge, development times increasewith project size as the norm of the largest eigenvectorbecomes larger and larger.As mentioned, these analytical results strictly hold

only for specific cases to which most scenarios of ourmodel do not conform. In the following, we verify viasimulation that the suggested qualitative behavior doesgeneralize, and we examine the effects of variousmanagerial actions to mitigate the unstable problemsolving dynamics.

5. Simulation Results

In this section, we discuss the results of the computersimulation. We first analyze a base case, whichcorresponds to the simplified system in Section 4. Thebase case also serves as the point of reference for fourother scenarios. A detailed description of the simulationparameters, and robustness is shown in the Appendix.

5.1 Base Case: Uncooperative Agentswith Limited Bandwidth

In Section 3, we have outlined a 2� 2 design for oursimulation experiments: (i) global optimization (coop-eration) versus local optimization and (ii) full compo-nent optimization versus satisficing. In the base case, theassumptions are as follows: Component engineers actlocally. No one is willing to compromise his ‘‘local’’performance to help other components. Full componentoptimization. Engineers insist on excellence in their

profession and optimize their components as much asthey can, without consideration of whether this forcesothers to engage in additional design iterations. Theseassumptions are extreme, but not entirely unrealistic inpractice, where component engineers often take othercomponents into account only imperfectly [48], andwhere communication is often not instantaneous butdelayed.

The simulation results are reported in a standard formfor all model scenarios, as is shown in Figure 2. Theupper left panel displays the average time for thenetwork to settle at its fixed point (the final designdecision), given that it settles at all (this graph uses onlythose networks that do eventually converge). The resultsof the base case directly illustrate the analytical resultsfrom Section 4. The time for the system to settle at thedesign fixed point grows as a function of the networksize N. By changing their decision variables, agentschange the optimal decision for others and trigger achain reaction. The feedback (reciprocity of dependence)can cause small deviations from the optimal state to beamplified. In larger systems, the mutual adjustmentprocess involves more agents and thus becomes moredifficult.

The upper right panel shows the percentage ofnetworks that become ‘‘unstable’’. This fraction growswith network size and soon approaches 1. The reasonfor this lies, again, in the system feedback: designdecisions move in cycles as interdependent compo-nents keep changing. Instead of converging, designdecisions oscillate more and more and ultimatelydiverge.

Instability means that the design group does notreach an equilibrium in which no one wants to changehis decision variable unilaterally. The decisions‘‘diverge’’ toward extreme values with low perfor-mance. In reality, of course, teams do not deliver suchextreme solutions at the end. They recognize when thesolutions diverge and take one of two remedies: first,a team may stop and go back to a solid base solutionand restart optimization from there. In this case,instability in our model is interpreted as the need fora larger number of design restarts. Second, a teammay ‘‘freeze’’ a number of component designs at somereasonable value to prevent further iteration [50]. Inthis case, instability is interpreted as a lower solutionquality because more variables have to be frozen atsuboptimal values.

The lower left panel of Figure 2 shows a measure forthe number and size of problem solving revisions beforefinding a joint design solution. The number is computedaccording to:

m ¼1

S

XS

j¼0

PT�1t¼0 jhtþ1

j � htj j

hTj � h0j: 5ð Þ

192 C. LOCH ET AL.


Here, S is the network size, T the final time when thenetwork has converged, and hj

t the decision ofcomponent j at time t. The measure is 1 when the finaldecision is approached gradually, without overshootingor oscillating. If the measure m is greater than 1, thedecision makers have at least sometimes reversed theirdesign decisions.

The bottom right panel shows the ‘‘performance’’ ofthe network. This measure cannot be compared acrossdifferent network sizes N. As the constraints Iij arecombined multiplicatively, and all lie in the interval(0,1), each additional Iij lowers the maximal perfor-mance achievable. This panel is only relevant whencompared to the same network size in the othersimulation scenarios.

The simulation results (conversion time and stability)confirm the analytic results for the base case, establish-ing a reliable anchor point for the simulation. Theresults of this section are consistent with well-knownfindings from organization science literature (e.g.,[3,14,28,45]): It is not enough to transmit informationwithout errors and to everyone, the frequency (or‘‘channel capacity’’) must be sufficient. Our analysisshows that problem solving instability is a significantdanger when the project size gets large. The question

addressed below is whether immediate communication(that is, larger channel capacity) can eliminate thisproblem.

Subdivision of projects in order to reduce complexityhas been used in many industries for years. For example,software engineers have intuitively understood thisrelationship. Empirical studies show that the larger asoftware project, the higher its probability of failure [22].Therefore, a recent trend in software engineering hasbeen to cut down project size where a series of smallerprojects is implemented rather than trying to build alarge integrated system [38,58]. Figure 2 explains why amodularization strategy may be successful if immediatecommunication or system optimization are difficult toachieve.

An increase in the number of lines coded, along with aproportional increase in individual mistakes, usuallyimplies a much more than proportional increase in thetime taken to fix bugs. The reason for this is the mutualinterdependence of code segments. Removing a bug inone segment usually causes many adjustments in othersegments, either to ensure code validity or to ensureperformance. The seriousness of the problem increases ifthe code is not properly separated into smaller segments.In a similar way, the car industry uses modularization

Figure 2. System behavior with global optimization.



(platform design) [53]. With standard interfaces, thesubdivisions can be easily assembled into the finalsystem.One implication of this is that management must

think about the size of the projects it undertakes. Thenonlinear feedback interactions among interdependentcomponents govern the project completion time.Therefore, it may be important for the success of aproject to find a reasonable subdivision into largelyindependent subsystems which reduce the de factosystem size (of interdependent components). Designmodularization is an extreme example of finding suchsubdivisions. We now turn to the question of whetherthe nonlinear feedback can be eliminated by othermanagement actions.

5.2 Global Optimization: Cooperationamong Agents

In the base case, the component engineers do notcooperate but perform local optimization only. We nowcompare this ‘‘benchmark’’ to a situation where thedecision makers are willing to sacrifice their own localperformance on behalf of a larger performance increaseof another component. Each component engineer setshis design decision hi so as to maximize the sum of allcomponent performances (taking the other engineers’decisions as given). The second set of curves in Figure 2shows the results of the simulation for globallyoptimizing agents.The qualitative insights from the base case remain

valid: The probability of system instability, the time todesign conversion, overshooting, and iterations in thesearch process, all increase with system size. Thus,cooperation by itself cannot guarantee stability andproject success.However, cooperation dramatically improves system

behavior relative to the base case on all three dimen-sions. The benefit is amplified for larger networks. Thisresult is somewhat optimistic, because our model doesnot include the coordination costs of cooperation (suchas meeting times, or the time to read documentationallowing an engineer to understand trade-offs with othercomponents). However, the time gain caused by globalbehavior is dramatic, e.g., for the seven node case itamounts to 30%. It is unlikely that such a largeadvantage is neutralized by coordination costs.The third benefit from cooperation is a higher

performance achieved by globally oriented agents thanby locally acting agents. The latter converge to the fixedpoint (0N) – if they converge –, corresponding to thenormalized performance of the system in which allcomponents are myopically optimal. This design isgenerally not a system optimum, not even a local one.The decisions of cooperating agents, in contrast,converge to a local optimum centered around (0N).

Thus, the performance of the locally oriented decisionmakers is the probability distribution for a specificpoint, while the performance for the cooperatingdecision makers is characterized by the probabilitydistribution of at least a local maximum of theperformance function P. The performance differentialcannot be quantified as a percentage difference sincethere is no natural zero value on the scale for theperformance function in our model. However, thedifferences are statistically significant (see [34]).

Finally, cooperation limits the size and number ofiterations performed during the search process. Thismeans that the NPD-development process proceedsmore smoothly and is less prone to seemingly randomshifts in decisions and observed system performance.

In summary, these results highlight – in line withexisting literature – the usefulness of striving forcooperation among globally oriented decision makersduring the development process. However, even withfull global optimization, project duration, and instabil-ity still increase with project size. Thus, project size itselfstill emerges as important and must be managed.

5.3 Satisficing

In the previous section, we have seen the benefits oftaking into account the results of one’s design decisionson other system components. Another aspect of systemorientation of the engineers is the willingness to foregothe last bit of performance of one’s own component inthe interest of reducing system design time. This is (likeglobal behavior) not a trivial demand on engineers whoare used to emphasize their own specialized, functionallydefined, excellence and are asked to ‘‘compromise’’ thisexcellence in the interest of time.

In this scenario, we assume that the engineers willchange their design only if a minimum percentage ofimprovement can be achieved (taking the other compo-nent decisions as given). Otherwise, they leave thedesign unchanged. Mathematically, the condition for achange is

htþ1i 6¼ hti only if Piðh

tþ1i Þ � Piðh

tiÞ

� �� =PiðhtiÞ�� > k, 6ð Þ

where k indicates a percentage improvement hurdle,representing the level of satisficing. If k is high, the newsolution must be much better than the old for theengineer to adopt it. If k¼ 0, the base case results.

Figure 3 shows the system dynamics with a satisficingparameter k¼ 0.05. The improvement in the systemdynamics is striking: the system settles into the designfixed point faster, is less likely to diverge, and undergoesfewer iterations. At the same time, system performancedoes not drop.

A small performance compromise buys a signifi-cant reduction of oscillations and design time. The

194 C. LOCH ET AL.


explanation lies in the circular interactions: Sometimes,a change in component i shifts the optimum ofcomponent j only a little bit. If every engineer insistson full optimization, the circular changes may go on fora long time. But they are cut short if engineer j is willingto suffer a small performance loss. In a complex system,the effect may be very large.

Of course, satisficing can be exaggerated. We haveseen how a small performance compromise alreadyoffers large time gains. If the satisficing parameter k isfurther increased, system performance suffers progres-sively more, while the time gains quickly run intodecreasing returns. In addition, the engineers may be de-motivated by having to give up too much of theirfunctional pride.

We have examined a second satisficing scenario, inwhich the engineers behave globally (take decisions toimprove system performance, not component perfor-mance only), and satisfice. That is, an engineer changeshis solution only if the change offers at least a fraction kimprovement in system performance.

When engineers optimize globally, the effect ofsatisficing, both in terms of the speed benefit and theperformance cost, is much weaker than in the scenarioof local behavior (Figure 3). The reason is that global

behavior and satisficing are partial complements. First,the system is already more stable when agents takesystem performance into account, so the reduction ofcycles is less significant (and over-proportionally sobecause it pushes iterations further down on a convexincreasing curve). Second, more scope for improvementexists in the system performance function (includinginteraction effects) than in the component perfor-mance, so fewer solution changes are eliminated bythe satisficing restriction. On the other hand, thesystem performance suffers less than when locallyacting engineers satisfice (lower right panel): thesystem performance with satisficing is still above thebase case (where the engineers optimize their compo-nents fully).

5.4 Equivoque

An interesting negative side effect from improving thesearch dynamics arises in the form of equivoque, or theavailability of multiple plausible explanations ofobserved behavior [56]. When a search quickly ‘‘spirals’’toward extreme solutions, the team can interpret what isgoing on, and stop or restart. But as long as the searchoscillates around, the choice is not clear.

Figure 3. System evolution with local behavior and satisficing.



Figure 4 establishes a relationship between networksize and equivoque by plotting the percentage ofnetworks which have proven neither unstable norstable after 10,000 time units. The amount of equivocalnetworks first increases and then decreases with networksize. This is because at first, the average time tosettlement grows with the size of the network, but asthe system grows further, the ever-increasing instabilitypushes the solution to divergence quickly enough to beidentifiable by the team.It is very important for a team to understand that

design oscillations may occur (clinging to the hope ofa solution convergence, without ever freezing or arestarting), and what the interactions are that causechanges to propagate. If engineers have a localoutlook and cannot place changes in context, their‘sensemaking’ of what is happening in the project maybreak down [57].As a case in point, take an example that we have

reported in previous work [49]. The developmentengineer for the air intake of the climate controlsystem (CCS) in a car project had been constructing aparticular component for over a year, based on designassumptions (such as the available space) that had beenformally ‘‘frozen’’ in previous reviews. Subsequently, hehad to cope with a total of 18 engineering changes(ECs), many of them based on events beyond hishorizon, with no obvious logic. As a result, hissensemaking collapsed, leaving him in severe stress andhe took an extended sick leave (Weick [56] calls this acosmology episode). The more experienced engineersaccepted the need for late rework and understood thatthe company sold cars thanks to strong engines, notCCS systems. They were able to retain their creativitydespite the new circumstances and increased pressurecaused by design oscillations and late ECs. In contrast,

functional engineers who were used to working on CCScomponents only, found it difficult to accept thedisruptions and, instead of working around them,became defensive.

6. Discussion and Conclusion

We have presented a model of a complex concurrentengineering project in which each member makesrepeated local decisions about his component, while theoverall design evolves. This model captures the combina-tion of distributed decision making and componentinterdependence in determining system performance.Our results show how the overall system quickly becomescomplex and non-linear as it grows in size, even if allcomponents and their interactions are very simple. Thus,a rugged performance landscape [18] easily arises, inparticular when many activities are carried out in par-allel, as is the rule in concurrent engineering processes.

Our model highlights that the design problembecomes fundamentally more difficult to solve as itgrows, even if resources (people) are scaled up withsystem size: the evolving design tends to ‘‘oscillate’’through numerous design solutions before converging toa solution. As the problem size grows, the probability ofthe design ‘‘diverging’’ to something unreasonable (andthus having to be restarted) grows exponentially. Even ifit converges, the time to conversion also growsexponentially. This effect is fundamentally driven byproblem complexity, and cannot be eliminated, onlymitigated, by managerial actions.

This is consistent with results in engineering design,which have shown that even modern methods of systemdecomposition with component optimization lead toinstability and loss of design quality (e.g., [4]). These

Figure 4. System equivocality.

196 C. LOCH ET AL.


problems appear whenever the system performancefunction cannot be analyzed as a whole – clever methodscan exploit system structure, but never avoid the basicchallenge of complexity. Based on our model, we outlinewhat fundamental actions management can take to atleast mitigate oscillations.

1. Limit System Size. The most radical solution is toavoid large complex design problems altogether.Recent trends in the software industry have movedin this direction, favoring several small softwarepackages to one big one. Especially in radically newdesign situations, for which the organization has notyet developed experience, small project size isparamount.

2. Modularization and Robust Design Methods. Thesereduce the ‘‘effective’’ system size of fully interde-pendent components by making a part of the systemindependent of other parts. Outright modularization[53] as applied in the automotive industry (‘‘chunks’’)and software industries may have the side effect ofreducing the overall system performance as thedesign degrees of freedom are reduced (e.g., [54]).A more subtle method of reducing interdependenciesis robust design: through a clever definition of thesystem quality loss function and through orthogonaldesign experiments over the component designvariables, system interactions may be mitigated.However, this is applicable only late in the processwhen the design is already relatively stable, and onlyfor systems with a small number of components. Forlarge systems, an additive quality loss functioncan typically not be found, and the number ofexperiments required for robustness becomes toogreat [37, 50].

3. Cooperate: Optimize Overarching Chunks as a

System. There are major benefits in choosing acomponent-specific design decision with respect to itseffect on the overall system rather than on therespective components only. Of course, this may beimpossible in a real system of high complexity.However, it may be possible to capture part of thebenefit by (a) optimizing a major subsystem (ratherthan the single component), or (b) by establishing agood ‘‘direction’’ for a component change based on arough approximation of the overall system.

4. Satisfice: Allow Small Compromises in Component

Performance to Reduce Design Iterations. Driven bythe nonlinear deterioration in system convergence toa solution, a small compromise in componentperformance may buy a disproportionally largedesign iterations and time improvement. Satisficingis a partial substitute with global optimization (butthe latter is often not possible).

In addition to these findings, we have shown inrelated work [35] that it is useful to make all component

design information, even if it is preliminary, immediatelyavailable to all actors (to avoid inundation withinformation, actors may restrict attention to the high-est-impact interactions, provided the architecture of thesystem is clear). Also, a team may ignore certaininteractions to simplify the design process, at thetradeoff of reducing system performance. These mitigat-ing actions are most effective if combined; only then dothey truly counter the divergence and oscillationproblems of large system size at an acceptable systemperformance.

It is very important for engineering managers tounderstand the fundamental reasons for design oscilla-tions, and to know what is, in principle, the range ofcountermeasures. Otherwise, equivoque, a loss ofsensemaking, and serious frustration of personnel mayresult, as we have described in Section 5.4. Even if thebenefits of reducing oscillations cannot be preciselypredicted, it is better to know the entire toolbox than totake ad hoc countermeasures that may cause significantunanticipated side effects.

APPENDIX

The Appendix is available from the authors orelectronically on the CERA web site.

References

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

2. Allen, T.J. (1966). Studies of the Problem-solving Process inEngineering Design, IEEE Transactions on EngineeringManagement, EM-13(2): 72–83.

3. Allen, T.J. (1977). Managing the Flow of Technology,Cambridge, MA: MIT Press.

4. Alexandrov, N.M. and Kodiyalam, S. (1998). Initial Resultsof an MDO Method Evaluation Study, American Instituteof Aeronautics and Astronautics (AIAA) Report 98–4884.

5. Anderson, P. (1999). Complexity Theory and OrganizationScience, Organization Science, 10(3): 216–233.

6. Balachandra, R. and Friar, J.H. (1997). Factors for Successin R&D Projects and New Product Innovation: aContextual Framework, IEEE Transactions on EngineeringManagement, 44(3): 276–287.

7. Clark, K.B. (1989). Project Scope and Project Performance:The Effect of Parts Strategy and Supplier Involvementon Product Development, Management Science, 35(10):1247–1263.

8. Clark, K.B. and Fujimoto, T. (1991). Product DevelopmentPerformance, MA: HBS Press, Boston.

9. Cooper, R.G. and Kleinschmidt, E.J. (1994). Determinantsof Timeliness in Product Development, Journal of Productand Innovation Management, 11: 381–396.

10. Devaney, R.L. (1989). An Introduction to Chaotic Dynami-cal Systems, 2nd edn, Reading, MA: Addison-Wesley.



11. Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala,D.A. (1994). A Model-Based Method for OrganizingTasks in Product Development, Research in EngineeringDesign, 6(1): 1–13.

12. Eppinger, S.D. (1997). A Planning Method for Integrationof Large-scale Engineering Systems, InternationalConference on Engineering Design, Tampere.

13. Ewens, W. (1979). Mathematical Population Genetics, NewYork: Springer.

14. Galbraith, J.R. (1977). Organizational Design. Reading,MA: Addison-Wesley.

15. Griffin, A. (1997). The Effect of Project and ProcessCharacteristics on Product Development Cycle Time,Journal of Marketing Research, 10(1): 24–35.

16. Ha, A. and Porteus, E. (1995). Optimal Timing Reviews inthe Concurrent Design for Manufacturability,Management Science, 41(9): 1431–1447.

17. Huberman, B.A. and Glance, N.S. (1993). EvolutionaryGames and Computer Simulations, In: Proceedings of theNational Academy of the Sciences, 90: 7716–7718.

18. Kauffman, S.A. (1993). The Origins of Order, New York:Oxford University Press.

19. Kauffman, S.A., Macready, W. and Dickinson, E. (1994).Divide to Coordinate: Coevolutionary Problems Solving,Working Paper 94–06–031, The Santa Fe Institute.

20. Kessler, E.H. and Chakrabarti, A.K. (1996). InnovationSpeed: a Conceptual Model of Context, Antecedents, andOutcomes, Academy of Management Review, 21(4): 1143–1191.

21. Krishnan, V., Eppinger, S.D. and Whitney, D.E. (1997).A Model Based Framework to Overlap ProductDevelopment Activities, Management Science, 43(4):427–438.

22. Laudon, K.C. and Laudon, S.P. (1991). ManagementInformation Systems, 3rd edn, New York: McMillian.

23. Lehmann, N. and Sommers, H.J. (1991). EigenvalueStatistics of Random Real Matrices, Physical ReviewLetters, 67(8): 941–944.

24. Levinthal, D.A. (1997). Adaptation on RuggedLandscapes, Management Science, 43(7): 934–950.

25. Levinthal, D.A. and Warglien, M. (1999). LandscapeDesign: Designing for Local Action in Complex Worlds,Organization Science, 10(3): 342–357.

26. Levitt, R.E., Thomsen, J., Christiansen, T.R., Kunz, J.C.,Yan, J. and Nass, C. (1999). Simulating Project WorkProcesses and Organizations, Management Science, 45(11):1479–1495.

27. Lewontin, R.C. (1974). The Genetic Basis of EvolutionaryChange, New York: Columbia University Press.

28. Loch, C.H. and Terwiesch, C. (1998). Communication andUncertainty in Concurrent Engineering, ManagementScience, 44(8): 1032–1048.

29. Loch, C.H. and Terwiesch, C. (2000). ProductDevelopment and Concurrent Engineering, In:Swamidass, P.M. (ed.), Encyclopaedia of Production andManufacturing Management, pp. 567–575, Dordrecht:Kluwer.

30. Loch, C.H., Huberman, B.A. and Stout, S. (2000). StatusCompetition and Performance in Work Groups, Journal ofEconomic Behavior and Organization, 43: 35–55.

31. Loch, C.H., Terwiesch, C. and Thomke, S. (2001). Paralleland Sequential Testing of Design Alternatives,Management Science, 47(5): 663–678.

32. Marbert, V.A., Muth, J.F. and Schmenner, R.W. (1992).Collapsing New Product Development Times: Six CaseStudies, Journal of Product Innovation Management, 9:200–212.

33. McKelvey, B. (1999). Avoiding the ComplexityCatastrophe, Organization Science, 10(3): 294–321.

34. Mihm, J. (2002). Mastering NPD Complexity, Vallendar,WHU: Dissertation.

35. Mihm, J., Loch, C.H. and Huchzermeier, A. (2003).Problem Solving Oscillations in Complex EngineeringProjects, Management Science, 49: 718–732.

36. Morris, P.W.G. and Hugh, G.H. (1987). The Anatomy ofMajor Projects, Chichester: Wiley.

37. Phadke, M.S. (1989). Quality Engineering Using RobustDesign, Englewood Cliffs: Prentice Hall.

38. Reel, J.S. (1999). Critical Success Factors in SoftwareProjects, IEEE Software, 16(3): 18–23.

39. Rivkin, J.W. (2000). Imitation of Complex Strategies,Management Science, 46(6): 824–844.

40. Roemer, T.A., Ahmadi, R.H. and Wang, R.H. (2000).Time-cost Trade-offs in Overlapped ProductDevelopment, Operations Research, 48(6): 858–865.

41. Simon, H.A. (1969). The Sciences of the Artificial,Cambridge, MA: MIT Press.

42. Smith, R.P. and Eppinger, S.D. (1997). IdentifyingControlling Features of Engineering Design Iterations,Management Science, 43(3): 276–293.

43. Sobieszczanski-Sobieski, J., Agte, J.S. and Sandusky, R.R.(1998). Bi-level Integrated System Synthesis (BLISS),American Institute of Aeronautics and Astronautics(AIAA) Report NASA/TM-1998–208715.

44. Sommers, H.J., Crisanti, A., Sompolinsky, H. andStein, Y. (1988). Spectrum of Large Random AsymmetricMatrices, Physical Review Letters, 60(19): 1895–1898.

45. Sosa, M.E., Eppinger, S.D. and Rowles, C.M. (2000).Understanding the Effects of Product Architecture onTechnical Communication in Product DevelopmentOrganizations, Working Paper \#4130, MIT.

46. Steward, D.V. (1981). The Design Structure System : AMethod for Managing the Design of Complex Systems,IEEE Transactions on Engineering Management, 28(3):71–74.

47. Tatikonda, M.V. and Rosenthal, S.R. (2000). TechnologyNovelty, Project Complexity and Product DevelopmentProject Execution Success, IEEE Transactions onEngineering Management, 47(1): 74–87.

48. Terwiesch, C. and Loch, C.H. (1999). Measuring theEffectiveness of Overlapping Development Activities,Management Science, 45(4): 455–465.

49. Terwiesch, C., Loch, C.H. and De Meyer, A. (2002).Exchanging Preliminary Information in ConcurrentEngineering: Alternative Coordination Strategies,Organization Science, 13(4): 402–419.

50. Thomke, S.H. (1997). The Role of Flexibility inthe Development of New Products, Research Policy, 26:105–119.

51. Thomke, S.H. (1998). Managing Experimentation inthe Design of New Products, Management Science, 44(6):743–762.

52. Thompson, J. (1978). Organizations in Action, New York:McGraw Hill.

53. Ulrich, K.T. and Eppinger, S.D. (2000). Product Designand Development, 2nd edn, New York: McGraw Hill.

198 C. LOCH ET AL.


54. Ulrich, K.T. and Ellison, D.J. (1999). Holistic CustomerRequirements and the Design-select Decision,Management Science, 45(5): 641–658.

55. Victor, B. and Blackburn, R.S. (1987). Interdependence: anAlternative Conceptualization, Academy of ManagementReview, 12(3): 486–498.

56. Weick, K.E. (1990). Technology as Equivoque: SenseMaking in New Technologies, In: Goodman, P. (ed.),Technology and Organizations, pp. 1–44, San Francisco:Jossey Bass.

57. Weick, K.E. (1993). The Collapse of Sensemaking inOrganizations: the Mann Gulch Disaster, AdministrativeScience Quarterly, 38(4): 628–652.

58. Whiting, R. 1998. News Front: Development in Disarray,Software Magazine 18 (12): 20.

59. Whitney, D.E. (1990). Designing the Design Process,Research in Engineering Design, 2: 3–13.

Biographies

Jurgen Mihm

Jurgen Mihm is a PhDstudent at the Otto BeisheimGraduate School of Manage-ment in Vallendar, Germany,and works at the manage-ment consulting companyMcKinsey. His research focu-ses on the dynamics of organi-zational processes in R&D,strategy and R&D manage-ment. He holds a DiplomWirtschaftsing. degree in

electrical engineering and business administration fromthe Technical University Darmstadt.

Christoph Loch

Christoph Loch is Professorof Technology Managementat INSEAD. His researchrevolves around managementof the product innovation pro-cess, particularly technologystrategy, project selection, con-current engineering, and per-formance measurement. He isalso interested in status compe-tition in organizations. He isAssociate Editor of Manage-

ment Science and Operations Research, and SeniorEditor of MSOM and of Production and OperationsManagement.

Arnd Huchzermeier

Arnd Huchzermeier holdsthe Chair in ProductionManagement of the WHU inVallendar, Germany, and holdsa PhD in Operations Manage-ment from the WhartonSchool. His research interestsinclude real options in R&D,for nonstorable products andin global supply networks; aswell as coordination appro-aches between retailers and

manufacturers with focus on promotion planning.



concurrent engineering: research and applications · concurrent engineering: research and...

Documents