|
Article Excerpt
1. Introduction
In the design of complex products (such as cars, aerospace systems, software, or industrial equipment), individual components are designed separately, but influence one another. Ongoing problem choices in other components make the requirements for a particular component inherently unstable (Alexander 1964, Thomke 1997). For example, Allen (1966) reported that in the design of aerospace subsystems, engineers' preferences for alternatives (their current guess of the "best solution") changed frequently and quickly, often back and forth and back again, as the design evolved. Moreover, it would have been virtually impossible to anticipate the final choice at the outset. Similarly, Terwiesch and Loch (1999) observed the engineering change (EC) management process in the final phase of the design of a car and found that ECs would "snowball" from one component to another, in some cases in cycles, causing long resolution times. What is the reason for this difficulty, and what can one do about it?
The design of such products is an example of a complex system (e.g., Gaibraith 1977, Thompson 1978, Kauffman 1993, Anderson 1999, Levinthal and Warglien 1999). Complex systems are characterized as "made up of a large number of parts that interact in nonsimple ways... [such that] given the properties of the parts and the laws of their interactions, it is not a trivial matter to infer the properties of the whole" (Simon 1969, P. 195). In particular, the performance properties of a complex system represent a "rugged landscape": Interactions among a multitude of decision variables weaken the correlation between the performance values of neighboring design choices. Thus, the highest performance peaks cannot be identified or found with local (incremental) search (Kauffman 1993, Levinthal 1997).
New products are typically designed in a distributed manner by a large number of designers who make many (at least partially) autonomous decisions on system components, yet strongly interact in their overall impact on system performance. The above described difficulty in designing such complex systems manifests itself in widespread performance problems--budget and schedule overruns, missed specifications (e.g., Morris and Hugh 1987, Terwiesch and Loch 1999, Tatikonda and Rosenthal 2000), and management frustration with "performance oscillations." One project manager observed: "Three months ago, we had a performance status that we now no more than match, after a lot of hard work."
This paper builds a mathematical model of a complex distributed design project. The model explicitly represents both local component decisions and component interactions in determining system performance. Our results offer three important insights. First, we show how easily a rugged performance landscape arises, even from simple components with single-peaked performance functions, if the components are interdependent. The system becomes highly nonlinear even if the interdependencies are (piecewise) linear.
Second, we characterize the dynamic behavior of the system, arising from the designers making successive local component decisions over time, taking into account the current status of the surrounding components. We analytically characterize a slightly simplified system, and we simulate the complete system to 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 system size, modularity, cooperation among designers and immediate communication, and exchanging preliminary information. Some of these have not received much attention nor been linked to the system's complexity.
In the remainder of this paper, a brief survey of relevant literature (??2) is followed by the development of the model (??3). Sections 4 and 5 describe the analytical and simulation results, while ??6 summarizes the implications and concludes.
2. Literature Review
Our research can be positioned in relation to three areas of literature: (1) Complexity theory, (2) new product development (NPD) process models, and (3) work on design iterations--model based and empirical.
Complexity theory derives macro behavior of systems (such as self-organized criticality and coevolution on the edge of chaos) from basic building blocks of interdependent agents interacting in a nonlinear manner (e.g., Anderson 1999). An influential contribution was the formal NK model of the dynamics of selective evolutionary processes, which has subsequently served as a basis for many applications in complexity theory (Kauffman 1993, Kauffman et al. 1994). In its basic form, the NK model defines a performance function of N binary variables whose individual fitness contribution to the overall system is dependent on K other elements nonlinearly.1 The higher the number N and K, the higher the number of peaks of the fitness landscape.
Levinthal (1997) applies the NK model to the dynamics of radical change and slow adaptation in organizations. Levinthal and Warglien (1999) use the NK metaphor to argue that it is management's foremost task to tune the fitness landscape that the individual intelligent stakeholders of the organization adapt to. Rivkin (2000) explains with a similar model why imitating complex strategies is much more difficult than simple strategies. Mckelvey (1999) applies a variant of the NK model to many coevolving (possibly competing) organizations, examining optimal levels of internal organizational complexity and the complexity of the interactions among the organizations. He arrives at the conclusion that internal complexity should be the same for all entities, a result which is not applicable to engineering projects. This entire literature stream focuses on organizational change and strategy, using complexity metaphors that are not valid at the micro level of iterations in NPD.
With the rise of the paradigm of concurrent engineering, the traditional view of sequential design has yielded to the insight that design is inherently iterative (e.g., Whitney 1990). The second area of literature comprises formal models that have developed this thought (e.g., Ha and Porteus 1995, Krishnan et al. 1997a, Roemer et al. 2000, Loch and Terwiesch 1998, Thomke 1998, Loch et al. 2001a). These models see iteration as exogenous and probabilistic. By devising an optimal scheme of concurrency, they implicitly define an optimal number of design iterations. They do not consider the source of iteration, the NPD search process in a network of interacting components. Our model makes network configuration, component interactions, and iteration endogenous.
The third area of literature uses the design structure matrix (DSM) to model iteration. The structure matrix is a dependence graph that allows differentiating independent task groups, which can be worked upon sequentially, from interdependent task groups, which must be processed simultaneously (Eppinger et al. 1994). For some cases, Eppinger et al. (1994) suggest that interconnections may be disregarded to simplify coordination. Our model explains why this is useful and allows an estimation of the design quality trade-off from doing so.
Smith and Eppinger (1997) use the eigenvalues and eigenvectors of a DSM based on reiteration probabilities to identify iteration cycles. While similar to our model in their focus on repeated iterations, Smith and Eppinger (1997) emphasize a different source of iterations-stochastic "trial and error" on the individual component design. Our model, in contrast, emphasizes that system interactions cause iterations even if each component finds its best design right away.
Related to this work is a research stream on engineering design optimization, which has developed methods to cut a complex problem intelligently into pieces and integrate them again (via constraints or cross-partial effects on the overall objective) in a way that does not sacrifice too much system design quality (e.g., Alexandrov and Kodiyalam 1998, Sobieszczanski-Sobieski et al. 1998).
On the empirical side, Balachandra and Friar (1997) (and similarly Kessler and Chakrabarti 1996) identified more than 70 different project success factors, but size- or complexity-related measures were not among them. Managing size and complexity of an NPD project has not received widespread attention in the empirical literature. The few papers that mention size or complexity describe phenomena consistent with our findings. Clark (1989, p. 1260) concludes that "bringing parts engineering in-house and adding work by doing more unique parts design adds more engineering hours than one would expect from the amount of the increased workload," and that "the impact of scope on lead time works through changes in the difficulty of coordination in the planning process." Griffin (1997) finds that decreasing project and product/project complexity can significantly reduce cycle time. Reel (1999) reports that the average project size in the software industry keeps shrinking and, as a result, the project failure rate declin es with it.
Finally, our study is related to computer agent models. In particular, Levitt et al. (1999, p. 1480) create a decision-support tool with the ambition to support "true organization engineering" (p. 1480). Their level of analysis is the individual task and the individual project team member. Their decision-support model aims at a high level of detail to draw conclusions for a specific project, not at the general search dynamics that are the center of our study.
3. Model Description
The NPD team consists of individual decision makers (or "engineers"), each working on his own task within the constraints of the architecture, collectively solving a distributed information processing problem (Thomke 1997). (2) The reader may picture a task as a "component," a basic building block of the project. A task is determined by functional requirements as well as by the product architecture. Each team member optimizes a "local" performance measure, specific to his component. But interdependence requires a communication process among the engineers when making successive design decisions on their respective components. At each decision point, the component engineer must consider the status of other components in the system. Interdependence may be caused by competition for space or by the exchange of forces, information, or material flows. Although it may be mitigated by modularity (Ulrich 1995) or robust design methods (Phadke 1989), it cannot be eliminated in complex products....
|
