Managing complex product development projects with design structure matrices and domain mapping matrices

Abstract

Complexity in product development (PD) projects can emanate from the product design, the development process, the development organization, the tools and technologies applied, the requirements to be met, and other domains. In each of these domains, complexity arises from the numerous elements and their multitude of relationships, such as between the components of the product being developed, between the activities to develop them, and among the people doing the activities. One approach to handing this complexity is to represent and analyze these domains’ design structures or architectures. The design structure matrix (DSM) has proved to be a very helpful tool for representing and analyzing the architecture of an individual system such as a product, process, or organization. Like many tools, the DSM has been applied in a variety of areas outside its original domain, as researchers and practitioners have sought to leverage its advantages. Along the way, however, its fundamental rules (such as being a square matrix) have been challenged. In this paper, we formalize an approach to using a domain mapping matrix (DMM) to compare two DSMs of different project domains. A DMM is a rectangular (m × n) matrix relating two DSMs, where m is the size of DSM₁ and n is the size of DSM₂. DMM analysis augments traditional DSM analyses. Our comparison of DSM and DMM approaches shows that DMM analysis offers several benefits. For example, it can help (1) capture the dynamics of PD, (2) show traceability of constraints across domains, (3) provide transparency between domains, (4) synchronize decisions across domains, (5) cross-verify domain models, (6) integrate a domain with the rest of a project or program, and (7) improve decision making among engineers and managers by providing a basis for communication and learning across domains.

Introduction

Complexity in product development (PD) projects stems from many sources. The product or service to be developed (the deliverable) may be complex in its function, form, integration, technology, etc. The work required to develop it is often complex in its number of activities, people, teams, and organizations involved and their relationships. These areas are interwoven, creating a number of complexities and uncertainties for managers. In our view, managers should focus on identifying, understanding, and reducing these product, process, and organizational uncertainties, among others, to add value.

Complexity can be identified and handled, and uncertainty reduced, by using a systematic approach to gathering, organizing, integrating, and analyzing the best information about a project. Models and tools that enable this also provide a basis for planning and learning [2], [3]. However, models must be based upon the latest and most accurate input information if they are to provide helpful output. Hence, trans-disciplinary or cross-functional teams are advocated to provide the collective expertise, information, and resources for effective model building and problem solving. However, such intensive interaction between people often causes conflicts because of variations in experience, knowledge, organizational or professional loyalty, understanding of the purpose and goals, and/or contradictory purposes and goals. Each project stakeholder has a different mental model of the project, assumptions about it, interpretations of realities, expectations, etc. A shared, codified model can test and align participants’ mental models through discussions and lead to joint understanding of the reality in PD projects. To coordinate agents effectively into teams in the dynamic environment of PD, within and across different domains as indicated above, our research explores the following idea: we must lay bare the assumptions about the nature of the desired result, the activities to get to it, and the organization that will do the work, and the logic by which these domains have been decomposed and integrated.

PD projects are dynamic ones in which different domains are interwoven and effective management requires understanding how they interrelate and influence each other. Fig. 1 illustrates some critical aspects of PD that dynamically relate to each other. Product specifications are a consequence of customer requirements as well as logistic and manufacturing system capabilities. It is an illusion that PD starts solely with customer requirements and ends in design of the product structure. In reality this process is like a web. Domains are interrelated and information is flowing back and forth between them. The crucial aspect here is to understand and explore dependencies and the need for information exchange between different domains of product architectures, organizations and processes.

The problem for managers is to find the appropriate way to organize people and assign work over time, enable communication, and synchronize actions. The implication of such a dynamic approach is that managers and engineers must understand and take into account interdependencies and relations, and the information that needs to be exchanged, not only within each domain but also across domains.

PD projects contain at least five different domains (Fig. 2): the product (or service, or result) system; the process system (and the work done to get the product system); the system organizing the people into departments, teams, groups, etc.; the system of tools, information technology-solutions, and equipment they use to do the work; and the system of goals, objectives, requirements, and constraints pertaining to all the systems. Each of these five systems is composed of elements with relationships and thus can be discussed in terms of its structure, network, and architecture—where architecture is defined, for example, as: “the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time” (IEEE STD 610.12). Moreover, each of the five systems is related to the others. Each system both enables and constrains the others.

An enterprise typically has multiple projects going on at once (represented by the layers in the Fig. 2), and there are strong incentives to achieve commonality in these five systems across projects. In multi-project situations, each project usually does not have full control over its organizational structure, product architecture, process structure, etc., since companies usually want some commonality in these across projects to provide economies of scale and scope and easy project comparison. For example, they want organizational commonality so that the employee evaluation and promotion process is similar, product commonality so that all of the company’s products have similar themes, process commonality so that standard processes can be used and people can be assigned to work on multiple projects without having to learn an entirely different process, tool (especially information technology) commonality to provide economies of scale in purchasing software and training employees, etc. In spite of all of these limitations, projects have to be coordinated in order to produce a complete result—a product, a service, etc. However, when a project fails, it is often because someone forgot to account for the effects of some of these systems and their implications. And this should not be surprising, because there is a tremendous amount of information to consider and manage. In multi-project situations it is crucial to examine interfaces between projects and their needs for information exchange [5], [6], [7], [8], [9], [10]. However, this is necessary in and across all of the domains. It is therefore essential to have a technique for examining the relationships between the elements of these systems.

In this paper, we compare two complementary, matrix-based approaches for representing, analyzing, and managing the crucial information regarding project domains and their interactions. The first, the design structure matrix (DSM), is a square matrix that has been used in a variety of product, process, and organization modelling applications over the last twenty years. We formalize the domain mapping matrix (DMM) as a second type of matrix-based approach, used to map between two different project domains. A DMM is a rectangular (m × n) matrix relating two DSMs, where m is the size of DSM₁ and n is the size of DSM₂. DMM analysis augments and adds insights to traditional DSM analyses. Our comparison of DSM and DMM approaches shows that DMM and DSM–DMM analyses offer a number of managerial insights and benefits.

The rest of this paper is organized as follows. Section 2 presents the DSM and DMM as two matrix-based tools for organizing the information that drives complexity within and across the five domains in PD. Section 3 compares and contrasts the DSM and DMM. Section 4 presents three example applications, Section 5 provides further discussion and insights, and Section 6 concludes the paper.