By Monica Nakamine
December 28, 2001
As part of the continuing series of on-line seminars that LFM-SDM has been hosting throughout the year, LFM-SDM Co-Director Steven Eppinger gave a webcast presentation on “Product Development Interaction Patterns” on October 19, 2001. Based on his research, Eppinger, who is also the co-director of MIT’s Center for Innovation and Product Development, General Motors LFM Professor of Management Science, and Professor of Engineering Systems, introduced three views of product development complexity:
“First, there is the product perspective where we think about the product as a system of components,” said Eppinger. “Then, there is the process perspective where we think of development as a set of activities or steps. Third is the organization where we consider the organization that is developing this product as a network of individuals and teams.”
Eppinger discovered, through his research, that there is a relationship between each of these perspectives and that the underlying problems within them are also connected.
“These decompositions are not independent; that is, the product decomposition may be similar or related to the organization decomposition, or the organizational units may have process assignments,” he said. “Decomposition defines architectures, which are patterns of interaction. Interactions are found within each of these perspectives. For example, in the product perspective, the interactions are between the components. In the process perspective, the interactions are across the tasks. Then, in the organization, the interactions are between the people who exchange information to do the work.”
Patterns of interaction may be simple or complex. Interactions limited to only each subsystem would be a simple architecture; interaction patterns with many linkages across the subsystems, groups, or work units represent more complex architectures. Eppinger went on to further discuss architectures that include interactions across the different perspectives – people within the organization affecting the process, or the process influencing the product, etc.
“Architectures could be simple or complex, and that is why we want to study them,” said Eppinger. “But what determines the complexity of this development challenge?”
Four possible metrics of complexity were discussed to address this question:
- Number of elements involved
- Certainty of elements
- Patterns of interaction
- Alignment of patterns
To exemplify the three perspectives, as well as the four metrics mentioned above, Eppinger used studies conducted through LFM-SDM research at Pratt & Whitney, Intel, and General Motors.
Product Example: Pratt & Whitney Jet Engine Development
Eppinger alluded to the Boeing 777 airplane, which utilizes the PW4098 engine produced by Pratt & Whitney. This jet engine has nine systems (i.e. fan, low and high pressure compressors, the burner diffuser, and so on). Systems themselves are fairly complex, and are further broken down by component. Using a matrix-based analytical method, Eppinger described how system decomposition for the engine was mapped out, and how density between and across the subsystems can be displayed.
Secondly, Eppinger pointed out that not all interfaces are known by the experts in advance. Unknown interfaces give rise to what he calls incidental interactions.
“Incidental doesn’t mean that they aren’t important, but they are not predictable.
“I recently did some work with GM in fuel cells,” said Eppinger. “It’s a new architecture and their model is sparse, meaning that there are few interactions. As we gain more experience [with the architecture], we learn and find out about more of these interactions and can characterize them as requirements, interactions, or constraints – and then we put them as marks on the matrix.
“As the system becomes more mature, that is, we have a lot of experience with it, we actually learn how to minimize certain interactions,” said Eppinger. “We can cluster the interactions that we want to build in, and eliminate the ones that we know we can’t deal with at all. Then we can define the system so that it’s more modular.”
Process Example: Intel Semiconductor Development
Eppinger continued his discussion with Intel as an example for the process perspective of product development, again, using a matrix diagram. Blocks on the chart represent planned iterations. This predictability helps the company to be proactive about the set of activities within a process. However, there are also unplanned iterations. When these happen, Intel calls them “failure modes of the development process” because they are learned from.
“It’s possible to capture the hundreds of information flows in a complex process in a way that is actually reliable enough to study it and learn how to improve the process,” said Eppinger. “We use risk management strategies to deal with failure modes that might happen. We hope they don’t happen and try to minimize the possibility. Or, if they do happen, we minimize their impact. One of Intel’s key ideas that they learned is to how to optimize their process to minimize the affect of these unplanned iterations.
“As these processes mature, the iterations become more plannable. Maybe we’ll be able to eliminate the unplanned iterations, or eliminate their effects, and can plan better product development processes. Not to say that they are less iterative, but they are more understood, thus, proactively managed.”
Organization Example: General Motors Engine Development
By studying the development of the small V-8 engine that was developed for a Chevrolet pickup truck and the Corvette, among other vehicles, Eppinger was able to study the pattern of interactions between teams. There were 22 teams involved for the V-8, each one assigned to a specific part of the engine – camshaft, cylinder head, engine block, etc.
“The idea that we can map out organizations in terms of interactions is an engineer’s perspective on organization design,” said Eppinger. “We clustered this set of interactions and essentially created an organizational design for GM. We are able to design organizations based on what we think is the tactical structure of the product. Organizations evolve over time, and I think this one will evolve to handle the inefficiencies of the process and the deficiencies of the team’s own skills.”
Comparing across three perspectives
After Eppinger described the types of interaction patterns that are visible within product, process and organizational models, he showed how the architectures can be compared across the three domains.
He explained how this is done using the Pratt & Whitney jet engine example. The product was decomposed into systems, subsystems, and components. Then the interfaces were documented across the components. Similarly, the development organization was broken down into teams assigned to each component. We can also document the interactions across these teams. The questions then are: Is the set of interactions the same in both domains? Does the product architecture determine the interactions across the teams? And, how similar are these patterns?
Eppinger believes that there is much we can learn by studying these patterns.
“We can actually predict the vast majority of team interactions just by studying the product architecture,” said Eppinger. “By asking component design experts about the interfaces with other components, we are able to predict fairly well the pattern of communications that happen in the organization.”
Eppinger also discovered that teams sometimes do not communicate even though they share design interfaces. Likewise, teams that don’t share interfaces will occasionally interact.
“Interaction patterns teach us something about the development process,” said Eppinger. “I believe we can make design processes better if we look at our development challenges in this way.”