Research

 

Prof. Browning'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.

 

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

 

Examples of important research findings pertaining to projects/programs:

Organizations:

  • 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)

Work/Processes:

  • A project/program can be viewed as a complex adaptive system (CAS).  Using simple rules, predefined activities can self-organize to form value-adding paths towards project goals. (P20)

  • Project time-cost tradeoffs depend not only on crashing/expediting individual activities but also on modifying how those activities work together (process architecture and work policy, decisions about when to begin and end project activities). (P32)

  • Project and portfolio managers can use heuristics to allocate constrained resources, even with only general knowledge of project characteristics, but these characteristics make a big difference in which heuristic to use.  (P23)

  • Counter-intuitively, the fastest (shortest duration) project often does NOT have minimum iteration and rework.  (P8)

  • 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)

  • Lean and Six Sigma can be applied to product development processes, but not in exactly the same ways they are applied in manufacturing and other repetitive processes. (P10, P25)

  • Almost all processes are parts of a larger process.  Process improvement will provided limited benefit without integration and synchronization with the greater process. (P7)

Risks, Progress, and Value:

  • Many of the surprising "unknown unknowns" (unk-unks) affecting projects/programs are actually knowable and can be discovered through a process of directed recognition. (P29, O26)

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

  • There are important differences between four aspects of project/program value:  the value desired by the project's stakeholders; the "goal" value provided by meeting the project's specified goals, requirements, and objectives; the project's likely value, given its performers' capabilities; and the actual value provided by the project, known only after project completion.   (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.

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)

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)

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

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)

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)

 

 

Last updated:  April 27, 2017

 
Home Classes Home Publications Biography Email