Systems engineering of products, processes, and organizations requires tools and techniques for system decomposition and integration. A design structure matrix (DSM) provides a simple, compact, and visual representation of a complex system that supports innovative solutions to decomposition and integration problems. The advantages of DSMs vis-à-vis alternative system representation and analysis techniques have led to their increasing use in a variety of contexts, including product development, project planning, project management, systems engineering, and organization design. This paper reviews two types of DSMs, static and time-based DSMs, and four DSM applications: 1) Component-Based or Architecture DSM, useful for modeling system component relationships and facilitating appropriate architectural decomposition strategies; 2) Team-Based or Organization DSM, beneficial for designing integrated organization structures that account for team interactions; 3) Activity-Based or Schedule DSM, advantageous for modeling the information flow among process activities; and 4) Parameter-Based (or low-level schedule) DSM, effective for integrating low-level design processes based on physical design parameter relationships. A discussion of each application is accompanied by an industrial example. The review leads to conclusions regarding the benefits of DSMs in practice and barriers to their use. The paper also discusses research directions and new DSM applications, both of which may be approached with a perspective on the four types of DSMs and their relationships.

The design structure matrix (DSM) is a powerful tool for visualizing, analyzing, innovating, and improving systems, including product architectures, organizational structures, and process flows. Akin to a traditional N 2 chart and the System-System matrix (SV-3) in the DoD Architecture Framework (DoDAF), the DSM is a square matrix showing relationships between system elements. These elements can be components, teams, activities, or others. By analyzing the DSM, one can prescribe a better (e.g., more modular) system architecture. Adding a time-basis enables one to prescribe a faster, lower-risk process. Because the DSM highlights process feedbacks, it helps identify iterations and rework loops-key drivers of cost and schedule risk. The DSM is concise and visually appealing and is used in many organizations across diverse industries. Over the past decade the DSM has gained popularity. Users have found the tool extremely useful for fostering architectural innovation and enabling the situation awareness and empowerment that motivates the people executing complex processes. This tutorial introduces the DSM and three distinctive applications useful to product developers, systems engineers, and project and program managers. Real-life examples are presented from the aerospace, automotive, semiconductor, and other industries. Participants will engage in hands-on exercises and come away with a clearer understanding of the drivers of some critical, emergent behaviors in systems.

Abstract-To gain competitive leverage, firms that design and develop complex products seek to increase the efficiency and predictability of their development processes. Process improvement is facilitated by the development and use of models that account for and illuminate important characteristics of the process. Iteration is a fundamental but often unaddressed feature of product development (PD) processes. Its impact is mediated by the architecture of a process, i.e., its constituent activities and their interactions. This paper integrates several important characteristics of PD processes into a single model, highlighting the effects of varying process architecture. The PD process is modeled as a network of activities that exchange deliverables. Each activity has an uncertain duration and cost, an improvement curve, and risks of rework based on changes in its inputs. A work policy governs the timing of activity execution and deliverable exchange (and thus the amount of activity concurrency). The model is analyzed via simulation, which outputs sample cost and schedule outcome distributions. Varying the process architecture input varies the output distributions. Each distribution is used with a target and an impact function to determine a risk factor. Alternative process architectures are compared, revealing opportunities to trade cost and schedule risk. Example results and applications are shown for an industrial process, the preliminary design of an uninhabited combat aerial vehicle. The model yields and reinforces several managerial insights, including: how rework cascades through a PD process, trading off cost and schedule risk, interface criticality, and occasions for iterative overlapping.Index Terms-Activity network, budgeting, cycle time, design iteration, design structure matrix, engineering design management, process architecture, process modeling, process structure, product development, rework, risk management.

A central tenet in the theory of lean production is that the implementation of lean practices will reduce waste and thereby decrease costs. However, not all lean implementations have produced such results. Apparently, this effect is moderated by several factors, potentially even to the point of reversal. It is important to increase our understanding of how this might occur. In this paper, we explore how novelty, complexity, instability, and buffering affect the relationship between lean implementation and production costs. An interest in these factors drew us to study the case of Lockheed Martin's production system for the F‐22, an extremely complex and innovative product. To build theory, we synthesize our empirical data from the case with other existing theory, such as theories of learning and complexity. Through this analysis, we develop a revised framework that reconceptualizes the effect of lean on production costs and use it to develop 11 propositions to direct further research. Included among these are propositions about how the timing, scale, and extent of lean implementation can regulate the benefits of lean. Furthermore, when the objective of lean is construed as the provision of value, we propose that this value is an emergent property of a complex process, different from the mere sum of the values provided by its constituent tasks. Therefore, the elimination of tasks will not guarantee cost reduction, and lean may provide even greater value by incorporating some aspects of agile manufacturing. Overall, we develop a fuller range of the effects of lean practices on production costs and illuminate how operations managers might control key variables to draw greater benefits from lean implementation.

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 1 and n is the size of DSM 2 . 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.