The success of the DSM method is determined by an appropriate system decomposition and by the accuracy of the dependence relationships. Therefore, it is vital to decompose the system under study carefully into a comprehensive set of meaningful system elements. An appropriate decomposition can be established by gathering a group of managers/experts from different functional groups of an organization and asking them to collectively list the different sub-systems that comprise the system as a whole.

The decomposition can be hierarchical or non-hierarchical (sometimes called network decomposition). In the hierarchical decomposition, the system can be divided into sub-systems or modules. Those modules are, in turn, divided into finer components, it is therefore suitable if the decomposition is clear-cut and unambiguous. In the network decomposition, a system hierarchy is not evident, such a decomposition is purposeful if no straightforward hierarchy can be devised or if the hierarchy is ambiguous.

Once the appropriate system elements or set of activities that comprise a project have been identified, they are listed in the DSM as row and column labels in the same order. The elements within the matrix are then identified by asking the appropriate manager or expert in the group for the minimum set of parameters that influence their own sub-system and contribute to its behavior. In a task-based DSM, this can be the minimum set of activities that need to be performed before the activity under questioning can be started. In a parameter-based DSM, the rows and columns are design parameters that drive the design or define the system and the managers/experts can then be asked to define the precedence relationships between the listed parameters. These tasks/parameters/elements are marked in the DSM by an ‘X’.

Basic Steps

• Interview engineers and managers
  
  
• Check for possible sources of data that can be parsed or exported into a DSM
  
  
• Determine list of system elements
  
  
• Ask about inputs, outputs, strengths of interaction, etc between elements
  
  
• Enter marks in matrix
  
  
• Collect the comments that explain each element and each dependency (for later understanding and interpretation)
  
  
• Check with engineers and managers to verify/comment on DSM
  
  
• Refine the model over time by assimilating organizational learning

Available templates

	Interview-template.pdf Interview template in PDF format	8.8 K
	Interview-template.xls Interview template as editable spreadsheet	21 K

Another complete methodology to build DSMs and MDMs is proposed in 
Lindemann, U.; Maurer, U.; Braun, T.: Structural Complexity Management. Berlin, Springer 2009, ISBN 978-3-540-87888-9.

A Proposed Approach for Building Credible DSMs

This section is taken and adapted from  Qi Dong: Predicting and Managing System Interactions at early phase of the product development process, PhD Thesis, MIT, 2002.

1.  Define the system and its scope

Since the DSM is a tool that studies the design process as a system with many interacting elements, it is important to define the boundary of the system in order to focus the research work. Different system definition results in different output of the DSM.

2.  List all the system elements

Initially, the system elements can be chosen based on the existing project plans, engineers’ suggestions, etc. The author of the DSM usually defines the initial set of system elements based on the reading of design documentation. However, experience shows that the initially defined system elements often need to be modified in the process of assigning interactions to them. A critical review of the list of elements in collaboration with engineering staff or other relevant experts is therefore necessary.

3.  Study the information flow between system elements

The third step is to study the information flow between system elements. Reading the design documents as well as interviewing experienced engineers who were working on the particular product is a good source of knowledge. Interviews are just as important as reading design documents for two reasons. First, not all the knowledge is well captured by design documents. A large amount of information exists in engineers’ heads. Hence, it is important to extract the undocumented knowledge from the engineers. Second, interviews seem to be an effective means of extracting knowledge from the engineers’ mind compared to other methods. During the thesis research work, the author found that different engineers often had different views on how one element related to the other and how important the relation was. The causes of the differences could usually be one of the following two:

• The interaction was not direct. For example, the Belt Seals (in an automotive door assembly) affect the motion of the window Glass by exerting seal drag force on the glass. The seal drag force and the motion of the glass are factors that affect the motor design. Thus the relation is:
  
  Belt Seals –> Glass –> Motor
  
  However, often, the engineers would say the belt seals affected the motor design due to their intuition from work experience. In this situation, the interviewer needs to have a good understanding on the content of the interaction, and explain to the engineers why a mark should be put in Column Belt Seals and row Glass, instead of column Belt Seals and row Motor. Although there is no mark between the Motor and the Belt Seals, the two will reach each other indirectly, which will show in the reachability matrix. Thus, the detailed definition of the relationship type and its direction is very important.
  Sometimes, the indirect interactions might not be found out during the interview. The interviewer needed to document the content of each interaction, and to go through them alone after the interview to sort out indirect relations. By doing so, the interviewer can also gain a good insight to the system, and find out the essence of the information flow.
  
  
• The engineers have different perspectives on the issues due to the difference of their work. In this case, the interviewer acted as a mediator. The interviewer should possess the knowledge of the system to some degree, and be able to discuss different viewpoints with different interviewees, or even go back and ask them again, until a common understanding is reached.

For the two reasons mentioned above, it is very important to interview individual engineers face to face for the content of the relations. However, since interviews are usually time-consuming and tedious, many researchers have proposed using survey sheets or collecting information from meetings.

• Sometimes, researchers used survey sheets to obtain the engineers’ opinions. The DSM was constructed based on the majority of the votes or the higher level managers’ views. The advantage of using survey sheets is time-efficient. However, many important details may be lost since the survey sheets don’t give explanations on their choices. Also, bias due to work experience cannot be distinguished in a survey sheet.
  
  
• Meetings open up the opportunities for discussion and understanding which is unavailable from the survey sheets. Meetings also reduced the amount of time for the data collector to get a consensus among engineers. However, it is inevitable that some of the engineers may feel uneasy to speak their mind due to peer pressure, or due to the influence of the rest of the group. Some important data may be lost this way. In all cases, a meeting should be well-prepared and documented for later use of the data collected.

Since the DSM is a tool to analyze the design project and to seek improvements, it is important that the data is accurate. Although talking to engineers in person is time consuming, the interviewer can usually gather accurate information and gain a very good insight to the system. However, when necessary, one may have to trade the speed of data collection with the quality of the data.

Step 2 and Step 3 are highly iterative. Deeper understanding of the system usually results in modification of the initial system elements. The system elements in this thesis research were modified many times during the interviews and documentation readings in order to represent the system accurately.

4.  Complete the matrix to represent the information flow

Having collected the elements and the dependencies, initially, a binary DSM can be built to represent the basic dependency structure and information flows between various system elements. A binary DSM serves as a good start for preliminary analysis; however, a better understanding of the system (or project) might require the use of a numerical DSM that will provide better system understanding and allow for more detailed analysis.  

5.  Give the matrix to the engineers and managers to comment on and use

DSM provides aid to design engineers and engineering managers to understand the design process better and approach the communication more systematically. Hence, the constructed DSM’s are usually provided to the engineers and manager who participated in their building to receive comments. This creates, on the one hand side, transparency about the benefits of building a DSM, as seeing the entire picture of the design process like never before makes many engineers rethink their current practice, and seek improvements. On the other hand, the collection of comments can further aid the refinement of the structure of the DSM.

Observations and issues with building DSMs

• You cannot do all data gathering by talking to yourself! 
  
  
• Passing out standardized forms to collect DSM data did not prove to be very reliable. Instead, face-to-face interviews with the right experts is recommended to fill out these forms.
  
  
• People are reasonably accurate in answering what “information” they need before they can do their job, and where to get this information. However, they are less accurate/reliable when it comes to knowing where does their information go and who uses it.  
  
  
• There is a tendency for engineers to want/ask for as much information as possible before making a decision about a parameter. This will tend to over-populate the DSM with unnecessary marks.
  
  
• There is a tendency for engineers to rely on past experiences when making judgement as to what information is needed to fully determine a given parameter (in a current / ongoing project). This may result in ignoring important marks in the DSM.
  
  
• High level abstraction or decomposition of a system might oversimplify the design process and tend to ignore important sub-system interactions that might be apparent at a lower abstraction level. On the other hand, with finer system decompositions we run a risk of diminishing the intuitiveness provided by the DSM as it becomes increasingly difficult to identify important sub-system  interfaces. This difficulty can be overcome by building a hierarchy of DSMs at different levels of abstraction. By that we mean, build a high level DSM first (that may contain all different subsystems as line items only). Then, for each line item in the previous DSM hierarchy, build a separate DSM (which explodes each line item in previous DSM into a separate DSM). This process of DSM explosion can be cascaded down enough until certain desired interactions are apparent at the lowest level. Finally, the lowest level DSMs can be aggregated to form a complete system DSM.