TABLE OF CONTENTS

1. Getting Started with Design Structure Matrices
   
2. Types of Design Structure Matrices
   
3. Simplified Methods of Analysis
   
4. DSM Simulation
   
5. Advanced Topics
   
6. References and Web Resources
   

WHAT IS A DESIGN STRUCTURE MATRIX (DSM)?

A design structure matrix (DSM) is a compact, matrix representation of a system or project. The matrix contains a list of all constituent subsystems/activities and the corresponding information exchange and dependency patterns (i.e., what information pieces (parameters) are required to start a certain activity and where does the information generated by the activity feed into).

1. As a systems analysis tool, DSMs provide a compact and clear representation of a complex system and a capture method for the interactions, interdependencies, interfaces between system elements (i.e. sub-systems and modules).

2. As a project management tools, DSMs provide a project representation that allows for feedback and cyclic task dependencies. This is extremely important since most engineering applications exhibit such a cyclic property. This DSM project representation results in an improved and more realistic execution schedule for the corresponding design activities.

A LITTLE BIT OF HISTORY

The use of matrices in system modeling can be traced back to Warfield in the 70s and Steward in the 80s. However, it is not until the 1990s that the method received attention and wide spread. Much of the credit in its current popularity is accredited to MIT's research in the design process modeling arena.

Earlier works started with the use of graphs for system modeling. For example, consider a system that is composed of two elements (or sub-systems): element "A" and element "B". [The two elements  are assumed to completely describe the system and characterize its behavior]. A graph may be developed to represent this system pictorially. The system graph is constructed by allowing a vertex/node on the graph to represent a system element and an edge joining two nodes to represent the relationship between two system elements. The directionality of influence from one element to another is captured by an arrow instead of a simple link. The resultant graph is called a directed graph or simply a digraph.

The use of matrices in system modeling can be traced The matrix representation of a digraph (i.e. directed graph) is a binary (i.e., a matrix populated with only zeros and ones) square (i.e. a matrix with equal number of rows and columns) matrix with m rows and columns, and n non-zero elements, where m is the number of nodes and n is the number of edges in the digraph. The matrix layout is as follows: the system elements names are placed down the side of the matrix as row headings and across the top as column headings in the same order. If there exists an edge from node i to node j, then the value of element ij (column i, row j) is unity (or marked with an X). Otherwise, the value of the element is zero (or left empty). In the binary matrix representation of a system, the diagonal elements of the matrix do not have any interpretation in describing the system, so they are usually either left empty or blacked out.

KEY BENEFITS OF DSM

In a nut shell, binary matrices for system modeling are useful in systems modeling because they can represent the presence or absence of a relationship between pairs of elements of a system. A major advantage of the matrix representation over the digraph is in its compactness and  ability to provide a systematic mapping among system elements that is clear and easy to read regardless of size.

If the system is a project represented by a set of tasks to be performed, then off-diagonal marks in a single row of the DSM represent all of the tasks whose output is required to perform the task corresponding to that row. Similarly, reading down a specific column reveals which task receives information from the task corresponding to that column. Marks below the diagonal represent forward information transfer to later (i.e. downstream) tasks. This kind of mark is called forward mark or forward information link. Marks above the diagonal depict information fed back to earlier listed tasks (i.e. feedback mark) and indicate that an upstream task is dependent on a downstream task.

There are three basic building blocks for describing the relationship amongst system elements: parallel (or concurrent), sequential (or dependent) and coupled (or interdependent).

Three Configurations that Characterize a System
Relationship	Parallel	Sequential	Coupled
Graph Representation
DSM Representation	A B A      B	A B A      B X	A B A   X B X

Points to note are as follows:

• In the parallel configuration, the system elements do not interact with each other. Understanding the behavior of the individual elements allow us to completely understand the behavior of the system. If the system is a project, then system elements would be project tasks to be performed. As such, activity B is said to be independent of activity A and no information exchange is required between the two activities.

• In the sequential configuration, one element influences the behavior or decision of another element is a uni-directional fashion. That is, the design parameters of system element B are selected based on the system element A design parameters. Again, in terms of project tasks, task A has to be performed first before task B can start.

• In the coupled system, the flow of influence or information is intertwined: element A influences B and element B influences A. This would occur if parameter A could not be determined (with certainty) without first knowing parameter B and B could not be determined without knowing A. This cyclic dependency is called "Circuits" or "Information Cycles"

READING THE DSM

The DSM provide insights about how to manage a complex system/project and hilights issues of information needs and requirements, task sequencing, and iterations. A sample DSM is shown below:

The X marks indicate the existence and direction of information flow (or a dependency in a general sense) from one activity in the project (i.e. matrix) to another. Reading across a row reveals the input/dependency flows by an X mark placed at the intersection of that row with the column that bears the name of the input task. Reading across a column reveals the output information flows from that activity to other activities by placing an X in a similar manner described above. For example, consider activity C in the above matrix. Activity C relies on information from activities A and B and delivers information to activities D, E, F and G.

The green marks (below the diagonal) represent forward flow of information. The red marks (above the diagonal) are of special significance. Such a mark reveal a feedback from a later (i.e. downstream) activity to an earlier (i.e. upstream) one. This means that the earlier activity has to be repeated in light of the late arrival of new information.

This iterative process in common in most engineering design and development projects. Design iterations create rework and require extra comunication and negotiation which result in a prolonged development process. In order to speed up this iterative design process, the DSM methodology suggests the manipulation of the matrix elements such that iterative behavior is removed from the matrix, or at least minimized (a process called partitioning -- see details below.

It is worth noting that some DSM researchers and practitioners use an opposite convention for the feedforward and feedback marks, as discussed above. That is, the DSM can be built in such a way that sub-diagonal marks represent feedback (MIT DSM Lab).

Design structure matrices can be used to represent four different types of data:

COMPONENT-BASED DESIGN MATRICES

A component-based DSM documents interactions between elements in a complex system architecture. Different types of interactions can be displayed in the DSM. Types of interactions will vary from project to project.
Some representative interaction types are shown in the table below (Pimmler and Eppinger, 1994).

As an example, consider the material interaction between components for an automobile Climate Control System.

Clustering the "X" marks along the diagonal of the DSM resulted in the creation of three "chunks" for the Climate Control System. The "chunks" are (Pimmler and Eppinger, 1994): (1) Front End Air Chunk; (2) Refrigerant Chunk; (3) Interior Air Chunk.

TEAM-BASED DESIGN MATRICES

This approach is used for organizational analysis and design based on information flow among various organizational entities.  Individuals and groups participating in a project are the elements being analyzed (rows and columns in the matrix).  A Team-based DSM is constructed by identifying the required communication flows and representing them as connections between organizational entities in the matrix.  For the modeling exercise it is important to specify what is meant by information flow among teams. The table, below, presents several possible ways information flow can be characterized. 

The matrix can be manipulated in order to obtain clusters of highly interacting teams and individuals while attempting to minimize inter-cluster interactions. The obtained groupings represent a useful framework for organizational design by focusing on the predicted communication needs of different players.

For an application example, refer to McCord and Eppinger (1993). They propose a team-based DSM to analyze the organizational structure necessary for an improved automobile engine development process.

ACTIVITY-BASED DESIGN MATRICES

Three types of task interactions can be observed from the matrix. In the figure, below, tasks 1 and 2 are "independent" since no information is exchanged between them. These tasks can be executed simultaneously (in parallel). Tasks 3, 4, and 5 are engaged in a sequential information transfer and are considered "dependent". These tasks would typically be performed in series. Tasks 7 and 8, however, are mutually dependent on information. These are "interdependent" or "coupled" tasks often requiring multiple iterations for completion.

A Sample Task-Based DSM

1 2 3 4 5 6 7 8 9 1 1                 2   2               3   X 3             4   X   X X 4           5   X   X 5         6   X       6 X     7         X   7 X X 8      X       X 8   9            X     9

Marked cells above the diagonal represent iterations in the process. This occurs when an activity is dependent on information from a task scheduled for a later execution. Such scenarios often lead to rework and are undesirable. A number of algorithms have been developed (Warfield, 1973; Steward, 1981) to minimize such instances of iteration (above diagonal marked cells) by re-arranging the sequence of tasks in the process. Methods are also available on how to handle iterations in the process that cannot be eliminated through re-sequencing.

DSM models using simple binary representations strictly display the existence of a dependency between two tasks without providing additional information on the nature of the interaction. Further studies have extended the basic DSM configuration by capturing additional facts on the development process. For example, the numerical DSM adds task duration in the diagonal elements, and replaces marks with numbers in the off-diagonal cells each representing the degree of dependency between two tasks (Browning, 1998; Yassine, 1999).

PARAMETER-BASED DESIGN MATRICES

This type of modeling is used to analyze system architecture based on parameter interrelationships. A parameter-based DSM is constructed through explicit definition of a system's decomposed elements and their interactions. A systematic taxonomy and a quantification scheme assist in the analysis by categorizing types of interactions among system elements and associating an appropriate weight to each. Table 1 and Table 2, below, present the classification of interactions and an example of a quantification scheme proposed by Pimmler and Eppinger (1994).

Black (1990)applied a parameter-based DSM to an automobile brake system design, using the DSM to describe the current practices of a brake system component supplier. The DSM shown below is extracted from the original DSM which was (103 X 103). After sequencing the parameters, the resultant DSM (also shown below) two blocks of coupled, low level parameter determinations become apparent.

Parameter-Based DSM for Brake System (Black, 1990)

Parameter-Based DSM After Sequencing (Black, 1990)

DSM PARTITIONING

Partitioning is the process of manipulating (i.e. reordering) the DSM rows and columns such that the new DSM arrangement does not contain any feedback marks. Thus, transforming the DSM into a lower triangular form. For complex engineering systems, it is highly unlikely that simple row and column manipulation will result in a lower triangular form. Therefore, the analyst's objective changes from eliminating the feedback marks to moving them as close as possible to the diagonal (this form of the matrix is known as block triangular). In doing so, fewer system elements will be involved in the iteration cycle resulting in a faster development process.

There are several approaches used in DSM partitioning. However, they are all similar with a difference in how do they identify cycles (loops or ciruits) of information. All partitioning algorithms proceed as follows:

1. Identify system elements (or tasks) that can be determined (or executed) without input from the rest of the elements in the matrix. Those elements can easily be identified by observing an empty row in the DSM. Place those elements in the top of the DSM. Once an element is rearranged, it is removed from the DSM (with all its corresponding marks) and step 1 is repeated on the remaining elements.

2. Identify system elements (or tasks) that deliver no information to other elements in the matrix. Those elements can easily be identified by observing an empty column in the DSM. Place those elements in the bottom of the DSM. Once an element is rearranged, it is removed from the DSM (with all its corresponding marks) and step 2 is repeated on the remaining elements.

3. If after steps 1 and 2 there are no remaining elements in the DSM, then the matrix is completely partitioned; otherwise, the remaining elements contain information circuits (at least one).

4. Determine the circuits by one of the following methods:

   • Path Searching
   • Powers of the Adjacency Matrix Method

5. Collapse the elements involved in a single circuit into one representative element and go to step 1.

PATH SEARCHING

In path searching, information flow is traced either backwards or forwards until a task is encountered twice (Sargent and Westerberg, 1964). All tasks between the first and second occurrence of the task constitute a loop of information flow. When all loops have been identified, and all tasks have been scheduled, the sequencing is complete and the matrix is in block triangular form. The figure, below, is a simple example. The path searching partition proceeds as follows:

1. The unpartitioned matrix is in its original order.

2. Task F does not depend on information from any other tasks as indicated by an empty row. Schedule task F first in the matrix and remove it from further consideration.

3. Task E does not provide  information to any tasks in the matrix as indicated by an empty column. Schedule task F last in the matrix and remove it from further consideration.

4. Now, no tasks have empty rows or columns. A loop exists and can be traced starting with any of the remaining tasks. In this case, we select task A (arbitrary) and trace its dependence on task C. Task C is simultaneously dependent upon information from task A. Since task A and task C are in a loop, collapse one into the other and represent them in a single, composite task (i.e. task CA).

5. Task CA has an empty column indicating that it is not part of any other loop. Schedule it last and remove it from further consideration.

6. Trace dependency starting with any unscheduled task: task B depends on task G which depends on task D which depends on task B. This final loop includes all the remaining unscheduled tasks.

7. The final partitioned matrix.

Example

POWERS OF THE ADJACENCY MATRIX METHOD

Identifying Loops by Powers of the Adjacency Matrix. The Adjacency matrix is a binary DSM where an empty cell is replaced with a "zero" and a non-empty cell is replaced by one. Raising the DSM to the n-th power shows which element can be reached from itself in n steps by observing a non-zero entry for that task along the diagonal of the matrix. For example squaring the DSM (below) shows that tasks A and C are involved in a two-step loop. [Note that in the resultant square matrix, cells with a value of greater than one were replaced by a value of one].

Similarly, cubing the DSM, as shown below, shows that tasks B, D and E are involved in a three-step loop. The higher powers of the DSM reveal no other loops in the system.

REACHABILITY MATRIX METHODS

DSM Partitioning Using Reachability Matrix Method. The reachability matrix is a binary DSM with the diagonal elements equal to "ONE". The method calls for finding a multi-level hierarchical decomposition for the matrix. The top level in this hierarchy is composed of all elements that require no input or are independent from all other elements in the matrix. Any two elements at the same level of the hierarchy are either not connected to each other or are part of the same circuit at that level. Once the top level set of elements is identified, the elements in the top level set and their corresponding from/to connections are removed from the matrix leaving us with a sub-matrix that has its own top level set. The top level set of this sub-matrix will be the second level set of the original matrix. Proceeding in this manner, all the levels of the matrix can be identified.

The step-by-step procedures is as follows:

1. Construct a table with four columns.

   • In the first column, list all the elements in the matrix.

   • In the second column, list the set of all the input elements for each row in your table. This set can easily be identified by observing an entry of "ONE" in the corresponding row in the DSM. (Include the element itself as an input).

   • In the third column, list the set of all output elements for each row in your table. This set can easily be identified by observing an entry of "ONE" in the corresponding column in the DSM. (Include the element itself as an output).

   • In the fourth column, list the intersection of the input and output sets for each element in your table.

2. Identify top level elements and remove them from the table. An element is in the top level hierarchy of the matrix if its input set is equal to the intersection set.

3. Go to step 1.

Example. An excellent step-by-step example can be found in John Warfield (1973).

DSM TEARING

Tearing is the process of choosing the set of feedback marks that if removed from the matrix (and then the matrix is re-partitioned) will render the matrix lower triangular. The marks that we remove from the matrix are called "tears".

Identifying those "tears" that result in a lower triangular matrix means that we have identified the set of assumptions that need to be made in order to start design process iterations when coupled tasks are encountered in the process. Having made these assumptions, no additional estimates need to be made.

No optimal method exist for tearing, but we recommend the use of two criteria when making tearing decisions:

• Minimal number of Tears. The motivation behind this criterion is that tears represent an approximation or an initial guess to be used; we would rather reduce the number of these guesses used.
• Confine tears to the Smallest blocks along the Diagonal. The motivation behind this criterion is that if there are to be iterations within iterations (i.e.. blocks within blocks), these inner iterations are done more often. Therefore, it is desirable to confine the inner iterations to a small number of tasks.

DSM CLUSTERING

As we have learned in the partitioning section, the goal of partitioning was to render the DSM lower triangular as much as possible. The reason was due to the significance of upper-diagonal marks, which represented feedback information flows. This situation arises whenever the matrix elements represent a set of project tasks (i.e. task-based DSM).

On the other hand, when the DSM elements represent design components (i.e. component-based DSM) or teams within a development project (i.e. team-based DSM), the goal of the matrix manipulation changes significantly form that of partitioning algorithms. The new goal becomes finding subsets of DSM elements (i.e. clusters or modules) that are mutually exclusive or minimally interacting subsets. This process is referred to as "Clustering". In other words, clusters absorb most, if not all, of the interactions (i.e. DSM marks) internally and the interactions or links between separate clusters is eliminated or at least minimized.

Example. Consider a development process that includes seven participants as shown in the DSM, below. Note that the interactions between different participants are also shown in the DSM. If we were to form several development teams within this project, what will be the number of teams required and the membership of each team?

Clustering the DSM for this project will provide us with insights into optimal team formations based on the degree of interactions among participants.

If the above DSM was rearranged in the following manner (as shown below). One possible team assignment is:

• Team 1: participants 1 and 6;
• Team 2: participants 4 and 5;
• Team 3: participants 2, 3, 4 and 7.

Note that by making participant 4 a member of both teams 2 and 3, we were able to absorb more interactions internally within a team.

Example. Consider the following component-based DSM for an automobile Climate Control System (Pimmler and Eppinger, 1994).

The above DSM was rearranged such that the following module structure was apparent. 

Clustering the "marks along the diagonal of the DSM resulted in the creation of three" for the Climate Control System (Pimmler and Eppinger, 1994):

1. Front End Air Chunk.
2. Refrigerant Chunk.
3. Interior Air Chunk.

DSM BANDING

Banding is the addition of alternating light and dark bands to a DSM to show independent (i.e. parallel or concurrent) activities (or system elements) (Grose, 1994). Banding is similar to partitioning the DSM using the Reachability Matrix Method when the feedback marks are ignored (a band correspond to a level).

The collection of bands or levels within a DSM constitute the critical path of the system/project. Furthermore, one element/activity within each band is the critical/bottleneck activity. Thus, fewer bands are preferred since they improve the concurrency of the system/project. For example, in the  DSM shown below, tasks 4 and 5 do not depend on each other for information; therefore, they belong to the same band.

Example

Note that in the banding procedure, as described above, feedback marks are not considered (i.e. they are ignored in the process of determing the bands).

NUMERICAL DSM

In binary DSM notation (where the matrix is populated with "ones" "zeros" or "X" marks & empty cells) a single attribute was used to convey relationships between different system elements; namely, the "existence" attribute which signifies the existence or absence of a dependency between the different elements.

Compared to binary DSMs, Numerical DSMs (NDSM) could contain a multitude of attributes that provide more detailed information on the relationships between the different system elements. An improved description/capture of these relationships provide a better understanding of the system and allows for for the development of more complex and practical partitioning and tearing algorithms.

Example. Consider the case where task B depends on information from task A. However, if this information is predictable or have little impact on task B, then the information dependency could be eliminated. Binary DSMs lack the richness of such an argument.

What attributes/measures can be used?

• Levels Numbers: Steward (1981) suggested the use of level numbers instead of a simple "X" mark, for certain marks in the binary matrix. Level numbers reflect the order in which the feedback marks should be torn. The mark with the highest level number will be torn first and the matrix is reordered (i.e partitioned) again. This process is repeated until all feedback marks disappear. Level numbers range from 1 to 9 depending on the engineers judgement of where a good estimate, for a missing information piece, can be made.

• Importance Ratings: A simple verbal scale can be constructed to differentiate between different important levels of the "X" marks. As an example, we can define a 3-level scale as follows:

In the above scenario, we can proceed with tearing the low dependency marks first and then the medium and high in a process similar to the level numbers method, above.

Some other attributes depend on the type of DSM used in the representation and analysis of the problem.

For example,in an Activity-based DSM, the following measures can be used:

• Dependency Strength: This can be a measure between 0 and 1, where 1 represents an extremely strong dependency. The matrix can, now, be partitioned by minimizing the sum of the dependency strengths above the diagonal. 

• Volume of Information Transferred: An actual measure of the volume of the information exchanged (measured in bits) may be utilized in the DSM. Partitioning of such a DSM would require a minimization of the cumulative volume of the feedback information.

• Variability of Information Exchanged: A variability measure can be devised to reflect the uncertainty in the information exchanged between tasks. This measure can be the statistical variance of outputs for that task accumulated from previous executions of the task (or a similar one). However, if we lack such historical data, a subjective measure can be devised to reflect this variability in task outputs (Yassine et al., 1999).

• Probability of Repetition: This number reflects the probability of one activity causing rework in another. Upper-diagonal elements represent the probability of having to loop back (i.e. iteration) to earlier (upstream) activities after a downstream activity was performed Smith et al. (1997a). While lower-diagonal elements can represent the probability of a second-order rework following an iteration Browning (1998). Partitioning algorithms can be devised to order the tasks in this DSM such that the probability of iteration or the project duration is minimized. Browning (1998) devised a simulation algorithm to perform such a task. An excel macro that performs Monte Carlo simulation of the DSM is available to download from this web site. A brief description of the DSM similation technique and how it works is in another section of this tutorial. Click here if you want to jump to the DSM simulation section.

• Impact strength: This can be visualized as the fraction of the original work that has to be repeated should an iteration occur [Browning (1998) and Carrascosa et al. (1998)]. This measure is usually utilized in conjunction with the probability of repetition measure, above, to simulate the effect of iterations on project duration.

Similar measures can be devised for other DSM types.

Note. This section of the notes was written by : Dr. T.R. Browning, Lockheed Martin TAS, Fort Worth, Texas USA. For a fuller explanation of the DSM-Sim, see Chapter 6 of Browning, Tyson Rodgers (1998) Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product Development, Unpublished Ph.D. Thesis (TMP), Massachusetts Institute of Technology, Cambridge, MA.

We can use a DSM-based model of a process to quantify a process configuration’s expected cost and duration and their variances. Cost, duration (or schedule), and variances in both are largely a function of the number of iterations required in the process execution and the scope or impact of those iterations. Since iterations may or may not occur (depending on a variety of variables), this model treats iterations stochastically, with a probability of occurrence depending on the particular package of information triggering rework.

This model characterizes the design process as being composed of activities that depend on each other for information. Changes in that information cause rework. Thus, rework in one activity can cause a chain reaction through supposedly finished and in-progress activities. Activity rework is a function of the probability of a change in inputs (data package volatility and activity sensitivity) and the impact of a change in inputs (activity sensitivity). The model also assumes that independent activities can work concurrently.

As input, the DSM-Sim requires a DSM model and some additional data. For each activity, three cost and duration estimates are required: an optimistic or best case value (BCV), a most likely value (MLV), and a pessimistic or worst case value (WCV). Each activity also has an associated improvement curve, which represents learning, set up times, etc. The improvement curve is given by a percentage, the percentage of the original duration required to regenerate the outputs. (E.g., it takes 30% of the original duration to repeat the activity second and successive times.) Table 1 provides example activity data. In addition, for each activity interface, the model requires an assessment of the probability of a typical change in the data causing rework for an activity and the impact of that rework should it occur. Impact values are percentages of an activity to rework. Example probabilities and impacts are shown in the DSMs in Table 2.

Table 1: Activity Data for Model Input

Table 2: DSM Dimensions One (Top) and Two, Showing Rework Probabilities and Rework Impacts, Respectively

Points to note on the simulation formulation are as follows:

1. Activity cost and duration are random variables, represented by a distribution of possible values. The BCV, MLV, and WCV are used to form a rough, triangular PDF, denoted as TriPDF(BCV,MLV,WCV) for "smaller is better" (SIB) measures such as cost and duration. For each run, the model randomly samples a single value for each activity’s cost and duration from that activity.

2. The model also uses three other vectors, each with a length equal to the number of activities. First, a sequencing vector specifies the order of the activities in the DSM—i.e., the process configuration. In Table 2, for instance, the sequence is simply 1, 2, …, 14. Changing the sequencing vector allows for the exploration of alternative process configurations. Second, a work vector, W, keeps track of the amount of work remaining to be done on each activity. Usually, each entry in this vector is set to 100% to begin each simulation run. Third, a "work now" vector of Boolean entries indicates if an activity is to do work at a given time during the simulation execution. This vector is discussed below.

3. The simulation uses a simple, time advancing approach. Each run consists of a series of equal time steps, ?t, the size of which is smaller than the duration of the shortest activity. (E.g., if activities have durations ranging from five to 50 weeks, a reasonable ?t could be 0.5 weeks, as activity durations are rounded off to an integer number of time steps. Smaller time steps provide greater model resolution at the expense of greater simulation execution time.)

4. During each time step, the model checks for the most upstream activity requiring work and any activities that can be executed concurrently. Activities do not begin work until their needed inputs are available from completed, upstream activities. (Dependencies on upstream activities are shown in the lower triangular portion of the DSM.) Work is done on available activities during the time step, and their work remaining is reduced by the fraction of their duration represented by the time step. The cumulative process cost is increased based on the cost of this work. Whenever an activity finishes, the model checks for potential iterations (rework for upstream activities) and second-order rework resulting from iterations using the probabilities in the DSM. If rework occurs, its amount—a percentage of the activity given in the DSM and modified by improvement curve effects—is added to the W vector.

5. When all activities are complete, all W vector entries equal zero. The model converts the number of time steps required into appropriate units and outputs this as the process duration or schedule, S, for the run. Cumulative process cost is output as C.

6. Each run of the simulation yields a cost and schedule outcome for a process in a given configuration. The simulation continues to do batches of 25 runs until the means and variances of the C and S outcome distributions stabilize to within 1%. The user can adjust the 1% stability threshold and the run batch size between stability checks.

The simulation is implemented in a spreadsheet. Table 3 presents the important variables used in the model, and Table 4 provides an overview of the algorithm.

Table 3: Model Variables

Table 4: Algorithm for Each Run of Model

Points to note are as follows:

1. The DSM-Sim utilizes some simplifying assumptions and makes some work policy choices. These choices can be altered by modifying the simulation algorithm. The algorithm currently assumes that the most upstream activity requiring work will begin first. Additional activities can work concurrently with this activity if they do not depend on it (or an interim activity). With this approach, the workflow is determined by the process configuration, thereby allowing the comparison of alternative configurations. Note that this policy has the effect of causing an activity to stop and wait if an activity upon which it depends begins rework. Furthermore, the algorithm currently assumes that activities only produce outputs upon completion, and that rework cannot increase the original scope of an activity (i.e., no W vector entry can exceed 100%).

2. Using the example data given above and running the simulation provides some example outputs. Figure 1 shows the pattern of activity execution in a Gantt chart format for a single run. Figure 2 shows probability mass functions (PMFs) and cumulative distribution functions (CDFs) for a large set of cost and schedule outcomes (r = 475, ?t = 2). The mean cost outcome, E[C], is $647k with a standard deviation, s_C, of $45k. The median cost outcome is $640k. As we expect, this distribution is skewed right (skewness = 1.15). The mean duration, E[S], is 141 days with a standard deviation, s_S, of 8 days. Median duration is 140 days, even though the schedule distribution is skewed right (skewness = 0.95).

SIMULATING DSMs BASED ON INFORMATION AND RESOURCE CONSTRAINTS

Introduction.

DSM literature focuses on a single projects, where precedence information constraints determine the execution sequence for the activities and the resultant project lead-time.  In this research, we consider a DSM model for multiple projects that share a common set of design resources.  Especially in this setting, precedence information availability is insufficient to assure that activities will execute on time.  We extend the DSM modeling literature by including resource availability, where activity execution is based on both information and resource constraints.

The Multi-Project DSM Model.

Here we discuss the extension of the single-project DSM to include multiple projects and resource constraints. We refer to the multi-project DSM as the aggregate DSM.Building the aggregate DSM is best illustrated through a simple example. Consider three development projects occurring simultaneously (projects 1, 2, and 3) and involving four development resources/processors (A, B, C, and D), as shown in the top part of Figure 1. Processor A is assigned to all projects as depicted in the Figure by A1, A2, and A3.Processor B is assigned to projects 1 and 2 as depicted in the Figure by B1 and B2.The same representation holds for processors C and D.

The aggregate DSM, shown in the lower part of Figure 1, combines the DSMs for each project. The square marks (“n”) inside the aggregate DSM represent information constraints, while the diamond marks (“v”) represent resource constraints. Note that the diamond marks shown in the figure represent only one possible resource constraint profile. The arrangement shown assumes that activities in project 1 are preferred to activities in project 2, and activities in project 2 are preferred to activities in project 3.For example, the diamond mark in row 5 and column 1 conveys that A2 depends on A1 finish for its execution. Inserting this mark in row 1 column 5, instead, would reverse the resource dependency. In general, if a processor is assigned to p projects, then there are (p!) possible priority profiles for that processor.

The aggregate DSM provides managers of multiple projects a simple snapshot of the whole development portfolio, allowing them to clearly see and trace information dependencies within projects and across multiple projects, while explicitly accounting for resource contention.[1] Partitioning the aggregate DSM reveals an improved information flow and clear resource prioritization across the whole PD portfolio as compared to independently partitioning the individual project DSMs. 

Project Queues

Each processor can be involved in multiple activities (from the same or different projects), but they can only work on one project's activity at any given moment. The list of activities from different projects is called the project queue for a processor. We will refer to each processor's project queue as Q_i, where i is the processor index.

At any time, t, Q_i(t) consists of two mutually exclusive and collectively exhaustive partitions: A_i(t) and I_i(t). The processor's active queue, A_i(t), contains a subset of Q_i(t) that is readily available for work (based on predecessor information availability only) at time t. The processor must choose one of these activities to work on. The inactive queue, I_i(t), contains all other activities. Coupled activities are those activities involved in an iterative block.  A work policy is used to allocate coupled activities to either A_i(t) or I_i(t) based on how the activities are sequenced in the DSM (the process architecture determined by partitioning). The first activities in the coupled block make assumptions about the later activities’ inputs and are assigned to A_i(t).

The Preference Function

If a processor is assigned to two projects and it can perform work on either one, at a given instant in time, the choice is made based on a preference function that includes activity, project, and processor characteristics. The preference function addresses the following concerns:

• When faced with a choice, which activity (in which project) should a processor work on?
• What is the impact of the above decision on PD time?

The preference function (or priority profile) ranks the activities in processors’ active queues, so that the activity with the highest priority is selected to work on. Preference or priority is a function of activity, project, and processor attributes. The attribute hierarchy is shown in the tree of Figure 2.Determining how to weight the attributes requires conducting interviews with the processors involved in the different projects to solicit their mental value model they use when determining activity priorities. The preference function consists of a weighted combination of the eight attributes listed and discussed in Table 1.

Each branch, i, in the attribute hierarchy Figure 2) has a weight, k_i, and a utility or preference value, U_i, which is a function of the attribute level, x_i.

To arrive at an overall preference index for each activity, we can use a weighted sum: U(x₁, …., x_n) =

Each utility curve is defined over [0,1], and all of the weights are positive and sum to one, so the overall preference index is also defined over [0,1]. Once a preference index is calculated for each activity in a processor’s active queue, the activity with the highest preference index is preferred.

 

Activity Attributes	1. Expectations for activity rework (Rework Risk). People’s choice of whether or not to work on an activity can be influenced by their knowledge of the likelihood of that activity to change or be reworked later. Prior to running the simulation, a “rework risk” is estimated for each activity based on the likelihood and the impact of changes in the activity’s inputs. The estimate combines the impacts of both first- and second-order rework. First-order rework is caused by changes in inputs from downstream activities and is the sum of the product of rework probability and rework impact for all such inputs. Second-order rework is caused by changes in inputs from upstream activities which themselves have some risk of first-order rework. Second-order rework is the sum of the product of rework probability and rework impact for all such inputs, where each such product is further multiplied by the upstream activity’s estimated rework risk.
	2.     Number of dependent activities.  People are more likely to work on activities upon which a large number of other people depend.  The number of marks in each column of the binary DSM is counted to determine the number of dependent activities.
	3.     Nearness to completion.  This attribute is a function of the amount of work remaining for the activity.  It assumes that people would rather finish nearly complete activities than begin new activities. (The attribute can also be set to reflect the reverse situation).
	4.     Relative duration.  This attribute assumes that shorter activities will be preferred to longer ones.  Prior to running the simulation (but after a random sample has been obtained for each activity’s duration), the relative duration of each processor’s activities is determined.  Each processor’s activities are classified as either the shortest or the longest duration activity for that processor, or else in-between.  (This attribute can also be set to prefer longer activities.)
Project Attributes	5.     Cost of project delay.  A cost of delay is supplied for each project as an input to the simulation.  Activities in projects with higher costs of delay are given greater priority.
	6.     Project type.  Project type is also given for each project as an input to the simulation.  We classify project type based on project visibility and/or priority—which is either “high,” “medium/normal,” or “low.”
	7.     Schedule pressure.  As a project falls behind schedule, pressure builds to finish its activities.  Each project and each activity within it have scheduled completion times or deadlines, which are provided as inputs to the simulation.  Project schedule pressure is the sum of the schedule pressure contributions of all of its activities.
Processor Attribute	8.     Personal and interpersonal factors.  It is impossible to represent the comprehensive set of factors that influence a processor’s choice of projects and activities.  Therefore, we utilize a random factor to represent other influences, including personal and interpersonal (and even irrational) factors.  The random factor can represent personality, risk propensity or averseness, interpersonal relationships—really anything not attributable to the other attributes.

Simulating the Model

The simulation is implemented in a spreadsheet model using Excel Visual Basic macro programming (click here to download). All input information (i.e. project data and the corresponding activity details) is entered into the Excel spreadsheet. Then, the simulation starts by executing the simulation macros. The results of the simulation are displayed as a set of lead-time distributions for each project and for the whole portfolio as shown in Figure 3.

(a) Lead time distributions for the overall project portfolio: with and without resource constraints	(b) Lead time distributions for Project 1: with and without resource constraints
(c) Lead time distributions for Project 2	(d) Lead time distributions for Project 3

In our simulation, project execution is guided by a specific work policy.

1. We use a simple work policy that requires all predecessor activities to be completed before an activity is eligible to begin work. However, coupled activities can begin work without inputs from downstream activities within their block (by making assumptions about the nature of those inputs). Prior to the beginning of the simulation, the aggregate DSM is partitioned in order to the minimal set of coupled activities. Then, a nominal duration for each activity is randomly sampled from its triangular distribution. These sampled durations are saved in a temporary vector for later use within a single simulation run.

2. Once the DSM is partitioned and nominal activity durations are sampled, the simulation proceeds through increments of time, Dt. At each time step, the simulation must (a) determine which activities are worked on (b) record the amount of work accomplished, and (c) check for possible rework. Determining which activities can be worked requires two steps:

3. Determine which activities are eligible to do work based only on information constraints. Activities that have work to do and for which all predecessor activities are completed (i.e., for which all upstream input information is available) are eligible.

4. Assign eligible activities to their processors, thereby determining each processor’s active queue. If any processor has more than one activity in their active queue, then the preference algorithm is invoked to select the activity the processor will address in the current time step. This step essentially entails temporarily inserting additional marks into the DSM that represent processors’ preferences for eligible activities.

5. Each processor's active queue is redetermined at each time step. If it is empty, then the processor is idle. If it contains a single activity, then the processor works on that activity. If the active queue contains more than one activity, then the preference function is invoked to determine which activity the processor will work on. At each time step, the simulation deducts a fraction of “work to be done” from each working activity. Finally, at the end of each time step, the simulation macro notes all activities that have just finished (nominal duration or rework). The macro performs another check to determine the coupled ones by inspecting the partitioned aggregate DSM. For each one of these finished and coupled activities, a probabilistic call is made to determine whether this activity will trigger rework for other coupled activities within its block. If rework is triggered, then the amount of rework is determined from the impact DSM and added to the “work to be done” on the impacted activity.

1. Here, we assume no information dependencies (only resource constraints) between projects, but the aggregate DSM can accommodate such dependencies by allowing the insertion of a combination of square and diamond marks outside the individual projects blocks.
2. The triangular distribution for each activity duration is represented by the minimum, likely, and maximum duration values in the input spreadsheet

Insert material soon .....

REFERENCES

1. Black T.A., Fine, C.H., and Sachs, E.M., A Method for Systems Design Using Precedence Relationships: An Application to Automotive Brake Systems. M.I.T. Sloan School of Management, Cambridge, MA, Working Paper no. 3208, 1990.
2. Browning T.R., "Integrative Mechanisms for Multiteam Integration: Findings from Five Case Studies" Systems Engineering, vol. 1, pp. 95-112, 1998a.
3. Browning T.R., Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product Development, Ph.D. Thesis (TMP), Massachusetts Institute of Technology, Cambridge, MA, 1998b.
4. Browning T.R., "Use of Dependency Structure Matrices for Product Development Cycle Time Reduction", Proceedings of the Fifth ISPE International Conference on Concurrent Engineering: Research and Applications, Tokyo, Japan, July 15-17, 1998c, pp. 89-96.
5. Browning T.R., and Eppinger S.D., Model for Development Project Cost and Schedule Planning," M.I.T. Sloan School of Management, Cambridge, MA, Working Paper no. 4050, November 1998.
6. Browning T.R., "Categorization of Dependency Structure Matrix Applications for Systems Engineering, Organization Planning, and Project Management", Submitted to IEEE Transactions on Engineering Management, Revision April 1999.
7. Grose D.L., "Reengineering the Aircraft Design Process," Proceedings of the Fifth AIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimization, Panama City Beach, FL, Sept. 7-9, 1994.
8. McCord K.R. and Eppinger S.D., "Managing the Integration Problem in Concurrent Engineering", M.I.T. Sloan School of Management, Cambridge, MA, Working Paper no.3594,, 1993.
9. Pimmler T.U. and Eppinger S.D. "Integration Analysis of Product Decompositions", Proceedings of the ASME Sixth International Conference on Design Theory and Methodology, Minneapolis, MN, Sept., 1994. Also, M.I.T. Sloan School of Management, Cambridge, MA, Working Paper no. 3690-94-MS, May 1994.
10. Steward, D.V., "Partitioning and Tearing Systems of Equations, SIAM Numerical Anal., ser. B, Vol. 2, No. 2, pp. 345-365, 1965.
11. Steward, D.V., "The Design Structure System: A Method for Managing the Design of Complex Systems" IEEE Transactions on Engineering Management, Vol. 28, pp. 71-74, 1981a.
12. Ulrich, K. and Eppinger, S. Product Design and Development, McGraw-Hill Inc., New York, 1999.
13. Warfield J., "Binary Matrices in System Modeling," IEEE Transactions on Systems, Man, and Cybernetics, Vol. 3, pp. 441-449, 1973.
14. Yassine, Ali A., Falkenburg, D.R. and Chelst K., Engineerin Design Management: An Information Structure Approach. International Journal of Production Research, Vol. 37, no. 13, 1999. pp. 2957-2975.
15. Yassine, Ali A. and Falkenburg D.R., A Framework for Design Process Specifications Management, Journal of Engineering Design, vol. 10, no. 3, September 1999.
16. Yassine, A., Whitney D., Lavine J. and Zambito T., DO-IT-RIGHT-FIRST-TIME (DRFT) Approach to Design Structure Matrix (DSM) Restructuring," Proceedings of the 12th International Conference on Design Theory and Methodology (DTM 2000), September 10-13, 2000 Baltimore, Maryland, USA.

WEB RESOURCES

• The MIT Design Structure Matrix (DSM) Home Page

Developed in April 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin, University of Maryland