Exchanging Preliminary Information in Concurrent Engineering: Alternative Coordination Strategies

Successful application of concurrent development processes (concurrent engineering) requires tight coordination. To speed development, tasks often proceed in parallel by relying on preliminary information from other tasks, information that has not yet been finalized. This frequently causes substantial rework using as much as 50% of total engineering capacity. Previous studies have either described coordination as a complex social process, or have focused on the frequency, but not the content, of information exchanges. Through extensive fieldwork in a high-end German automotive manufacturer, we develop a framework of preliminary information that distinguishes information precision and information stability. Information precision refers to the accuracy of the information exchanged. Information stability defines the likelihood of changing a piece of information later in the process. This definition of preliminary information allows us to develop a time-dependent model for managing interdependent tasks, producing two alternative strategies: iterative and setbased coordination. We discuss the trade-offs in choosing a coordination strategy and how they change over time. This allows an organization to match its problem-solving strategy with the interdependence it faces. Set-based coordination requires an absence of ambiguity, and should be emphasized if either starvation costs or the cost of pursuing multiple design alternatives in parallel are low. Iterative coordination should be emphasized if the downstream task faces ambiguity, or if starvation costs are high and iteration (rework) costs are low. (Preliminary Information; Concurrent Engineering; Communication; Coordination; Problem-Solving Strategies; Product Development; Information Processing) Introduction Concurrent engineering, the practice of executing coupled development activities in parallel, has become the common mode of product development as time-to-market has gained in importance over the last 15 years (Takeuchi and Nonaka 1986, Wheelwright and Clark 1992, Krishnan and Ulrich 2001). Given tight project schedules, many engineers cannot afford to wait until all required information input is available, and have to start “in the dark,” requiring close coordination with other interdependent activities. Coordination among tightly coupled (interdependent) and parallel tasks forces parallel teams to share preliminary information about work in progress. Production tool orders have to be based on rough sketches of product designs, product concepts must be developed while uncertainty remains about the customer’s needs, and components must be specified while interacting systems are still under development. This kind of coordination often proceeds in an informal, ad hoc manner. It is hard to tell if the right information is being shared at the right time, as in the place of factual data (“the total vehicle mass is 3,126 pounds”); there is only vague preliminary data (“at present, we expect the vehicle mass to be around 3,000 pounds”). As one automotive executive put it, “Designing a car is much like building a house: you cannot afford to suspend the kitchen planning until you have put up the walls. But, if you start the kitchen planning too early, using preliminary floor plans from the architect, you are likely to do it twice. [. . .] We need a new way of exchanging information between the architect and the kitchen planner. Currently, our kitchen planner’s idea of concurrent engineering is that they should receive the floor plans as they did in the past, just six months earlier. They don’t understand that the nature of the information has changed!” C. TERWIESCH, C. H. LOCH, AND A. DE MEYER Exchanging Preliminary Information in Concurrent Engineering ORGANIZATION SCIENCE/Vol. 13, No. 4, July–August 2002 403 This highlights the two fundamental coordination problems addressed in this article. First, the uncertainty facing the kitchen planner with the floor plan may not necessarily arise from technologies or markets, but may be a consequence of the project manager’s decision to overlap (execute in parallel) two sequentially dependent activities. But how can the architect (upstream) inform the kitchen planner (downstream) that the information is only preliminary in nature? Second, we need to understand how the downstream party should use the preliminary information. If treated as final information, it is likely to lead to costly rework (if you plan the kitchen twice, you order a large appliance but end up not having the space to put it in). At the other extreme, not releasing any information until it has “converged” basically holds up the kitchen planning until the walls are up—an approach which avoids rework but sacrifices any time gains from parallel task execution. Coordination strategies outlined in the existing organizational literature have primarily focused on finding appropriate organizational structures to respond to uncertainty and interdependencies (Brown and Eisenhardt 1995). However, as most of these models have been static in nature (Adler 1995), they cannot fully capture the concept of concurrency, which is by definition time dependent. Prior studies have also left the concept of preliminary information itself undefined, despite numerous recommendations to define it (e.g., Clark and Fujimoto 1991). In the case of the kitchen planner, the existing literature would recommend forming a cross-functional team and engaging in frequent information exchanges. Although an important first step in dealing with uncertainty and interdependence, this fails to answer the fundamental question of what to communicate. The key questions when coordinating concurrent tasks are not how often to exchange information, but rather what information to exchange at what moment in time, and how to react to it. Moreover, preliminary information exchange, which results from the combination of interdependence and concurrency, is a time-dependent construct which is gradually finalized as upstream advances in its problem solving (or, if the uncertainty is caused by external events, as these events unfold). A model addressing this issue must be dynamic in nature. Theoretically our work extends a classical line of research on information exchange, uncertainty, and interdependence (e.g. Thompson 1967, Galbraith 1973) which has frequently been used as a theoretical foundation for the literature in the emerging field of new product development, such as Clark and Fujimoto (1991), Sobek et al. (1999), Krishnan et al. (1997), and Loch and Terwiesch (1998). More recently, detailed empirical studies of new product development projects have not only applied existing organizational theories, but successfully extended them (e.g. Adler 1995, Staudenmeyer 1999, Eisenhardt and Tabrizi 1995). In this article we present a qualitative study of an engineering project facing several situations of interdependence and concurrency, thus heavily dependent on preliminary information exchange. Using data collected from 10 engineering decisions traced on-site in a vehicle development project, we develop a dynamic model of coordination that hinges on the concept of preliminary information exchange. We study this exchange from three perspectives: that of the information-providing party, the information-receiving party, and of the system designer, as is reflected in our three research questions: •How does the information provider transmit preliminary information, and how is it revised over time? •How do downstream activities adjust to changes in the preliminary information received? •What trade-offs are relevant for downstream when using preliminary information, and specifically, can preliminary information be traded off against budget, time, or system performance? Based on these perspectives, we present a time-dependent model for coordinating interdependent tasks which in turn helps to define two alternative coordination strategies that we label iterative and set based. Second, we address the trade-offs faced by a development team in choosing a coordination strategy and how they change over time. This allows an organization to match its problem-solving strategy with the interdependence it faces. Relying on preliminary information too early can lead to rework in the form of costly iterations. Conversely, waiting for information to reach a desired level of certainty foregoes the time gains that come with parallel problem solving. We start by clarifying the theoretical problem of coordinating concurrent interdependent tasks and how it relates to existing literature in organizational theory and new product development. Secondly, we present our research methodology and a detailed description of the engineering decisions requiring coordination. Building on on-site observations, the three perspectives of preliminary information are presented. From this we derive the two coordination strategies and identify the managerial tradeoffs involved in choosing between them. Theoretical Problem and Literature Background Consider a very simple example of a development process where two activities are overlapped to reduce deC. TERWIESCH, C. H. LOCH, AND A. DE MEYER Exchanging Preliminary Information in Concurrent Engineering 404 ORGANIZATION SCIENCE/Vol. 13, No. 4, July–August 2002 Figure 1 Coordinating Parallel Activities Requires the Use of Preliminary Information velopment leadtime. The overlap allows the informationabsorbing downstream operation (e.g., stamping die development) to start before the information-supplying upstream activity (e.g., product design) is completed, thereby potentially reducing the overall cycle time due to concurrency benefits. In a fully sequential process (Figure 1, left), no information is released to downstream until upstream has gained full knowledge of its task. When downstream finally starts, it can rely on finalized information from upstream. This is symbolized by a formal release milestone in the process (the diamond shape in Figure 1) corresponding to the classical stage-gate model. Although the overlap creates a direct time gain by downstream starting early, it is not without drawbacks. Executing two activities concurrently (Figure 1, right) forces downstream to sacrifice quality of information and use preliminary information. If there is no concurrency, information can be exchanged in its final form. If there is no dependence, there is no need to exchange information. Thus preliminary information is the direct consequence of the interaction between task concurrency and dependence. Such preliminary information tends to be based on a low-to-medium level of upstream knowledge, symbolized by lighter shading in Figure 1. The earlier downstream starts, the higher the risk of future changes, especially if the outcome of the upstream activity is hard or impossible to predict. In this case, overlapping activities risk creating additional engineering effort in the form of rework (Stoy 1996). Rework can consume up to 50% of the engineering capacity and up to one-third of the development budget (Clark and Fujimoto 1991, Soderberg 1989). The well-known NPD process models (such as stagegate, waterfall, or evolutionary models known from engineering and software development, see, e.g., Cooper 1993 or Boehm 1981) show how uncertainty is resolved over time but do not address how to coordinate parallel activities. Within product development, Eastman (1980) was the first to discuss the benefits and dangers of committing engineering resources to nonfinal specifications. This work was further refined by Clark and Fujimoto’s (1991) studies in the automotive industry, specifically in the context of stamping die development. Taking an information-processing perspective, the authors identified intensive communication as a key driver of development performance. Instead of batching the information created by one activity and handing it on to the next, it was found to be more effective to release preliminary information early and let downstream use it to start in parallel. Although this line of research has substantially improved current understanding of development processes, looking at communication frequency and organizational structures alone cannot fully resolve the managerial challenges of dealing with preliminary information. Indeed, most companies have implemented many aspects of cross-functional integration over the last decade. In contrast with the large volume of literature on communication frequency, little work has been done on the format and timing of the information exchange. This is consistent with Scrivener et al. (2000), who emphasize the importance of what is communicated, as opposed to the media used or the frequency of the exchange. Unlike Scrivener et al., our focus is on need for information exchange, not on the mechanisms and media used to exchange it. Needs for information content are media independent (Scrivener et al. 2000, p. 349). Allen (1977) observed that communication changes over the course of a project, both literature research and personal advice, decrease over time, although the latter surges again toward the end due to interface problems. Since this study, the dynamic nature of the interdependence resulting from task concurrency has been neglected with the exception of Adler (1995), who points out that uncertainty and interdependence can dynamically change in the course of a project. We extend Adler’s work by looking at situations of interdependence and concurrency, adding a further level of complexity. Our research seeks an operational definition of preliminary information, needed not just from an academic standpoint, but also, as the initial kitchen example illustrates, for effective information exchange in practice. Secondly, it explores how downstream reacts to preliminary information. This implies the presence of costs and trade-offs, which is the third area explored. Research Methodology The automotive industry is a natural candidate for research on the coordination of concurrent activities: Car C. TERWIESCH, C. H. LOCH, AND A. DE MEYER Exchanging Preliminary Information in Concurrent Engineering ORGANIZATION SCIENCE/Vol. 13, No. 4, July–August 2002 405 development projects combine novelty with complexity (and thus task interdependence), and use task concurrency widely, thereby creating the coordination problem that interests us. Moreover, previous studies of concurrent engineering in this industry allow results to be compared (e.g., Clark and Fujimoto 1991, Cusumano and Nobeoka 1998). Task concurrency is, of course, used in other industries, such as electronics (Terwiesch and Loch 1999b), airplane design (Sabbagh 1996), and film making (Trip 1997). Our effort to extend previous research on preliminary information started with a visit to our host company, where we presented results from our own modeling (Loch and Terwiesch 1998) and survey-based (Terwiesch and Loch 1999b) research. While the audience did not disagree with any of the arguments presented, including the need for greater concurrency and for frequent information exchange between parties working concurrently, they cited other problems, including the introductory quotation. At a follow-up meeting, we agreed to explore preliminary information further and defined specific research objectives (similar to those presented in the previous section). Research Site We decided to focus on the climate control system (CCS) of a new vehicle under development. We narrowed our focus to one subsystem rather than the overall vehicle, as field-based research (see data collection methods below) required an in-depth observation of how engineering decisions evolved over time and how engineers exchange preliminary information. By examining such a “microcosm” we could interview all the engineers involved with the actual CCS design including its interfaces (about 40 individuals). A detailed system overview of the CCS is provided in Figure 2. The CCS contains all components and development activities related to the passenger’s climate environment, including air ventilation, air cleaning, warm up, and cool down. It was chosen over other subsystems because of the strong need for coordination and information exchange. Referring to the air intake of the car (part of the CCS), one interviewee explained: “Here at the air-intake you find all the problems we have in the development of new vehicles: coordination with other components (e.g., fire-wall, engine) and information release to tooling.” Together with the dashboard, the CCS is the subsystem with the most interfaces to other activities. Selected Cases The unit of analysis in our study is the exchange between an information-supplying upstream activity and an information-receiving downstream activity. Given our research focus, we are only interested in cases where downstream starts its work at a point before upstream has finalized its problem solving. With the help of the host company, we identified 10 such cases within the scope of the CCS, each relating to different components. For each case, we focused on one piece of information that fulfilled two criteria. First, the information had to move, over the course of our observation, from an initial estimate to a finalized design decision. Second, it had to relate to an important interdependence, thereby causing substantial rework downstream if not transmitted to the receiver. We then identified the sender (upstream) who had to forward this information to a receiver (downstream) prior to completing its problem solving. Thus, the communication dyad faced a situation similar to that described in Figure 1. Data Collection Data collection was performed over four months, during which the first author stayed on-site full time. This permanent presence enabled us to monitor the evolution of information and gain access to data sources usually closed to outsiders. Data were collected from multiple sources, including interviews, participation in relevant meetings, and internal project management information systems. About 100 semistructured interviews were conducted with 40 engineers and management, including upstream (information-sending) and downstream (informationreceiving) parties for every component. Initial individual interviews lasted from one to two hours. Subsequently, one to three follow-up interviews lasting between 15 and 45 minutes helped to capture what had happened since the previous interview. We passively participated in all relevant meetings on the 10 components. A typical week included five meetings (for all components together). About two-thirds of them occurred on a routine basis (e.g., every Tuesday afternoon). All meetings were cross-functional and, in most cases, included an outside supplier. They were held on the company’s development campus, either in conference rooms or the prototyping lab. In addition to those related to CCS development, we also participated in weekly package meetings on overall vehicle development, where space allocation among various modules was discussed. Each component was owned by one engineer, who had to coordinate with engineers of interacting components (for example at the package meetings) or manufacturing engineers (including suppliers), and get approval for changes from the CCS project manager. Problem solving in our host organization was supported by a number of information systems. In addition C. TERWIESCH, C. H. LOCH, AND A. DE MEYER Exchanging Preliminary Information in Concurrent Engineering 406 ORGANIZATION SCIENCE/Vol. 13, No. 4, July–August 2002 Figure 2 System Structure of the CCS to the CAD system, the most important systems for our research were an engineering change management system and a quality control list. The engineering change management system provided a database of all ongoing engineering changes and the anticipated cost and time delay associated with each one. The quality control list provided project management with a database of detected development problems still to be resolved, rather like a big “to do” list. Each open problem was assigned an evaluation of the risk it posed for the overall development process, a responsible engineer, and the next steps to be taken. Both systems were invaluable in that they allowed us to generate data and identify new leads for additional interviews. We followed the evolution of specific design decisions and their corresponding engineering changes over time. Following the paradigm of grounded research (Miles and Huberman 1984, Eisenhardt 1989), our analysis built on detailed field notes—interview notes, transcripts of engineering meetings, and company documents—compiled into detailed case studies for each engineering decision. This process was more iterative than sequential as the emerging cases were frequently updated after follow-up discussions with respondents. This included two rounds C. TERWIESCH, C. H. LOCH, AND A. DE MEYER Exchanging Preliminary Information in Concurrent Engineering ORGANIZATION SCIENCE/Vol. 13, No. 4, July–August 2002 407 of final presentations to engineers involved in the study as well as to the senior managers who had given us the go-ahead. Based on the cases, we contrasted various paths of information evolution, as described below. Technical Characteristics of the Five Engineering Problems Below we provide a detailed description of five of the 10 design decisions, as summarized in Table 1, beginning with the context of the information exchange, including sender, receiver, and content. The five cases are representative of the range of issues encountered and allow a thorough description of the information exchanged, the situation of the informationsending party, and the consequences for the informationreceiving party. They help to convey some of the richness and complexity of CCS development and show how our framework for preliminary information is grounded in the data collected. Much of the thermal energy used for heating the passenger cabin is supplied by the engine, the remainder coming from auxiliary heaters. Crucial information to the development of the CCS is thus the amount of warm water supplied by the engine. This is not fully available before engine development is finalized. Engine development supplies preliminary information about the volume of warm water per second to CCS development, which then uses a rough estimate to determine its approach to auxiliary heating. The geometry of the air-intake/filtering system is highly dependent on the engine geometry. Packaging space between engine, fire wall, and dashboard is extremely limited, requiring careful management of geometrical dependencies. This is particularly relevant for air flows as the amount of fresh air entering the cabin is a function of this geometry. An innovative feature of the CCS is a latent heat storage system (LHSS). Once the engine is running at its operating temperature, the LHSS can chemically store its heat for up to several days. This can be used to rapidly warm up the engine and passenger cabin the next time the car is started. At the time of our study, the LHSS was a highly innovative component with unproven demand, and management was not sure whether to include it. Given its substantial size, packaging the LHSS into the vehicle is a rather difficult task which completely changes the layout of the engine compartment. In this case, uncertainty and the associated preliminary nature of the information stemmed from the external market rather than the overlap of activities. Cars in general, and the CCS in particular, are increasingly sophisticated in their functionality. The CCS contains a substantial amount of software controlling dozens of precision motors, fans, and pumps to create a comfortable cabin environment. Software development depends on testing results from CCS prototyping in order to fine-tune the control system. The fire wall of the car is a solid metal sheet separating the passenger cabin from the engine compartment. It is a key component in providing body stiffness, but at the same time must have many holes to allow air and water from the engine compartment to enter the cabin, rather like a “Swiss cheese.” The positions of the holes are important pieces of information, as they provide the interface between fire-wall development/stiffness, climate control, and stamping die development for the car body. The Exchange of Preliminary Information from Three Perspectives To derive our two coordination strategies and the tradeoff between them, we first need to describe how preliminary information is exchanged. The description takes three perspectives: the format of the information as transferred by upstream, the downstream adjustment costs to changes, and possible substitutes for preliminary information that may be better overall. Format of the Information Passed from Upstream to Downstream The five cases share the same problem: A downstream development activity has to start with preliminary information from an upstream activity. For each of the five cases we describe in what format the preliminary information was passed on, how this uncertainty was resolved over time, and what format the final information took. The information needed for an auxiliary heating concept is the amount of water supplied by the engine. This information can be captured in a single number. While the first information transfer from the engine group occurred in the form of a number, there was a tacit agreement that this number should be understood more as an interval. This corresponds to the Krishnan et al. (1997) set-based framework, with the uncertainty being resolved in the form of an interval narrowed down over a series of engine tests. The information required for the package coordination between engine and air intake is more complex. The interface is defined not by a single number but through a complex three-dimensional geometric structure that evolves with the development of the engine. Not all this information is relevant for constructing the air intake— for the development of the air intake/filter box, the geometric details within the engine are of little importance— but the hull of the engine heavily influences the design C. TERWIESCH, C. H. LOCH, AND A. DE MEYER Exchanging Preliminary Information in Concurrent Engineering 408 ORGANIZATION SCIENCE/Vol. 13, No. 4, July–August 2002 Table 1 Summary of the Five Cases Case Information Piece Sender Receiver