DSM: A useful tool for process improvement efforts

by

Design Structure Matrix, or DSM in short, is a tool I frequently see during my year here at MIT.  It is often mentioned in “System Thinking” talks, as well as talks on designing complex system.  While the DSM’s uses are many, my project team mates and I focused on process improvement and successfully used the DSM to help our sponsor company improve its processes.  Our sponsor company is a aircraft maintenance, repair and overhaul business, and the process we focused on was the aircraft upgrading process, which spans from defining requirements for the upgrade, to drawing out the design, to implementation, to testing and finally to delivery.

How the DSM helped

1. Reduce long rework cycles – imagine the nightmare scenario where a project gets to almost completion, and then have to loopback to the beginning for reasons such as a major design error.  It is like the chutes and ladders game.  The DSM helps to reduce long reworks by reordering the tasks.  For example, in our project, initially there were four rework cycles that would set the project back by more than 20 tasks.  After the reordering, there were none.

2. Challenge the status quo task ordering, while respecting task dependencies – in the reordered task list for our project, we realized that a number of documentation tasks were pushed to the bottom of the list.  These tasks dealt with the development of internal test reports, flight manual and maintenance manual.

Initially, we thought that meant that the company should do those documentation tasks last.  However, on investigating further, we realized it was because no or very few other tasks depended on those tasks.  We thought about that further, and a revelation hit us: if no other tasks are waiting on those documents to be developed, does that mean that employees could develop those documents late and to the lowest quality but yet not affect the entire process in any way?  How can the company ensure the timeliness and quality of those documents?  Our sponsor validated that concern, and in the end, we recommended adding sign-offs of those documents to resolve this issue.

This is just one of the many examples.  The DSM challenged the status quo task ordering, in a way that respected the task dependencies, so the new ordering still made sense and provided ideas for how the current process might be done better.

3. Facilitate understanding of the current process
The DSM creation process required us to get our hands dirty into understanding the process.  We needed to think about what level of granularity we need to get down to, and what kinds of dependencies we should capture.  These activities helped us think more about the process, and thus added in our understanding.

In addition, the DSM also provided a visual map of the process.  At one glance, we could see which are the tasks that have many dependencies.

Additional Information about the DSM

For readers interested in finding out more about the DSM, I have included some basic information here.

DSM might seem rather technical and intimidating at first glance.  And that fear is well justified, as DSMs are matrices, a mathematical artifact that inspire fear into people’s heart by the mere mention of its name.  However, if you spend 10-15 understanding how it works, you will find DSM a useful tool to include in your toolbox for process improvement projects.

Creating the DSM

To use the DSM (for the purpose describe in the article), we have to provide three main pieces of information:
1. The list of tasks in the process.  For example, in the design phase, creating the high level design would be a possible task, and doing preliminary design review would be another possible task.
2. The dependencies between tasks.  This information will specify that for Task A to start, what tasks would need to be first completed.  For example, preliminary design review needs to be completed first before detailed design can commence.
3. Possible loopbacks.  This indicates scenarios where rework need to happen.  For example, after preliminary design review, the proposed design might be deem unsuitable and the project will need to go back to high level design.

These three pieces of information can be visualized in a graph like the following:

Here, the tasks are represented by the boxes, the task dependencies by the black arrows and the loopbacks by the red arrows.  This graph is not needed for DSM creation, but is included here to illustrate information needed to create a DSM.

With the required information, a DSM can easily be created.  Using the same example, the DSM will look like this:

The DSM contains the same information as provided by the graph, but putting it in a matrix allow us to apply some tools that will help in our process improvement task.  Then, to do the task re-ordering, you just need to use a tool to “partition” the matrix.  Tools, such as PSM 32 and a DSM Excel Macro, can be found DSMweb.org.

The partitioned DSM will have the new ordering, like the one described in this article.  Analysis and recommendations can then be made based on the partitioned DSM.

Further Readings

  • “Complex Concurrent Engineering and the DSM Method” by Yassine and Braha 
  • “The Model Based Method for Organizing Product Development” by Steven D. Eppinger, Daniel E. Whitney, Robert P. Smith and David E. Gebala. 
  • “Generalized Model of Design Iterations Using Signal Flow Graphs” by Steven D. Eppinger, Murphy V Nukala, and Daniel E. Whitney.

Credits

This work is not solely of my own.  A lot of credits to my team mates Haibo Wang, Davit Tadevosyan and Kai Siang Teo.

DSM: A useful tool for process improvement efforts

by

Design Structure Matrix, or DSM in short, is a tool I frequently see during my year here at MIT.  It is often mentioned in “System Thinking” talks, as well as talks on designing complex system.  While the DSM’s uses are many, my project team mates and I focused on process improvement and successfully used the DSM to help our sponsor company improve its processes.  Our sponsor company is a aircraft maintenance, repair and overhaul business, and the process we focused on was the aircraft upgrading process, which spans from defining requirements for the upgrade, to drawing out the design, to implementation, to testing and finally to delivery.

How the DSM helped

1. Reduce long rework cycles – imagine the nightmare scenario where a project gets to almost completion, and then have to loopback to the beginning for reasons such as a major design error.  It is like the chutes and ladders game.  The DSM helps to reduce long reworks by reordering the tasks.  For example, in our project, initially there were four rework cycles that would set the project back by more than 20 tasks.  After the reordering, there were none.

2. Challenge the status quo task ordering, while respecting task dependencies – in the reordered task list for our project, we realized that a number of documentation tasks were pushed to the bottom of the list.  These tasks dealt with the development of internal test reports, flight manual and maintenance manual.

Initially, we thought that meant that the company should do those documentation tasks last.  However, on investigating further, we realized it was because no or very few other tasks depended on those tasks.  We thought about that further, and a revelation hit us: if no other tasks are waiting on those documents to be developed, does that mean that employees could develop those documents late and to the lowest quality but yet not affect the entire process in any way?  How can the company ensure the timeliness and quality of those documents?  Our sponsor validated that concern, and in the end, we recommended adding sign-offs of those documents to resolve this issue.

This is just one of the many examples.  The DSM challenged the status quo task ordering, in a way that respected the task dependencies, so the new ordering still made sense and provided ideas for how the current process might be done better.

3. Facilitate understanding of the current process
The DSM creation process required us to get our hands dirty into understanding the process.  We needed to think about what level of granularity we need to get down to, and what kinds of dependencies we should capture.  These activities helped us think more about the process, and thus added in our understanding.

In addition, the DSM also provided a visual map of the process.  At one glance, we could see which are the tasks that have many dependencies.

Additional Information about the DSM

For readers interested in finding out more about the DSM, I have included some basic information here.

DSM might seem rather technical and intimidating at first glance.  And that fear is well justified, as DSMs are matrices, a mathematical artifact that inspire fear into people’s heart by the mere mention of its name.  However, if you spend 10-15 understanding how it works, you will find DSM a useful tool to include in your toolbox for process improvement projects.

Creating the DSM

To use the DSM (for the purpose describe in the article), we have to provide three main pieces of information:
1. The list of tasks in the process.  For example, in the design phase, creating the high level design would be a possible task, and doing preliminary design review would be another possible task.
2. The dependencies between tasks.  This information will specify that for Task A to start, what tasks would need to be first completed.  For example, preliminary design review needs to be completed first before detailed design can commence.
3. Possible loopbacks.  This indicates scenarios where rework need to happen.  For example, after preliminary design review, the proposed design might be deem unsuitable and the project will need to go back to high level design.

These three pieces of information can be visualized in a graph like the following:

Here, the tasks are represented by the boxes, the task dependencies by the black arrows and the loopbacks by the red arrows.  This graph is not needed for DSM creation, but is included here to illustrate information needed to create a DSM.

With the required information, a DSM can easily be created.  Using the same example, the DSM will look like this:

The DSM contains the same information as provided by the graph, but putting it in a matrix allow us to apply some tools that will help in our process improvement task.  Then, to do the task re-ordering, you just need to use a tool to “partition” the matrix.  Tools, such as PSM 32 and a DSM Excel Macro, can be found DSMweb.org.

The partitioned DSM will have the new ordering, like the one described in this article.  Analysis and recommendations can then be made based on the partitioned DSM.

Further Readings

  • “Complex Concurrent Engineering and the DSM Method” by Yassine and Braha 
  • “The Model Based Method for Organizing Product Development” by Steven D. Eppinger, Daniel E. Whitney, Robert P. Smith and David E. Gebala. 
  • “Generalized Model of Design Iterations Using Signal Flow Graphs” by Steven D. Eppinger, Murphy V Nukala, and Daniel E. Whitney.

Credits

This work is not solely of my own.  A lot of credits to my team mates Haibo Wang, Davit Tadevosyan and Kai Siang Teo.

Categories Uncategorized

The Next Power Pairing: CIO and HRO

by

Guest post by Amaresh Tripathy and Zack Capozzi Many CIOs haven’t given much thought to the human resources department, but maybe they should. Here’s why: Talent management deficits are derailing CEO plans. In the PwC 2012 global CEO survey, one in four CEOs said, because of talent challenges, they couldn’t pursue a market opportunity or had to cancel or delay a strategic initiative. Moreover, one in three CEOs is concerned that skill shortages will impact […]

EA Professional Oath

by

The Center for the Advancement of the Enterprise Architecture Profession (CAEAP) has created something that on first sight seems like a very good idea: the Enterprise Architect Professional Oath. The oath itself is one of eight what they call “pillars” of the profession, though from the website it is not yet entirely clear what the […]

Het bericht EA Professional Oath verscheen eerst op Rob Vens.

Different Words Meant Different Things, Part 3

by

This is the final installment of a three-part series that discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship. To close, The Open Group’s Leonard Fehskens will consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture. Continue reading →

Different Words Mean Different Things, Part 2

by

This is a three-part series that discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship. This second installment will examine the effect of our definition of enterprise on how we think about EA. Continue reading →

Showrooming in the Knowledge Economy

by

In the knowledge economy, service providers often give away selected portions of their intellectual property, in the form of webinars, white papers, blogposts, free downloads or whatever. They then hope to generate revenue from other products and servi…

Basic is Best

by

Fellow foodies will recognize the recent movement towards “farm-to-table” restaurants. These venues attempt to simplify their menus and source ingredients as close to the source as possible. I had the opportunity to dine at such a restaurant the other evening. I was gushing about the appetizer to my server when she described the preparation for the item and then punctuated her comments with “basic is best”. I reminded my fellow enterprise architect diners there was an architecture lesson in that statement. They rolled their eyes and chuckled. But they also knew I was right.

I’m reminded of Frederick Brooks’ book The Mythical Man Month and his latest The Design of Design. The former must read book talks about complexity. But he refrains from damning all complexity. The world we live in and enterprises we strive to transform with enterprise architecture are complicated organisms, much like the human body. But sometimes a simple solution is the best approach. Fewer applications (think: portfolio rationalization). Fewer components. Fewer lines of code. Whatever level of abstraction you are working at, less is more.

I’m reminded of the enterprise architecture principle “Control Technical Diversity”. At one firm I created pithy catch phrases for each principles. I named this one “Less is More”. But perhaps another variation is what my server said the other night, “Basic is Best”.

Basic is Best

by

Fellow foodies will recognize the recent movement towards “farm-to-table” restaurants. These venues attempt to simplify their menus and source ingredients as close to the source as possible. I had the opportunity to dine at such a restaurant the other evening. I was gushing about the appetizer to my server when she described the preparation for the item and then punctuated her comments with “basic is best”. I reminded my fellow enterprise architect diners there was an architecture lesson in that statement. They rolled their eyes and chuckled. But they also knew I was right.

I’m reminded of Frederick Brooks’ book The Mythical Man Month and his latest The Design of Design. The former must read book talks about complexity. But he refrains from damning all complexity. The world we live in and enterprises we strive to transform with enterprise architecture are complicated organisms, much like the human body. But sometimes a simple solution is the best approach. Fewer applications (think: portfolio rationalization). Fewer components. Fewer lines of code. Whatever level of abstraction you are working at, less is more.

I’m reminded of the enterprise architecture principle “Control Technical Diversity”. At one firm I created pithy catch phrases for each principles. I named this one “Less is More”. But perhaps another variation is what my server said the other night, “Basic is Best”.

Should Shouldn’t Matter

by

An overly large focus on the way things “should be” is one of the biggest inhibitors to innovation and productive action. A focus on what should be rather than what can be inhibits new ideas and siphons off a tremendous amount of energy. Though this is a problem throughout most organizations, it seems to be […]

How to Measure a CIO’s Effectiveness

by

I was reading an interesting article about Issa’s move to refine and refresh the role of the CIO in the Federal sector.  It got me thinking about where we stand with the Clinger Cohen Act and how CIOs really should be measured for effectiveness. The Clinger Cohen Act is a functional description of what CIOs should be doing.  It says do X, Y, and Z.  It speaks very little to […]