Are your Engineers Talking to Each Other When they Should?

Copyright ? 2007 Harvard Business School Publishing Corporation.Are Your Engineers Talking to Each Other When They Should?

by Manuel E. Sosa, Steven D. Eppinger and Craig M. Rowles

Companies that design complex, highly engineered products all have their horror stories. Ford and Bridgestone Firestone lost billions of dollars after their failure to coordinate the vehicle design of the Ford Explorer with the design of its tires. Similarly, Airbus’s development of the A380 “superjumbo” suffered major delays and cost overruns because of late emerging incompatibilities in the design of the electrical harnesses of various sections of the plane’s fuselage. These mistakes probably contributed to the loss of Airbus’s CEO and to important changes in the management of the A380 program.

What’s striking about these stories and many others like them is that in virtually every case, the people involved all agreed, in hindsight, that they could have avoided their expensive mistakes by making sure that the different teams responsible for developing the products’ components had communicated more effectively. Of course with complex development projects, you can never be certain that you have planned for every contingency. However, our experience shows that in the design phase of such projects, many companies would benefit from focusing sharply on the critical points of contact among their various component development teams to ensure that everyone knows when and with whom they should be sharing information.

This article helps managers mitigate this design communication problem. Drawing on detailed research into how Pratt & Whitney handled the development of its highest-thrust commercial jet engine—the PW4098, which powers the Boeing 777—we present a new application of an established project management tool: the design structure matrix (DSM). Our application helps managers identify where failures in planned communications could occur as well as recognize when project teams engage in unplanned technical communications. We also analyze communications between project teams that take place both within and outside the formal project structure. We conclude by discussing how managers should handle communications problems that are revealed in the process. While we do not pretend to offer a definitive solution to the design communication problem, we do believe that managers who use our tools over succeeding generations of products will improve the quality of their development processes.

Catching Missed Interfaces Before They Occur:

The first thing a project team does when faced with a complex development challenge is break the project down into manageable pieces that are then assigned to dedicated subteams. In the context of developing a product like a jet engine, this results in a large number of specialized cross-functional teams, each working on a different component or subsystem of the engine. Of course, these teams cannot work in isolation; in addition to designing their assigned components, they must also integrate their designs with those of the other components to ensure that the entire product or system functions as a whole. It is critical, therefore, in planning a complex product development process that the project managers specify just which resources and information different teams will need from each other at particular stages of the project.

In the Pratt & Whitney jet engine development project we studied, the engine was divided into eight subsystems, each of which was further decomposed into five to ten components, for a total of 54 engine components. Typical for such projects, the development organization was correspondingly structured into 54 cross-functional design teams responsible for each component, plus six integration teams responsible for managing engine-level requirements in areas such as fuel efficiency. These teams had to interact a lot: There were several hundred interfaces among the engine components, many of which would have experienced significant problems without proper communication among the relevant design teams.

To help manage the communications aspect of such projects, we propose the following approach: (a) identify unattended interfaces, areas where communication should be occurring but is not, and (b) look for unidentified interfaces, areas where communication is occurring but has not been planned. The result of implementing this approach is what we call an alignment matrix, which reveals mismatches between the communications and exchanges that are supposed to occur and those that actually do. It also demonstrates, therefore, how well the project has been planned and executed.

To see how the approach works, let’s suppose that we plan to develop a product with four components, each of which requires its own specialized design team. (This approach may be used when the organizational structure maps directly to the product architecture—that is, component X is designed by team X—which is the case in most of the complex development projects in the automobile and aerospace firms we have studied. For cases in which the organizational and product structures do not map directly, refer to M.E. Sosa’s “Aligning Process, Product, and Organizational Architectures in Software Development” in the Proceedings of the 14th International Conference in Engineering Design, Paris, August 2007.) Our analysis involves the following three steps:

1. Interview the system architects.

We begin by requiring the senior engineers responsible for the product’s overall function and layout—the system architects in engineering lingo—to identify the technical design interfaces among the four components. Do components need to be spatially connected with each other? Do some components transfer forces, material, energy, or information to other components to enable them to work properly? Answers to such questions are used to identify the interfaces among all the components of the product.

Armed with this data, the project managers can present the responses on a four-by-four design interface matrix (a type of DSM used to map the network of component interfaces), such as that illustrated in the exhibit “Assessing the Fit Between Design and Communication.”

Assessing the Fit Between Design and Communication (Located at the end of this article)

2. Survey the component design teams.

In the second step, we identify the technical communications that the people working on each component design team expect to take place with people from the other teams. Specifically, we ask members of each team whether they anticipate the need for technical information or resources from other teams. In surveying them, we need to make sure they are all familiar with the function and specifications of the component or components they are developing. (We do not share with them the matrix produced in the first step, as this would bias the teams’ responses.) Using these survey data, we can represent the technical interaction patterns of the teams in another four-by-four matrix (corresponding to the four design teams) that we call a team interaction matrix, also shown in the exhibit “Assessing the Fit Between Design and Communication.”

3. Combine the results.

In the third and final step, we overlay the two matrices to obtain the alignment matrix (again, see the exhibit “Assessing the Fit Between Design and Communication). This matrix shows the matches and mismatches between the product’s architecture as conceived by the system architects and the expectations of the teams involved in the product’s development. More important, it highlights the mismatches—when design interfaces have been identified but team interactions are not taking place (unattended interfaces) and when team interactions take place without a corresponding design interface being identified by system architects (unidentified interfaces). As we shall see, sometimes these unidentified interfaces turn out to be critical.

At the end of a project, managers can update the alignment matrix by redrawing the team interaction matrix based on more recent surveys in which component team members are asked to state where they actually received the information and resources they needed. Overlaying the new team interaction matrix on the original design interface matrix would reveal whether the mismatches uncovered at the start of the project had persisted and whether other mismatches had appeared. A postmortem of this kind yields valuable insights into future product development projects, especially for companies that expect to develop similar products in the future or further generations of the same product.

We conducted one such analysis of Pratt & Whitney’s development of the PW4098, the engine that, at the time, set new standards in the aviation industry for development speed and cost. (It was also the first commercial jet engine ever certified for 180-minute extended-range twin operations from its first day of service.) We began by interviewing the engine’s architects, who identified 569 interfaces among the 54 main components of the engine. Many of these interfaces were critical and complex because they not only involved physically adjacent components but also the transfer of material (air, fuel, or oil), energy (vibration or heat), structural forces, or signals used by the control system of the engine. The design interface matrix drawn from this information is shown in the exhibit “Creating an Alignment Matrix for Pratt & Whitney.” We then asked at least two members of each of the 54 teams involved in the project how often they received technical information from other teams during the detailed design phase of the project and how critical they perceived this information to be. The results of this survey documented 423 interactions among component teams, which appear on the team interaction matrix shown in the exhibit. We finally computed an alignment matrix by merging the two first matrices.

Creating an Alignment Matrix for Pratt & Whitney (Located at the end of this article)

Readers armed with a magnifying glass would count 220 unattended design interfaces that were not matched by team interactions and 74 unidentified interfaces in which teams exchanged technical information even though there was no identified design interface between the components. Although it would be naive to expect a perfect alignment of design interfaces and team interactions—and, in this case, many of the 220 unattended interfaces were unproblematic or not critical—misalignment on this scale indicates that Pratt & Whitney was subject to considerable risks involving cost overruns or other problems with this project.

Why Mismatches Occur:

Mismatches do not occur randomly in a product or organization. Rather, they are the result of product design and organizational factors. Planned key communication points may remain problematic for several reasons, including the presence of organizational boundaries (cross-boundary interfaces are more likely to be missed than interfaces with a team belonging to the same group), the lack of interface criticality (complex and critical interfaces receive more attention than noncritical ones), the use of indirect communication channels (teams sometimes pass technical information through other intermediary teams rather than interact directly), the presence of interface carryover (interfaces that have been defined in previous projects may not need to be reconfirmed in designing the new project), and the use of interface standardization (interfaces whose specifications have been formally documented are supposed to remain unchanged).

In the case of the Pratt &Whitney project, some mismatches occurred because component designs were carried over from previous designs. A number of components of the high-pressure compressor, for example, were virtually unchanged from a previous engine generation. As a result, some of the teams responsible for these components had to pay only marginal attention to coordinate their interfaces among themselves, though they still needed to coordinate with other highly redesigned components. Such inattention trickled over into their communications involving other highly designed components. In addition, many structural and thermal design interfaces were left unattended because they were noncritical or assumed to be standard. In many cases, these interfaces involved teams from different parts of the organization that had fewer opportunities for informal communications, which might have uncovered changes to the previous standards. The impact of these unattended interfaces probably resulted in very small reductions in performance or durability of affected components and systems. But given the 25- to 30-year life expectancy of a product like the PW4098, even small performance deviations could add up and cause significant warranty or service expense over the life of the product. For example, if a critical component like a turbine airfoil misses its life expectancy by only a few percent, it could mean one or more unplanned engine removals for maintenance over the life of the engine. For such a product, a single unplanned engine removal could add up to a $150,000 incremental cost to the customer.

Although most unattended interfaces are not critical, some are. Those critical unattended interfaces mostly occur when the teams involved come from different parts of the organization. The costs can be substantial. In the PW4098 project, two unattended interfaces turned out to be critical, and their costs varied with the time it took for problems associated with the interfaces to be uncovered and resolved. One related to a change in the structural loads transferred between rotating hardware assemblies in the high-pressure core and resulted in excessive loads on coupling hardware during tests of early development engines. Consequently, Pratt & Whitney had to disassemble, redesign, and rebuild the test engines. We estimate that this one problem added 1% to 2% to the cost of the program and a three- to four-month delay to certain elements of the program. The other unattended interface was uncovered later, after early production assembly had begun but before any engines were shipped. This one, also related to loads transferred between engine modules, reduced the life expectancy of one of the main engine bearings. The number of affected parts and engines was significantly greater than those associated with the first problem—and so was the impact on the program in terms of cost and time.

We have found unidentified interfaces to be less common than unattended interfaces. However, unlike unattended interfaces, their occurrence is almost always positive for the project because they reveal potentially critical but unanticipated interdependencies among a product’s parts or systems. Many of the unidentified interfaces we uncovered at Pratt & Whitney related to investigations into possible engine-level design problems that could have resulted in excessive strain, overheating, or insufficient pressure in the test engine. Because the teams involved talked to each other as they began to see or anticipate the unexpected problems, they were able to mitigate them before the product testing phase of the project, resulting in considerable time and cost savings potential. When unidentified interfaces like these are uncovered, the main question is whether to formally incorporate them into a project’s schedule and routines or leave them be. This decision depends largely on how critical the communication is. In the case of the interfaces described above, Pratt & Whitney formalized some of the relevant team interactions in planning the development of its next-generation engine.

The conditions that generate unidentified interfaces are different from those that cause people to overlook interfaces. Several of Pratt & Whitney’s unidentified interfaces occurred between teams working on engine-level design scenarios that created adverse structural or thermal loads. This, in turn, generated the need for technical solutions across distinct components. In one case, three teams from both the high-pressure turbine and the low-pressure turbine had to interact with teams working on the combustion chamber to optimize the thermal environment and resulting durability of their respective components. These were deemed critical interfaces that had not been identified by the system architects. Fortunately, the people on these teams had worked together in the same roles in previous projects, making it more likely that they would have unplanned exchanges of information.

How to Manage Mismatches:

Once the root causes of mismatches are understood, an organization can then decide how to deal with them. Potential solutions can be varied, including redrawing organizational lines, reassigning or creating new interface management responsibilities and facilitation tools, or even redesigning the system architecture (some of these are discussed below). To find the solution appropriate for your project, consider the following three steps:

1. Review organizational and system boundaries.

For projects in which a significant number of unattended interfaces span organizational boundaries, project managers should revisit their organizational structures. Doing so would probably have helped Airbus avoid the problems it encountered. The company based the organizational structure of its programs not only on the architecture of the plane but also on the share of work owned by the various partners of EADS (the European consortium to which Airbus belongs). The addition of this extra set of boundaries increased the likelihood of unattended interfaces occurring and reduced the likelihood of problem-solving unidentified interfaces taking place.

To change the organizational structure, though, may necessitate changing the system architecture, because that is what drives the organizational structure at most companies. Developing more-modular components that share fewer direct and indirect interfaces with other components in the product is especially helpful because technical communication in such projects is easier to manage than in projects requiring a great deal of component interaction. In the Pratt & Whitney project, teams responsible for designing more-modular components missed far fewer critical interfaces with teams from other components. There were fewer to be missed, and the workload associated with fewer direct and indirect interfaces was more predictable. Too much modularity, though, can lead to myopia, particularly at the subcomponent level. At Pratt & Whitney we found that the design teams of highly modularized subsystems were less likely to talk to teams working on other modularized subsystems than were teams working on more integrated subsystems. In going modular, therefore, product designers still need to pay careful attention to critical interfaces across those subsystems.

2. Form teams to handle mismanaged interfaces.

Managers also have the option to manage critical interfaces—to ensure that unidentified ones occur or that unattended ones are formalized—by assigning such work to the teams already tasked with the interaction or by making people on the involved teams formally and actively accountable for the interfaces. We would recommend this approach for managing identified interfaces across boundaries—the interfaces design teams are most likely to ignore.

Another way to handle missed interfaces—one that also avoids the need to significantly change the organizational structure—is to extend the responsibility of existing integration teams. Most large projects have such teams: At Pratt & Whitney there were six teams managing system issues like air and fuel efficiency, which affected the design of practically all engine components. Even though the management of team communications is not usually the primary function of integration teams, by the nature of their work, these teams communicate with almost all other teams in the organization. Accordingly, they are in a position to learn in real time about the status of critical interfaces during the design process and to bring unconnected teams together to handle critical interfaces that need special attention. These integration teams could be made responsible for flagging those critical interfaces that are not being properly attended to. In the PW4098 project, the secondary airflow team (one of the six integration teams) was responsible for managing the engine’s multiple internal thermal and pressure management systems to optimize engine aerodynamic performance and component durability. It regularly set up meetings and other communications between otherwise unconnected teams to address critical interfaces.

Unfortunately, most integration teams focus on milestone planning and resource allocation, paying only marginal attention to the quality of communication between component teams. That needs to change. Consider the pain that could have been avoided in the last phases of the development of the Airbus A380 if one of the integration teams had realized that the electrical harnesses team in Germany and its counterpart team in France, which were responsible for different sections of the fuselage, were not properly communicating about their design interface specifications.

3. Select appropriate communication support tools.

Many design teams miss interfaces because project planners haven’t thought through their use of communication tools and shared platforms. At Airbus, one of the main reasons for the communication breakdown between the A380 teams was the lack of compatibility between the computer-aided design (CAD) tools they used.

Being smarter about using communication tools doesn’t have to involve a lot of technology: Pratt & Whitney requires teams to regularly complete controlled interface documents and component requirements documents (specifications) to ensure that critical interfaces are identified and attended to. In cases where team members use technology to complete work, the various tools and platforms must be carefully integrated. In planning the development of the engine project that followed the PW4098, for example, Pratt & Whitney linked full engine aerodynamics and secondary air flow analytical models with component models to help the design teams manage their interfaces with the support of the integration teams. Specific people on each team were then tasked with tracking the impact of design changes across the component and system models and communicating those findings to their counterparts on other teams.

? ? ?

Our approach provides a systematic method for an organization to learn how and where it is exposed to the risk of communication failures between design teams working together to develop complex products. Moreover, an organization can use our tools to determine how changes in system architecture, or the emergence and removal of interfaces between system components, will affect its ability to avoid communication failures in the future. By using DSMs to document the architecture of the product for every generation of a product family, managers can identify key differences between old and new architectures. With the alignment matrix, managers create a compact and visual representation of interfaces and interactions that allows them to diagnose how their organization addresses design interfaces. Most important, the alignment matrix can help managers properly direct their efforts to align team interactions with design interfaces to prevent costly problems from occurring later in the product life cycle.