DTU ProjectLab - User contributions [en-gb]

Design Structure Matrix and its application in project communication

2017-10-02T21:48:33Z

S161001.01: /* References */

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM. They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter (Browning, 2001). The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope for a future article.

[[File:DSM_table.png|600px]]

==The application process (in general)==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The thinking behind this application is that every product development project should focus on the certain critical points of contact between development teams.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager in the below can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program. This statement will become clear by reading the case.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. Note that 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Sosa et al, 2004; Havard Business Review). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were also critical for engine performance and a bit more difficult to anticipate as they sometimes did not reflect in the product architecture or specifications clearly. Any losses or failures in communication at this stage can be critical to the outcome of the project. For this purpose, the researchers proposed the application of DSMs to map out the situation in order to identify failure possibilities.

'''Identifying the design interfaces'''
Researchers started by working with the product architects to identify all the components and the interfaces between them. Theory and concepts in engineering design were applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix using a two devel dependency frame (strong or weak) .

[[File:Design_Interface_matrix.png|600px]]

'''Identifying the team interactions (communication interface)'''
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|600px]]

Lastly, the two matrices were overlaid to give the following alignment matrix in order to get insights into where planned communication failure could occur.

[[File:Alignment_matrix.png|600px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were still 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces, in particular, were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for something as small as a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews and other data collection methods to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. This could also be a role of the program/project management team. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated by all teams. This creates an awareness of the critical data along with knowledge about the communication network and points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The interaction between projects becomes a matter of interest in program management, especially to effectively manage a program. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs. These type of projects are also hard to generalize and hence difficult to apply the tool without sufficient investment of resources.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure boundaries are not clearly defined. While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. It, however, does have potential if used actively. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures.

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback systems on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar types of future projects and hence, is worth the resources. A manager can also now compare system architectures of previous systems which can greatly benefit the learning process and eventually designing of better communication management systems and organizational structures.

==References==
<references/>

# ''Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions'', Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''The Misalignment of Product Architecture and Organizational Structure in Complex Product Development'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, Management Science, Vol 50 December 2004, pp. 1674–1689
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, the article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# ''Engineering Design, A Systematic Approach'', Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# ''Integration analysis of product decompositions'', Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# ''Managing the Flow of Technology'', Allen, T. J. 1977, MIT Press, Cambridge, MA
# ''Network data and measurement'', Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# ''Identifying modular and integrative systems and their impact on design team interactions'', Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

[https://hbr.org/2007/11/are-your-engineers-talking-to-one-another-when-they-should]

Design Structure Matrix and its application in project communication

2017-10-02T21:48:11Z

S161001.01:

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM. They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter (Browning, 2001). The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope for a future article.

[[File:DSM_table.png|600px]]

==The application process (in general)==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The thinking behind this application is that every product development project should focus on the certain critical points of contact between development teams.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager in the below can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program. This statement will become clear by reading the case.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. Note that 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Sosa et al, 2004; Havard Business Review). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were also critical for engine performance and a bit more difficult to anticipate as they sometimes did not reflect in the product architecture or specifications clearly. Any losses or failures in communication at this stage can be critical to the outcome of the project. For this purpose, the researchers proposed the application of DSMs to map out the situation in order to identify failure possibilities.

'''Identifying the design interfaces'''
Researchers started by working with the product architects to identify all the components and the interfaces between them. Theory and concepts in engineering design were applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix using a two devel dependency frame (strong or weak) .

[[File:Design_Interface_matrix.png|600px]]

'''Identifying the team interactions (communication interface)'''
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|600px]]

Lastly, the two matrices were overlaid to give the following alignment matrix in order to get insights into where planned communication failure could occur.

[[File:Alignment_matrix.png|600px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were still 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces, in particular, were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for something as small as a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews and other data collection methods to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. This could also be a role of the program/project management team. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated by all teams. This creates an awareness of the critical data along with knowledge about the communication network and points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The interaction between projects becomes a matter of interest in program management, especially to effectively manage a program. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs. These type of projects are also hard to generalize and hence difficult to apply the tool without sufficient investment of resources.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure boundaries are not clearly defined. While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. It, however, does have potential if used actively. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures.

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback systems on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar types of future projects and hence, is worth the resources. A manager can also now compare system architectures of previous systems which can greatly benefit the learning process and eventually designing of better communication management systems and organizational structures.

==References==
<references/>

# ''Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions'', Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# '''The Misalignment of Product Architecture and Organizational Structure in Complex Product Development''', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, Management Science, Vol 50 December 2004, pp. 1674–1689
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, the article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# ''Engineering Design, A Systematic Approach'', Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# ''Integration analysis of product decompositions'', Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# ''Managing the Flow of Technology'', Allen, T. J. 1977, MIT Press, Cambridge, MA
# ''Network data and measurement'', Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# ''Identifying modular and integrative systems and their impact on design team interactions'', Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

[https://hbr.org/2007/11/are-your-engineers-talking-to-one-another-when-they-should]

Design Structure Matrix and its application in project communication

2017-10-02T21:43:44Z

S161001.01:

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM. They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter (Browning, 2001). The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope for a future article.

[[File:DSM_table.png|600px]]

==The application process (in general)==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The thinking behind this application is that every product development project should focus on the certain critical points of contact between development teams.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager in the below can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program. This statement will become clear by reading the case.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. Note that 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Sosa et al, 2004; Havard Business Review). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were also critical for engine performance and a bit more difficult to anticipate as they sometimes did not reflect in the product architecture or specifications clearly. Any losses or failures in communication at this stage can be critical to the outcome of the project. For this purpose, the researchers proposed the application of DSMs to map out the situation in order to identify failure possibilities.

'''Identifying the design interfaces'''
Researchers started by working with the product architects to identify all the components and the interfaces between them. Theory and concepts in engineering design were applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix using a two devel dependency frame (strong or weak) .

[[File:Design_Interface_matrix.png|600px]]

'''Identifying the team interactions (communication interface)'''
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|600px]]

Lastly, the two matrices were overlaid to give the following alignment matrix in order to get insights into where planned communication failure could occur.

[[File:Alignment_matrix.png|600px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were still 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces, in particular, were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for something as small as a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews and other data collection methods to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. This could also be a role of the program/project management team. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated by all teams. This creates an awareness of the critical data along with knowledge about the communication network and points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The interaction between projects becomes a matter of interest in program management, especially to effectively manage a program. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs. These type of projects are also hard to generalize and hence difficult to apply the tool without sufficient investment of resources.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure boundaries are not clearly defined. While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. It, however, does have potential if used actively. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures.

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback systems on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar types of future projects and hence, is worth the resources. A manager can also now compare system architectures of previous systems which can greatly benefit the learning process and eventually designing of better communication management systems and organizational structures.

==References==
<references/>

# '"Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions"', Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# '''The Misalignment of Product Architecture and Organizational Structure in Complex Product Development''', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, Management Science, Vol 50 December 2004, pp. 1674–1689
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, the article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

[https://hbr.org/2007/11/are-your-engineers-talking-to-one-another-when-they-should]

Design Structure Matrix and its application in project communication

2017-10-02T21:41:15Z

S161001.01:

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM. They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter (Browning, 2001). The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope for a future article.

[[File:DSM_table.png|600px]]

==The application process (in general)==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The thinking behind this application is that every product development project should focus on the certain critical points of contact between development teams.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager in the below can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program. This statement will become clear by reading the case.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. Note that 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Sosa et al, 2004; Havard Business Review). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were also critical for engine performance and a bit more difficult to anticipate as they sometimes did not reflect in the product architecture or specifications clearly. Any losses or failures in communication at this stage can be critical to the outcome of the project. For this purpose, the researchers proposed the application of DSMs to map out the situation in order to identify failure possibilities.

'''Identifying the design interfaces'''
Researchers started by working with the product architects to identify all the components and the interfaces between them. Theory and concepts in engineering design were applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix using a two devel dependency frame (strong or weak) .

[[File:Design_Interface_matrix.png|600px]]

'''Identifying the team interactions (communication interface)'''
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|600px]]

Lastly, the two matrices were overlaid to give the following alignment matrix in order to get insights into where planned communication failure could occur.

[[File:Alignment_matrix.png|600px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were still 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces, in particular, were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for something as small as a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews and other data collection methods to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. This could also be a role of the program/project management team. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated by all teams. This creates an awareness of the critical data along with knowledge about the communication network and points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The interaction between projects becomes a matter of interest in program management, especially to effectively manage a program. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs. These type of projects are also hard to generalize and hence difficult to apply the tool without sufficient investment of resources.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure boundaries are not clearly defined. While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. It, however, does have potential if used actively. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures.

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback systems on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar types of future projects and hence, is worth the resources. A manager can also now compare system architectures of previous systems which can greatly benefit the learning process and eventually designing of better communication management systems and organizational structures.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''The Misalignment of Product Architecture and Organizational Structure in Complex Product Development'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, Management Science, Vol 50 December 2004, pp. 1674–1689
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, the article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

[https://hbr.org/2007/11/are-your-engineers-talking-to-one-another-when-they-should]

Articles Fall Term 2017

2017-10-02T21:24:47Z

S161001.01: /* Overview of 2017 Wiki articles */

{| class="wikitable"
|+ '''Disclaimer!
|-
|''The requirements for the articles written in previous Terms (2014, 2015, 2016, Jun 2017) were not the same as for Fall Term 2017. Please make sure you read the requirements for your own fall term carefully before starting your wiki article.''
|}

Please complete this table with your group number, full name, username and the title of your article.

To create more lines in the table click '''Edit''' and use the following code to create more lines in the table and replace the example text with your own information:

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word;">
|-
|Group Number
|First Name
|Last Name
|Username
|Link to Article
|-
</pre>
Create a direct link by making square brackets ([[ ]]) around the title such as [[Title]]

The straight lines ( | ) create columns and the straight line with a dash ( |- ) creates a new row in the table.

( |} ) is only used at the very end to finish the coding for the table.

=Overview of 2017 Wiki articles=

{| class="wikitable sortable"
|+June 2017 Wiki Articles
|-
!Group number
!First name
!Second name
!User name
!Link to article
|-
|8
|Malyn
|Jørgensen
|Malyn
|[[Construction Contract Management Guidelines and Administration]]
|-
|4
|Javier
|Durá María
|Jaduma
|[[Delphi Method (expert for identification)]]
|-
|2
|Cornelis Johannes
|Jongenelen
|CJJongenelen
|[[Stage-Gate Process]]
|-
|4
|Waqas
|Khalid
|waqaskhld
|[[Concept of Risk Quantification and Methods used in Project Management]]
|-
|9
|Thomas
|Reigstad
|Thomas Reigstad
|[[Quality Control in Construction]]
|-
|GN
|Karlotta
|Thorhallsdóttir
|S162285
|[[Impact and Probability in Risk Assessment]]
|-
|GN
|Guillermo
|Altuna Faus
|Galtunaf
|[[RAPID Outcome Mapping Approach (ROMA)]]
|-
|4
|Bjarke
|Schjødt Rasmussen
|Schjodt92
|[[Project Performance Management Scorecard]]
|-
|8
|Marion
|Chambon
|s172284
|[[HAZOP method, deviation analysis]]
|-
|8
|Davide
|Morbin
|Davide
|[[Kaizen Week]]
|-
|GN
|Ignacio
|López Cabañas
|S161357
|[[PERT]]
|-
|7
|Leon David
|Schleer
|LeonS
| [[Project Manager Competencies and Personality Types]]
|-
|GN
|Pascal
|Trebin
|Pascal
|[[Kano model]]
|-
|2
|Michael Kirkeby
|Hansen
|Mikirkeby
|[[Scenario Analysis]]
|-
|7
|Julian
|Ofenstein
|Bekis
|[[Waterfall vs. Agile Methodology]]
|-
|1
|Kamma
|Christensen
|Kamma
|[[Change order]]
|-
|5
|Alexandra
|Darmaraki
|s162578
|[[Scenario Planning Strategy]]
|-
|3
|Eyðbjørg Amanda
|Petersen
|EAP
|[[Feasibility Study]]
|-
|5
|Iason
|Divanis
|Iason Divanis
|[[Dynamic Systems Development Method(DSDM)]]
|-
|2
|Signe
|Risager
|s163071
|[[Teamweek (virtual resource management tool)]]
|-
|11
|Erik A.
|Heggstad
|Erikheggstad
|[[Stage-Gate Model]]
|-
|GN
|Philip
|van Berkom
|PA
|[[Contingency]]
|-
|GN
|Apostolos
|Bougas
|S162469
|[[Decision Tree]]
|-
|11
|Paolo
|Meneghini
|Paolo M
|[[The procurement process]]
|-
|3
|Ragnheidur
|Ragnarsdottir
|S161269
|[[Benefits Map]]
|-
|3
|Thorunn Sif
|Ingimundardottir
|Thorunn
|[[MBTI]]
|-
|2
|Sophie Emilie
|Smietana
|SophieEmilie
|[[Agile Methodology]]
|-
|5
|Thomas
|Engelhart
|Engelhart
|[[DICE Framework]]
|-
|3
|Nathalie Lückstädt
|Nielsen
|S130038
|[[Scope creep]]
|-
|11
|Eleni
|Pagoni
|Ele
|[[The Stage-Gate Model]]
|-
|11
|Konstantinos
|Vontas
|Konstantinos
|[[Project Control]]
|-
|5
|Emmanouil
|Psomas
|Manolis
|[[Decision-making skills in project management]]
|-
|GN
|Ingvild Reine
|Assmann
|Ingvild Assmann
|[[Muda, Mura and Muri]]
|-
|-
|11
|Javier
|Gumà
|S161631
|[[Simon's four levels of control]]
|-
|-
|GN
|Christina Diget
|Christiansen
|S160541
|[[Lean Construction on Bispebjerg Bakke]]
|-
|-
|10
|Nikoleta
|Kolitsopoulou - Maridaki
|Nikoletta
|[[Roles and responsibilities]]
|-
|-
|7
|Matthis
|Hanstein
|Matthis
|[[Communication with public stakeholders on the femern link project in Germany]]
|-
|-
|6
|Patrick
|Grimm
|S161459
|[[SMART goals in project planning and performance management]]
|-
|-
|7
|John
|Gomes
|S161001
|[[Design Structure Matrix and its application in project communication]]
|-
|-
|6
|Hani
|Selim
|s135278
|[[Project Scope Control]]
|-
|-
|9
|Anders Stig
|Pedersen
|S124052
|[[Project Network Diagram]]
|-
|-
|10
|Timokleia
|Orfanidou
|S155592
|[[Situational Leadership II]]
|-
|-
|4
|Gudmann
|Tommy
|tg_dk
|[["Interpersonal skills of a Project Manager"]]
|-
|-
|4
|Gudjon
|Arngrimsson
|Gudjon
|[[Expectations Management]]
|-
|-
|6
|Victor
|Aguasca Lloberes
|S161321
|[[Performance Measurement and Performance Management]]
|-
|3
|Asger
|Fuhr Høyer
|Asger
|[[Antifragility]]
|-
|1
|Klavs
|Skovby
|Klask
|[[Decision Tree: Risk & Opportunities]]
|-
|1
|Nicolaj J. B.
|Thomsen
|Kittymaumau
|[[Pro-active: Risk and Opportunity Management]]
|-
|-
|7
|Laurens M.
|van der Schaft
|s172077
|[[Implementation of BIM as communication tool for construction site operations]]
|-
|-
|8
|Thuritha
|Ravindran
|s123252
|[[Digitalisation of the construction industry ]]
|-
|-
|GN
|Rune
|Nedergaard
|RRN
|[[Case Study: Updating Airplane Tracking Systems in the Australian Defense Force]]
|-
|11
|Ioanna-Eleni
|Vasilopoulou
|Ioanna-Eleni Vasilopoulou
|[[Balanced Scorecard in Project Portfolio Management]]
|-
|6
|Maria
|Barba Garcia
|MariaB
|[[Omnichannel strategy]]
|-
|1
|Frederik Lybek
|Lind
|Frederik Lind
|[[Decision tree]]
|-
|1
|Alisha
|Patnaik
|Alisha.patnaik
|[[Critical Path Method (CPM)]]
|-
|6
|Patricia
|Máñez Aleixandre
|Patriciamanez
|[[Schein's model of organizational culture]]
|-
|4
|Niels
|Mikkelsen
|Niels
|[[Servant Leadership]]
|-
|GN
|Einar
|Loktu
|ELoktu
|[[Lean construction, takt time planning]]
|-
|-
|10
|Edvinas
|Zamaratskis
|Edvinas
|[[Risk tolerances]]
|-
|-
|2
|Lea
|Glahn Christiansen
|LeaGlahn
|[[Jung's personality Theory]]
|-
|2
|Karoline
|Holm Hansen
|Karoline
|[[Fishbone diagram]]
|-
|9
|Thomas
|Sotiriadis
|ThomasSot
|[[Theory of Constrains Manufacturing Systems]]
|-
|9
|Rick
|Kool
|Rick Kool
|[[Collaborative_Tendering]]
|-

Design Structure Matrix and its application in project communication

2017-10-02T21:17:41Z

S161001.01:

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM. They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter (Browning, 2001). The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope for a future article.

[[File:DSM_table.png|600px]]

==The application process (in general)==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The thinking behind this application is that every product development project should focus on the certain critical points of contact between development teams.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager in the below can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program. This statement will become clear by reading the case.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. Note that 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Sosa et al, 2004; Havard Business Review). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were also critical for engine performance and a bit more difficult to anticipate as they sometimes did not reflect in the product architecture or specifications clearly. Any losses or failures in communication at this stage can be critical to the outcome of the project. For this purpose, the researchers proposed the application of DSMs to map out the situation in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|600px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|600px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|600px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.
While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''The Misalignment of Product Architecture and Organizational Structure in Complex Product Development'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, Management Science, Vol 50 December 2004, pp. 1674–1689
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

[https://hbr.org/2007/11/are-your-engineers-talking-to-one-another-when-they-should]

Design Structure Matrix and its application in project communication

2017-10-02T21:16:54Z

S161001.01:

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM. They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter (Browning, 2001). The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope for a future article.

[[File:DSM_table.png|600px]]

==The application process (in general)==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The thinking behind this application is that every product development project should focus on the certain critical points of contact between development teams.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager in the below can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program. This statement will become clear by reading the case.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. Note that 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Sosa et al, 2004; Havard Business Review). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were also critical for engine performance and a bit more difficult to anticipate as they sometimes did not reflect in the product architecture or specifications clearly. Any losses or failures in communication at this stage can be critical to the outcome of the project. For this purpose, the researchers proposed the application of DSMs to map out the situation in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|800px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|800px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|800px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.
While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''The Misalignment of Product Architecture and Organizational Structure in Complex Product Development'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, Management Science, Vol 50 December 2004, pp. 1674–1689
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

[https://hbr.org/2007/11/are-your-engineers-talking-to-one-another-when-they-should]

Design Structure Matrix and its application in project communication

2017-10-02T20:52:44Z

S161001.01:

Every big project or program involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This often results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships in projects is by ensuring that the people/teams are communicating the right information at the right time. But in order to do that, it is first and foremost necessary to understand the network and the interdependency between people/teams. This is where the tool Design Structure Matrix can come in handy.

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. Using Pratt and Whitney’s PW4098 engine development as a case, the application of DSM as an Alignment Matrix is explained. The application of both Design Structure Matrix and Alignment Matrix is finally reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes, and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.png|600px]]

==The application process in general==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|800px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|800px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|800px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.
While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:43:50Z

S161001.01: /* Critical reflection */

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.png|600px]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|800px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|800px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|800px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.
While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:43:07Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.png|600px]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|800px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|800px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|800px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

'''Limitations'''
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

'''Advantages'''
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:41:10Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.png|600px]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|800px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|800px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|800px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

File:Alignment matrix.png

2017-10-02T20:40:35Z

S161001.01:

File:Team interaction-matrix.png

2017-10-02T20:40:08Z

S161001.01:

File:Design Interface matrix.png

2017-10-02T20:39:34Z

S161001.01:

File:DSM table.png

2017-10-02T20:38:18Z

S161001.01:

Design Structure Matrix and its application in project communication

2017-10-02T20:37:39Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.png|600px]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.png|1000px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.png|1000px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.png|1000px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

File:DSM configurations.png

2017-10-02T20:36:05Z

S161001.01:

Design Structure Matrix and its application in project communication

2017-10-02T20:35:32Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|400px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg|1000px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg|1000px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg|1000px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:35:16Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|600px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|600px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg|1000px]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg|1000px]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg|1000px]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:34:20Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|200px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|600px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|200px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:33:54Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|200px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png|200px]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.png|200px]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:33:13Z

S161001.01: /* Concept/Theory */

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|200px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.png]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

File:Diagraph configurations.png

2017-10-02T20:32:13Z

S161001.01:

Design Structure Matrix and its application in project communication

2017-10-02T20:31:04Z

S161001.01: /* Description of the tool */

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|200px]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.jpg]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:29:46Z

S161001.01: /* Description of the tool */

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png|200px|thumb|left|alt text]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.jpg]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:26:31Z

S161001.01: /* Description of the tool */

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.png]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.jpg]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:25:41Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File:DSM_example.gif‎]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.jpg]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

File:DSM example.png

2017-10-02T20:22:53Z

S161001.01:

Design Structure Matrix and its application in project communication

2017-10-02T20:21:23Z

S161001.01:

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File: DSM_example.gif‎]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.jpg]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Design_Interface_matrix.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Team_interaction-matrix.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Alignment_matrix.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Design Structure Matrix and its application in project communication

2017-10-02T20:19:08Z

S161001.01: Created page with "In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within prog..."

In this article, the tool Design Structure Matrix (DSM) is explained. The theoretical concepts and applications are explored with a focus on the application of DSM within program management. will be studied in one such case in the development of the Pratt and Whitney’s PW00000 engine. The application of the tool will then be reflected upon from a program management perspective drawing on insights on how projects communicate and coordinate within a program.

==Description of the tool==

Design Structure Matrix or DSM is a compact, matrix representation of a system or project. The tool has existed in graph theory before, but work by Tyson R. Browning (2001) and Ali Yassine (2003) in fields of systems engineering and project management has made this tool a subject of interest and relevance in this course. While many of the tools like Gantt charts and PERT allow sequential modeling of processes, they do not address interdependencies, especially when it comes to complex product development projects (A. Yassine). DSM is a powerful tool that helps visualize these interactions, exchange of information and dependency patterns between sub-systems. There are two types of DSMs, static and time-based. Elements like components of product architecture and groups in an organization are examples of static DSM while time-based activities with precedence conditions constitute time-based DSMs. The tool can be implemented on an IT platform or it could be a simple Excel sheet or paper. Four basic types of interdependency data can be represented on a DSM (Browning, 2001, manually referenced from staff.aub). They can represent information relations among components of a product, teams working on a project, activities or tasks and parameter. The subsystems or elements are filled in the row and column headers of the table and the interdependency data are then mapped onto the matrix like the figure below.

[[File: DSM_example.gif‎]]

==Concept/Theory==

Understanding complex systems like products, processes and organizations can be a challenge. Interdependencies between subsystems (elements) can often be difficult to show or document and can be the causes of system behaviors. A classical approach to understanding complex systems is to model it by breaking it down into subsystems which are easier to comprehend. Those same interdependencies seem much more clear and easy to grasp when modeled or mapped on a matrix cause of the simple and graphical nature of a matrix. Besides, the tool is compact and systematic which makes it easy to use no matter the size of the system.

For better understanding, consider a simple two element system, with elements “A” and “B”. Those two elements can have the following three interdependency configurations. Either they both function in parallel and are concurrent systems, or one system element is dependent on another or finally, or the system elements are coupled and are interdependent. If these configurations are to be modeled on a directed graph (diagraph) with nodes as the system elements and directed links (arrows) showing interdependencies, then they can be modeled as shown below.

[[File:Diagraph_configurations.jpg]]

However, if these same three configurations were to be represented by a matrix, then it could be done in a binary square where 1 (or a mark like a dot or X) marks the dependency of an element in the row to the corresponding element in the column at the intersection.

[[File:DSM_configurations.jpg]]

Considering that most systems have several elements, the matrix structure appears to be a practical and applicable tool as discussed above. Additionally, the data representation within cells of a matrix can be adapted to show varying degrees of dependency.

==Purpose==

Below, is a whole range of applications of the tool corresponding to the data types ranging from performing system analysis to systems design. This article will be focusing on an application in performing system analysis. Team-based and component-based DSM types are static DSMs and are usually analyzed with clustering algorithms. A detailed explanation of clustering can be found in the reference ( T. U. Pimmler, S. D. Eppinger, "Integration Analysis of Product Decompositions", Proc. ASME 6th Int. Conf. on Design Theory and Methodology, 1994.)
and can be the scope of an article in the future.

[[File:DSM_table.jpg]]

==Application==

==The application concept==

A recently developed new application of DSM is an Alignment Matrix. It was developed in the field of product development to aid managers between different sub-component development teams in identifying key areas where planned communication failures could occur. This was done by overlaying a team-based (team interactions) DSM and a component-based (design interface) DSM. The uncommon areas after overlaying reveal the unattended and unidentified interfaces of technical communication. The idea behind this application is that every product development project should focus on the certain critical points of contact between developments teams (PRATT REF) in order for a project to be successful.

[[File: Alignment_Matrix.gif‎]]

This application comes under the “performing system analysis” category and will be discussed in this article. It is chosen because of the program management perspective that can be reflected upon, drawing on insights on how projects communicate and coordinate within a program. The product development manager can be seen as or compared to the program manager with the different sub-component development teams as mini-projects under the same program.

==The application elaborated through a case example==

The application of Alignment Matrix was developed during a case study of Pratt and Whitney’s development of the engine PW4098. Like any complex product, the engine was divided into 8 components which were further subdivided into 5 to 10 sub-components. 6 out of the 8 systems were considered modular. That made up a total of 54 component development teams, each having its own design and development team (Details from the case article). Besides these, there were 6 system integration teams who were responsible for the engine as a whole. While each team had to develop their own component, it was also necessary to integrate the designs with that of other components. Sometimes, the links between components were not just physical but involved an exchange of either energy (heat, vibrations) or a media like fuel or air. These links were critical for engine performance and more difficult to communicate as they built many times on assumptions and often did not reflect in the product architecture. Any losses or failures in communication at this stage can be critical to the success of the project. For this purpose, the researchers utilized DSMs to map out stuff in order to identify failure possibilities.

Identifying the design interfaces
Researchers started by working with the product architects to identify all the components and the interfaces between them. Research in engineering design was applied to identify types of design dependencies which included spatial, material and energy-related as well as various levels of criticality. (Pahl and Beitz 1991, Pimmler and Eppinger 1994, Sosa et al. 2003). These dependencies were mapped in the below design interaction matrix.

[[File:Example.jpg]]

Identifying the team interactions (communication interface)
Key members of teams were interviewed for information on parameters like frequency and criticality of technical communications (Allen 1977, Marsden 1990). They were even asked about their anticipation of information from other teams. Note that in this process, teams were not made aware of design matrix in order to avoid biases during analysis. In addition to that, 57 of the 60 teams were surveyed for additional technical communication interactions. Finally, all these interactions were mapped on a binary scale as shown below. Note that the 6 system integration teams are not mapped as they interact with all teams and responsible for the coordination themselves.

[[File:Example.jpg]]

Lastly, the two matrices were overlaid to give the following alignment matrix

[[File:Example.jpg]]

Some interesting findings from the case.
Even though Pratt made efforts to have special Component Requirement Documents (CRD) with the intentions of design optimization and encouraged cross-boundary interactions, there were 220 (39% of the 569 design interfaces) unmatched design interfaces and 74 (17% of the 423 team interactions) unmatched team interaction.
While most of the missed interfaces were not critical, two interfaces in particular were. Their costs have varied with time, with one accounting to 1 to 2 percent of development costs and three to four months in project delays. That can be considered as a huge loss for a communication failure.

==Critical reflection==

In theory, the application of the tool is pretty straightforward and simple. In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. This process can be time-consuming as it involves a lot of data processing in order to carry out accurate mapping.

The study recommends assignment of resources to pay attention to these interfaces. Another approach or rather a complementary approach is to have the matrices as live documents which can be updated. This creates an awareness of the critical data along with the communication points.

If a program is considered a system, then the projects within the program become the elements of the matrix. The projects will obviously have some communication interfaces with each other that will be required to be mapped and managed for the program to reach its objectives and be a success. The difference though is that unlike the design interface in product development, the functional interface may be more complex or vague between projects especially in Organizational Change Programs and Societal Programs.

limitations:
Identifying the interfaces can be a challenge especially when you have the cross-functional team with people working in multiple teams or where the organizational structure is not clearly defined.

While the tool is useful in giving key communication failure insights, it does not necessarily benefit the current project, especially when applying it for the first time. Hence, it may not improve the current communication challenges of a project.

Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves lengthy data collection and processing procedures

Advantages
The alignment matrix tool could be a good complementary tool to feedback surveys and reviews on how effectively the communication system has been designed and implemented. It also helps create an awareness about the vital communication points which could set the path for critical thinking while designing future organizational structures. It also does massively improve communication in similar future projects and hence, is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# "Applying the Design Structure Matrix to System Decomposition and Integration problems: A Review and New Directions", Browning, T., IEEE Transactions on Engineering Management, Vol.48, No. 3, August 2001.
# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, article from Harvard Business Review.
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine.
# “Applying the design structure matrix to system decomposition and integration problems: a review and new directions”, T.R Browning
# "Engineering Design, A Systematic Approach", Pahl, G., W. Beitz. 1991, Springer-Verlag, New York,
# "Integration analysis of product decompositions", Pimmler, T. U., S. D. Eppinger. 1994, Proc. ASME Design Theory Methodology Conf., DE-Vol. 68, 343–351.
# "Managing the Flow of Technology", Allen, T. J. 1977, MIT Press, Cambridge, MA
# "Network data and measurement", Marsden, P. V. 1990, Ann. Rev. Sociology 16 435-463.
# "Identifying modular and integrative systems and their impact on design team interactions", Sosa, M. E., S. D. Eppinger, C. M. Rowles. 2003, J. Mech. Design 125(2) 240–252.

Application of Alignment Matrix in Project Coordination and Communication

2017-09-28T09:47:35Z

S161001.01:

Every big project involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships is ensuring that the people/teams are communicating effectively. In order to do that, it is first and foremost necessary to understand the network and the interdependency between teams. This is where the tool Alignment Matrix plays a role.

This aim of this article is to explain the tool and its applications. It will draw upon the key findings from the Pratt and Whitney project in order to provide Project Managers with insights by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. Lastly, the advantages and limitations will be reflected upon.

==Background of the tool==

An Alignment Matrix is a recently developed new application of a project management tool, Design Structure Matrix (DSM). DSM is nothing but a compact, matrix representation of a system or project. It is a powerful tool that helps visualize the interactions, exchange of information and dependency patterns between sub-systems (INSERT REF). Thereby, allowing to carry out analysis, project planning, and organizational design.

It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. The idea is to enable This is possible by mapping unattended and unidentified interfaces of technical communication. The application was primarily developed in a product development context based on the study of Pratt and Whitney’s development of their jet engine PW4098. The development of a jet engine, just like most sophisticated products, involves several sub-teams working on different components that make up the engine. In the PW4098 case, there were 54 sub components, each having its own design and developemnt team.

==Applications in Project Management==

In theory, the application of the tool is pretty straightforward and simple. All it involves is mapping first the areas in the matrix where communication should be occurring. Secondly, mapping the areas where communication is actually taking place. Finally, overlapping the two to find areas which are not common to both matrices. Those areas indicate the planned communication that is failing to take place or unplanned communication which should have been aware of.

[[File: Alignment_Matrix.gif‎]]

In practice, however, the above theory translates into massive amounts of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. They followed the below steps.

The first step in the process of applying the tool is having the system architect identify and list all the different subsystems and their interdependencies involved. The next step is to create a matrix where those interdependencies are then mapped. For the application discussed here, the system architect would most likely be the project manager or the management team that put together the project. It is here, where the data collection is required to complete the mapping process.

The last step is aligning the two matrices to conduct the analysis of unplanned and unidentified communication. The outcome is an excellent graphical representation of how well communication activities are taking place and provides the insights into where the focus should be directed in order to improve the project functioning.

==Critical reflection==

limitations: Identifying the different teams in order to create the matrix can be a challenge especially when you have people working in multiple groups or where the organizational structure is not clearly defined. It does not necessarily benefit the current project and hence it may not improve the current communication challenges of a project. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves interviews with different team members.
It does not necessarily the linkage to the organizational structure and hence causes for communication may not necessarily be identified.

Advantages
This tool could be a good complementary tool to feedback surveys and reviews. It, however, does create an awareness about the vital communication points which could set the path for critical thinking while sharing information. It also does massively improve communication in similar projects in the future and hence from a portfolio point of view, it is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger and Craig M. Rowles, article from Harvard Business Review,
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T21:11:50Z

S161001.01:

Every big project involves a large diverse group of people working and collaborating together towards common objectives, goals or deliverables. This results in complex relationships of tasks and people. One of the key aspects of managing such complex relationships is ensuring that the people/teams are communicating effectively. In order to do that, it is first and foremost necessary to understand the network and the interdependency between teams. This is where the tool Alignment Matrix plays a role.

This aim of this article is to explain the tool and its applications. It will draw upon the key findings from the Pratt and Whitney project in order to provide Project Managers with insights by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. Lastly, the advantages and limitations will be reflected upon.

==Background of the tool==

An Alignment Matrix is a recently developed new application of a project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This is possible by mapping unattended and unidentified interfaces of technical communication. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

In order to understand the application of Alignment Matrix, it is necessary to understand a bit more about Design Structure Matrix (DSM) and its working. DSM is a compact, matrix representation of a system or project. It is a powerful tool that helps visualize the interactions, exchange of information and dependency patterns between sub-systems. Thereby, allowing to carry out analysis, project planning, and organizational design.

==Applications in Project Management==

In theory, the application of the tool is pretty straightforward and simple. All it involves is mapping first the areas in the matrix where communication should be occurring. Secondly, mapping the areas where communication is actually taking place. Finally, overlapping the two to find areas which are not common to both matrices. Those areas indicate the planned communication that is failing to take place or unplanned communication which should have been aware of.

[[File: Alignment_Matrix.gif‎]]

In practice, however, the above theory translates into massive amount of data collection in order to be able to fill up the two matrices. Researchers, who developed this tool used interviews to collect this data. They followed the below steps.

The first step in the process of applying the tool is having the system architect identify and list all the different subsystems and their interdependencies involved. The next step is to create a matrix where those interdependencies are then mapped. For the application discussed here, the system architect would most likely be the project manager or the management team that put together the project. It is here, where the data collection is required to complete the mapping process.

The last step is aligning the two matrices to conduct the analysis of unplanned and unidentified communication. The outcome is an excellent graphical representation of how well communication activities are taking place and provides the insights into where the focus should be directed in order to improve the project functioning.

==Critical reflection==

Disadvantages: Identifying the different teams in order to create the matrix can be a challenge especially when you have people working in multiple groups or where the organizational structure is not clearly defined. It does not necessarily benefit the current project and hence it may not improve the current communication challenges of a project. Applying the tool can be a tedious task of noting all the departments, identifying interfaces, plotting and so on and will mostly require the time of the system designer which is many cases is the project manager. It is also intensive on resources as it involves interviews with different team members.

Advantages
This tool could be a good complementary tool to feedback surveys and reviews. It, however, does create an awareness about the vital communication points which could set the path for critical thinking while sharing information. It also does massively improve communication in similar projects in the future and hence from a portfolio point of view, it is worth the resources. It also provokes managers to be more critical in deciding the information to share with adjacent departments.

==References==
<references/>

# ''Are Are Your Engineers Talking to One Another When They Should?'', Manuel E. Sosa, Steven D. Eppinger and Craig M. Rowles, article from Harvard Business Review,
# ''An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method'', Ali A. Yassine

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T21:02:30Z

S161001.01: /* Critical reflection */

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T20:29:02Z

S161001.01:

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T20:26:12Z

S161001.01:

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T20:25:38Z

S161001.01:

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T20:23:48Z

S161001.01:

File:Alignment Matrix.gif

2017-09-22T20:20:50Z

S161001.01:

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T20:13:59Z

S161001.01: /* References */

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T19:09:25Z

S161001.01: /* Critical reflection */

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T18:49:23Z

S161001.01:

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T17:32:52Z

S161001.01:

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T17:18:52Z

S161001.01: /* Background about the topic */

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. It will be done by reflecting on a process setup project in a company in India. The aim is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Background about the topic==

In order to understand the application of Alignment Matrix, it is necessary to understand a bit about Design Structure Matrix (DSM) and its working. DSM is a compact, matrix representation of a system or project. It is a powerful tool that helps visualize the interactions, exchange of information and dependency patterns between sub-systems. Thereby, allowing to carry out analysis, project planning, and organizational design.

==Applications in Project Management==

==Critical reflection==

==References==

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T17:18:31Z

S161001.01: /* Background about the topic */

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T17:18:18Z

S161001.01: /* Background about the tool */

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. It will be done by reflecting on a process setup project in a company in India. The aim is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Background about the topic==
In order to understand the application of Alignment Matrix, it is necessary to understand a bit about Design Structure Matrix (DSM) and its working. DSM is a compact, matrix representation of a system or project. It is a powerful tool that helps visualize the interactions, exchange of information and dependency patterns between sub-systems. Thereby, allowing to carry out analysis, project planning, and organizational design.

==Applications in Project Management==

==Critical reflection==

==References==

Application of Alignment Matrix in Project Coordination and Communication

2017-09-22T17:17:47Z

S161001.01: /* Introduction and background */

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. It will be done by reflecting on a process setup project in a company in India. The aim is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Background about the tool==

In order to understand the application of Alignment Matrix, it is necessary to understand a bit about Design Structure Matrix (DSM) and its working. DSM is a compact, matrix representation of a system or project. It is a powerful tool that helps visualize the interactions, exchange of information and dependency patterns between sub-systems. Thereby, allowing to carry out analysis, project planning, and organizational design.

==Applications in Project Management==

==Critical reflection==

==References==

Application of Alignment Matrix in Project Coordination and Communication

2017-09-18T06:41:30Z

S161001.01:

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. It will be done by reflecting on a process setup project in a company in India. The aim is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Introduction and background==

===Key findings===

==Applications in Project Management==

==Critical reflection==

==References==

Application of Alignment Matrix in Project Coordination and Communication

2017-09-17T20:45:21Z

S161001.01:

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. The aim is to study is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Introduction and background==

===Key findings===

==Applications in Project Management==

==Critical reflection==

==References==

Application of Alignment Matrix in Project Coordination and Communication

2017-09-17T20:43:10Z

S161001.01: /* Key learnings (Solution) */

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. The aim is to study is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Introduction and background==

==Key learnings==

==Applications in Project Management==

==Critical reflection==

==References==

Application of Alignment Matrix in Project Coordination and Communication

2017-09-17T20:42:48Z

S161001.01:

An Alignment Matrix is a recently developed new application of an old project management tool, Design Structure Matrix (DSM). It was developed to aid managers between different sub-system development teams in identifying key areas where planned communication failures could occur. This was done by mapping unattended and unidentified interfaces of technical communication to form an alignment matrix. The application was developed based on a study of Pratt and Whitney’s development project of their jet engine PW4098.

This article hence reflects on their key findings of that study (by M. Sosa, S. Eppinger, and C. Rowles) in order apply it on the communication interface between Project Managers and their respective sub-teams. The aim is to study is to provide Project Managers with a tool by which they can monitor their effectiveness in communication with the intention of learning and improving for future projects. This tool could be a good complementary tool to feedback surveys and reviews.

==Introduction and background==

==Key learnings (Solution)==

==Applications in Project Management==

==Critical reflection==

==References==