Tyson's research focuses on modeling and analyzing complex projects

  • To increase our understanding of how such entities operate and

  • To identify insights to improve planning and management.


Tyson's areas of interest and expertise:

Process Engineering Project and Program Management Business Operations Product Architecting and Systems Engineering
  • Product design and development processes
  • Systems engineering processes
  • Process modeling and analysis
  • Process improvement (including Lean and Six Sigma)
  • Processes as complex adaptive systems
  • Design structure matrix (DSM) applications
  • Project design
  • Project control
  • Risk management
  • Cost and duration estimation and optimization
  • Technical performance and quality management
  • Resource management
  • Enterprise engineering
  • Measures and metrics; leading indicators



Click here for Key Insights from Tyson's Research



Examples of important research findings pertaining to projects/programs:


  • In large projects/programs, where work is distributed across many teams, inter-team integration is critical (just as intra-team integration has long been emphasized) and can be facilitated through models (such as the DSM) and integrative mechanisms. (P2, P4, O17, O20)


  • Ironically, increasing activity and interface standardization can INCREASE process flexibility and agility. (O15, P20)

Process Improvement:

  • In complex projects/programs, value is a function of the overall process, not just individual activities.  How much value an activity adds depends on how it fits into the overall process.  Improved efficiency and effectiveness (e.g., "getting Lean") often requires adding rather than subtracting activities. (P10, P18, P25)

  • Process improvement requires process integration and synchronization. (P7)

Risks, Progress, and Value:

  • Project/Program progress and added value depend on removing "anti-value" (i.e., reducing the project's value at risk)  (P9, O14, O16, O19, P31)


Explaining project architecture:

The term “architecture” refers to the structure of the elements and relationships in a system that gives rise to its behavior.  The architecture of any complex entity may be viewed through several lenses.  Much of the existing research on project management uses only one of these lenses, that of the activities to be planned, scheduled, and controlled.  Like the blind men touching the elephant in the famous Asian story, using only one point of view cannot tell the whole story.  In an effort to better understand complex projects, I seek to study them from several points of view—especially the product, process, and organization perspectives.

  • The product design literature refers to product architecture as the set of interrelated components comprising a product.  I consider the product domain more generally as the artifact designed or result produced by any project—e.g., the recipe for a new product or service.

  • To create the product, a project must accomplish tasks.  These tasks collectively entail all the work done in a project.  I refer to all of this work as the process domain, and to all of the activities and their relationships as the process architecture (or activity network, or project process).

  • In every project, people accomplish the tasks that create the product.  These people may do some tasks individually, but more often they work together in teams to accomplish tasks.  These people and teams also relate to each other—e.g., in reporting relationships in the organization structure, in social networks, in information exchange relationships, etc.  I call this set of organizational units (the smallest of which is a person) and their relationships in the organizational domain the organization architecture.

Orientation with these three domains and architectures—product, process, and organization—will facilitate the explanation of my research.  I refer to these domains collectively as the project architecture.


Research areas and streams:

AREA 1:  Modeling and analyzing individual project domains

STREAM 1:  Developing the design structure matrix (DSM) as an architecture modeling and analysis tool in and across domains

STREAM 2:  Modeling and analyzing the product architecture

STREAM 3:  Modeling and analyzing the process architecture

STREAM 4:  Modeling and analyzing the organization architecture

AREA 2:  Modeling and analyzing overall projects

STREAM 5:  Modeling project progress, value, and risk reduction

STREAM 6:  Exploring project architecture and its adaptation

More information about each stream follows.

STREAM 1:   Developing the design structure matrix (DSM) as an architecture modeling and analysis tool in and across domains

The DSM provides a way to represent a model of a complex system with simplicity and conciseness.  It can be used to highlight important architectural patterns such as modularity and cyclicality.  It has helped illuminate techniques for improved understanding and management of projects, products, processes, and organizations.  I have taken an international role in the development of DSM methods and applications.  Key publications:

  • P6 developed a widely-used taxonomy of DSM application areas to organize the first review of DSM literature.

  • P12 developed the domain mapping matrix (DMM) as a complement to the DSM that paved the way for multidomain matrix (MDM) models.

  • O20 provides an introduction to the DSM and presents 44 industry applications that have made an impact.

  • P33 expanded and updated the taxonomy and surveyed the latest DSM, DMM, and multidomain matrix (MDM) applications and extensions.

Click here for an introductory tutorial on DSM methods and applications (from the Oct. 2020 DSM Conference).

STREAM 2:  Modeling and analyzing the product architecture

  • Sub-stream 2a:   Designing products for adaptability (P16, C24, O21, P37)

  • Sub-stream 2b:   Modeling the life-cycle value of enduring products (P15, P17)

  • Sub-stream 2c:   Investigating consequential patterns (hubs, cycles, modules) in product architectures (P24, P26, O28)

  • Sub-stream 2d:   Investigating the evolution of product architectures (C17)

STREAM 3:  Modeling and analyzing the process architecture

  • Sub-stream 3a:   Process modeling and a process architecture framework (PAF) (P11, P13, P19, P22, P27, P30, P38)

  • Sub-stream 3b:   Using the DSM to model and analyze the process domain (C4, P5, P7, P8, P14, O20)

  • Sub-stream 3c:   Managing a portfolio of projects under resource constraints (P21, P23, P34, P36)

  • Sub-stream 3d:   Modeling and simulating adaptive processes (P20)

  • Sub-stream 3e:   Modeling project time-cost tradeoffs due to alternative work policies and activity crashing, overlapping, and iteration (P32, P35)

  • Sub-stream 3f:    General project scheduling (O18)

STREAM 4:  Modeling and analyzing the organization architecture

  • Modeling the organization domain, applying integrative mechanisms to facilitate the organizational unit interaction, and designing organizations for ease of integration (P2, P4, O17, O20)

STREAM 5:  Modeling project progress, value, and risk reduction

  • Sub-stream 5a:   Conceptual models of sources of uncertainty and risk in projects (P3, C6, P28, P29, O26)

  • Sub-stream 5b:   Quantitative frameworks for measuring progress and added value, including the risk value method (RVM) and the project value, risk, and opportunity (PVRO) framework (P9, O14, O16, O19, P31, C26, O32, P39)

  • Sub-stream 5c:   Relationships between uncertainty, complexity, novelty, and value, especially as prompted by applications of Lean in product development projects (P10, P18, P25)

STREAM 6:  Exploring project architecture and its adaptation

  • Exploring static and dynamic relationships among project structures within and across the domain perspectives (O15, O20, O25)


  • Looking back, around, and forward at the state of project management research, mainly in conjunction with operations management research (O30)


Last updated:  December 30, 2020

Home Classes Home Publications Biography Email