Thursday, 02 October 2008 04:37

Introducing the New Project Complexity Model. Part I.

Written by Kathleen B. Hass

The Nature of Project Complexity

“The parts that make [project] complexity difficult to assess are in the two areas hardest to measure: People and their abilities, and work environment.”
Johanna Rothman, consultant, speaker, and author

The jury is still out: There is no widely accepted definition of project complexity that is research-based and therefore defensible1. The project management industry is sort of taking the stand that “You will know it when you see it.” We do, however, have a good understanding of the some of the causes of project complexity2:

  • Details – number of variables and interfaces
  • Ambiguity – lack of awareness of events and causality
  • Uncertainty – inability to pre-evaluate actions
  • Unpredictability – the inability to know what will happen
  • Dynamics – rapid rate of change
  • Social structure – numbers and types of interactions
  • Interrelationships – many interdependencies and interconnections exist

There is general consensus that a project that consists of many interdependent moving parts should be treated as complex. There is also agreement that our failure to understand the complexity of the product or of the project often leads us to project failure3, as does the inability to recognize uncertainty. Many authors stress the relationship between how well-defined the goals are and how certain the methods of achieving the goals are, suggesting different managerial techniques depending on the uncertainties4. Others postulate that the element of urgency present on nearly all business transformation projects adds its own element of complexity and stress to projects.

Webster’s Encyclopedic Unabridged Dictionary, 2001 tells us that complexity is characterized by a complicated or involved arrangement of many interconnected parts, units, etc., and that the situation is so complicated or intricate as to be hard to understand or deal with. We will not attempt to put forth an authoritative definition of project complexity – we leave that to the academics. We will explore what we believe is a widely accepted set of dimensions of project complexity. The ability to diagnose that some or all of the project complexity dimensions exist on a project provides invaluable information to the project leadership team as they make decisions about how to manage the project at hand.

The intent of this series of articles is to present a new Project Complexity Model that attempts to capture dimensions of project complexity – those characteristics that are present that make a project unpredictable and dynamic – and then discuss the project management tools, methods and approaches that should be considered by the project leadership team to manage the complexities. Existing, traditional project management tools and techniques based on decomposition and control theory are still quite valid for straightforward, well-understood projects; and emerging more adaptive methods to manage project complexities and uncertainties are proving to be effective as well. The real trick is to determine which approaches and interventions to apply. When managing complex projects, the emphasis is on approaches that will add value to the project by affording the project team the ability to adapt to learnings and changes in the environment and fine tune the project methods accordingly.

The Project Complexity Model

The Project Complexity Model presented here provides a framework to diagnose the elements of complexity that exist on a particular project so that the project team can make the appropriate complexity management decisions. There are a number of dimensions of project complexity that are captured in the model, including: Project time and value, team size and composition, project urgency, schedule, cost and scope flexibility, clarity of the problem and solution, stability of requirements, strategic importance, stakeholder influence, level of organizational and commercial change, external constraints and dependencies, political sensitivity, and unproven technology.

Using the Project Complexity Model

Before examining the model, it is important to understand that relatively small, short-duration projects might be highly complex because of the presence of complexity dimensions that have nothing to do with size, e.g., the level of change required within both the business and technical communities. In the case of large-scale organizational change, the deployment across multi-cultural groups is what makes the project complex, while the new business solution might be relatively straight-forward. So, the model is meant to be applied when taken in its entirety, without focus on only one or two dimensions.

To use the model to diagnose the complexity of a particular project, in the following table, shade the boxes that best describe your project and apply the complexity formula described.. Note that all conditions described within a box do not need to be present; shade only one cell in each row that best describes your project.

Highly Complex
Moderately Complex
Independent
Level of change = large-scale enterprise impacts
OR
Both problem and solution are difficult to define or understand, and the solution is difficult to achieve. Solution likely to be using unproven technologies
OR
Four or more categories in the “Highly Complex” column
Four or more categories in the “Moderately Complex” column
OR
One category in “Highly Complex” column and three or more in the “Moderately Complex” column
Remaining Combinations

Table 1 - Project Complexity Formula

Complexity Dimensions
Project Profile
Independent
Moderately Complex
Highly Complex
Time / Cost
< 3 months
< $250K
3 – 6 months
$250K – $750K
> 6 months
> $750K
Team Size
3 – 4 team members
5 – 10 team members
> 10 team members
Team Composition and Performance
· Strong project leadership
· Team staffed internally, has worked together in the past, and has a track record of reliable estimates
· Formal, proven PM, BA, SE methodology with QA and QC processes defined and operational
· Competent project leadership
· Team staffed with internal and external resources; internal staff has worked together in the past, has a track record of reliable estimates
· Contract for external resources is straightforward; contractor performance known
· Semi-formal methodology with QA/QC processes defined
· Project manager inexperienced in leading complex projects
· Complex team structure of varying competencies, (e.g., contractor teams, virtual teams, culturally diverse teams, outsourced teams)
· Complex contracts; contractor performance unknown
· Diverse methodologies
Urgency and Flexibility of Cost, Time, and Scope
· Minimized scope
· Small milestones
· Schedule, budget and scope are flexible.
· Schedule, budget, scope can undergo minor variations, but deadlines are firm
· Achievable scope and milestones
· Over-ambitious schedule and scope
· Deadline is aggressive, fixed and cannot be changed
· Budget, scope & quality have no room for flexibility
Problem and Opportunity Clarity
· Clear business objectives
· Easily understood problem or opportunity
· Defined business objectives
· Problem or opportunity is undefined
· Unclear business objectives
· Problem or opportunity is ambiguous and undefined
Solution Clarity
Level of IT Complexity
· Solution is readily achievable using existing, well-understood technologies
· IT complexity low
· Solution is difficult to achieve or the technology is proven but new to the organization
· Moderate IT complexity and legacy integration
· Solution requires groundbreaking innovation
· Solution is likely to be using immature, unproven or complex technologies provided by outside vendors
· IT complexity & legacy integration high
Requirements
Volatility and Risk
· Strong customer/user support
· Basic requirements understood, straightforward, stable
· Adequate customer/user support
· Basic requirements understood, but are expected to change
· Moderately complex functionality
· Inadequate customer/user support
· Requirements are poorly understood, volatile, and largely undefined
· Highly complex functionality
Strategic Importance Political Implications Multiple Stakeholders
· Strong executive support
· No political implications
· Straightforward communications
· Adequate executive support
· Some direct mission impact
· Minor political implications
· 2-3 stakeholder groups
· Challenging communication and coordination effort
· Mixed/inadequate executive support
· Affects core mission
· Major political implications
· Visible at highest levels of the organization
· Multiple stakeholder groups with conflicting expectations
Level of Organizational Change
· Impacts a single business unit, one familiar business process and one IT system
· Impacts a 2-3 somewhat familiar business units, processes and IT systems
· Large-scale organizational change that impacts the enterprise
· Spans functional groups or agencies
· Shifts or transforms the organization
· Impacts many business processes and IT systems
Level of Commercial Change
· Minor changes to existing commercial approach
· Enhancements to existing commercial practices
· Ground-breaking commercial practices
Risk, External Constraints and Dependencies
· Considered low risk
· Some external influences
· No challenging integration issues
· No new or unfamiliar regulatory requirements
· No punitive exposure
· Considered moderate risk
· Some project objectives dependent on external factors
· Challenging integration effort
· Some new regulatory requirements
· Acceptable exposure
· Considered high risk
· Overall project success depends largely on external factors
· Significant integration required
· Highly regulated or novel sector
· Significant exposure

Table 2 - Project Complexity Model for Business Transformation Projects

Rationale Accompanying the Project Complexity Model

The Project Complexity Model presented here is extremely robust, encompassing the priorities emphasized in the Standish Group’s Recipe for Project Success: The CHAOS Ten5, as well as the best practices presented in the nine knowledge areas of the PMBOK® Guide: scope, time, cost, integration, procurement, quality, communication, risk and human resource management6.

There are several variations of project assessment models in the project management literature. One might refer to the Project Sizing Grid presented by David Hillson and Peter Simon7. The authors present four levels of project characteristics to arrive at an overall project risk rating. Then one can extrapolate whether the project can be considered to be small, medium, or large to indicate the appropriate level of risk management activities that is warranted.

Another instance is provided by Gregory A. Garrett, referred to as the Project Complexity Assessment Tool8. Garrett uses five levels of project complexity characteristics, Low, Low-to-Medium, Medium, Medium-to-High, and High. The tool’s purpose is to extrapolate the level of project complexity to determine the appropriate amount of project management rigor that is needed to achieve success.

We have chosen to use a clear-cut three-tiered model for simplicity and ease of use. Referencing the model, some may argue that a project needs to be much longer in duration than six months or much larger in value than $750K to be considered complex. However, we have chosen these tolerances because the project performance statistics clearly indicate that projects of this size involving new or changed IT systems are complex and challenging; Standish CHAOS research has demonstrated that we have been able to improve performance largely because we have continued to reduce the duration and resource levels. Our approach is consistent with the Recipe for Project Success put forth by The Standish Group International, Inc. in 1999 and updated in 2001 as depicted in Table 39. Their message is clear: Size matters; less is more.

Ingredients:
Clear business objective; minimized scope (microprojects with rigorous configuration management); communication and collaboration; proven, standard, stable software infrastructure (vs. custom code); firm basic requirements; formal methodology; reliable estimates
Mix with:
Full-time, co-located core team members: (experienced business analyst, project manager, business visionary, architects and developers), coached by an involved executive project sponsor
Bake:
No longer than six months; no more than six people; at no more than $750,000 (1999)
No longer than 4 months; no more than 4 people; at no more than $500,000 (2001)
Table 3 - Standish Group Recipe for Project Success

Visualizing and Communicating Project Complexity

In order to communicate the nature of the complexities on your project, it is helpful to create a visual depicting the overall project complexity by developing a “spider chart” similar to the one illustrated in Figure 1 - Overall Project Complexity.


Figure 1 – Overall Project Complexity

The Project and Program Complexity Model


Refer to Figure 2 for another view of the Project Complexity Model. This view incorporates the concept of program management. A program is defined as a group of related projects with varying degrees of complexity. As you diagnose the complexity of ach project within the program, it is wise to focus on the high-risk, highly complex projects first to ensure the risks and complexities can be managed before investing time and resources on the less complex projects.


Figure 2 – Project and Program Complexity Model

When to Apply Complexity Thinking to Projects

Using the Project Complexity Model to guide management of complex projects should be used during many phases of the project life cycle. Take your project leadership team through the analysis recommended in the remaining articles in this series to apply complexity thinking to the major decisions you make about your project. Specifically, adopt the project complexity management approaches outline here when you are: 

  • Preparing the business case for a new project proposal 
  • Initiating and planning a new project or program 
  • Initiating and planning a new major phase of a project 
  • Recovering a troubled project 
  • Recovering troubled projects within a program

Steps to Apply Complexity Thinking to Projects

“Fools ignore complexity, Pragmatists suffer it, Some can avoid it, Geniuses remove it”
Alan Perlis, American Computer Scientist

For 21st century projects, it is important to clearly understand the level of complexity and then apply a management approach that is commensurate with the complexity dimensions that are present. There are two types of complexity when it comes to projects:

  • Project Management Complexity: Managing projects that exist within complex adaptive business environments with an array of interrelationships and interdependencies 
  • Solution Development Complexity: Implementing complex, adaptive business solutions; building business solutions quickly that are flexible, adaptive, dynamic, and easy to change as the business environment changes

Therefore, applying complexity thinking to projects involves selecting appropriate methods and techniques, assigning project leadership and project cycles based on the project profile and the complexity dimensions that are present, and building complex, adaptive business solutions that are easy to change as the business needs evolve. There are four steps in the process listed below. The remaining articles in this series will discuss these in detail.

STEP 1: ASSIGN PROJECT LEADERS BASED ON THE PROJECT PROFILE
Project sometimes fail because of inappropriate match of project leadership to the level of project complexity. The project manager, business analyst, lead IT architect and developer, and business visionary are four critical project leadership positions. Once the project complexity has been understood, organizations should use this vital information to make project leadership assignments as will be described in Part II

STEP 2: SELECT THE PROJECT CYCLE BASED ON THE PROJECT PROFILE
Based on the project profile diagnosed using the Project Complexity Model, the project team determines the appropriate project cycle to use, as will be described in Part III. All projects have a cycle, a sequence of stages through which the project passes. Typical cycles have a series of periods and phases, each with a defined output that guides research, development, construction, and/or acquisition of goods and services10. As projects have become more complex, project cycles have evolved to address the various levels of complexity.

STEP 3: SELECT APPROPRIATE MANAGEMENT TECHNIQUES BASED ON COMPLEXITY DIMENSIONS
Projects sometimes fail because of misapplication of good management methods and techniques. In Part IV, we will discuss the application of complexity thinking to determine the appropriate techniques to use based on the complexity dimensions present. Successful managers of complex projects become situational project managers by adapting their leadership style and the project management, software engineering, and business analysis methods to deal with the complexity dimensions that exist.

STEP 4: DESIGN AND BUILD COMPLEX, ADAPTIVE BUSINESS SOLUTIONS
To design, build and maintain complex adaptive business solutions, which are almost always comprised of highly complex IT systems, we must be able to understand and account for the business strategies as they evolve, as well as the system interrelationships and interdependencies. In addition, we must be able to build and support nested systems within systems, complex business rules, and intricate feedback loops. While engineering complex adaptive systems is a field in and of itself, we will offer a few techniques for your consideration in Part V. In this section we also discuss some emerging technologies and management techniques to deal with the legacy of business and IT complexity that exists today.

Summary

Most 21st century projects are highly complex involving lots of interrelationships, nested systems within systems, and changing requirements. Using an effective Project Complexity Model to diagnose the level of complexity on a particular project and making managerial decisions accordingly will greatly increase your chances of project success. We propose using the Project Complexity Model as a framework to inform your decisions and communicate about your project when you are:

  • Assigning key project team members 
  • Selecting the project cycle 
  • Selecting appropriate management techniques based on complexity dimensions 
  • Designing and building complex, adaptive business solutions 
  • Dealing with the legacy of business and IT complexity

The next article in this series will discuss applying complexity thinking to assign project leaders based on the project complexity profile.

Note
Much of the information in this article has been previously published in other forms, including: a paper which was part of 2007 PMI Global Congress Proceedings North America, a white paper published by Management Concepts in 2007 entitled: Living on the Edge: Managing Project Complexity, and as a section in the book to be published by Management Concepts in 2008 entitled: Managing Project Complexity: A New Model.
References
1 S. Jonathan Whitty and Harvey Maylor, And Then Came Complex Project Management, February 2007. Presented at the Proceedings of 21st IPMA World Congress on Project Management. Online at http://espace.library.uq.edu.au/eserv.php?pid=UQ:13419&dsID=And_then_came_Complex_Project_Management.pdf
 (accessed January 2008).
2 Jerry Mulenburg, 2008. What Does Complexity Have to Do With It? Complexity and the Management of Projects. From the proceedings of the 2008 NASA Project Management Challenge Conference.
3Terry Williams, Modelling Complex Projects, 2002. West Sussex, UK: John Wiley and Sons, Ltd .p. 49.
4Terry Williams, Modelling Complex Projects, 2002. West Sussex, UK: John Wiley and Sons, Ltd .p. 55.
5The Standish Group International, Inc. CHAOS: A Recipe for Success, 1999. Extreme CHOAS, 2001.
6 Project Management Institute, A Guide to the Project Management Body of Knowledge, Third Edition (PMBOK® GUIDE) 2004.Newtown Square, PA.
7 David Hillson and Peter Simon, Practical Project Risk Management, 2007. Vienna VA Management Concepts, P. 29.
8 Gregory A. Garrett, Managing Complex Outsourced Projects, 2004. Chicago: CCH Incorporated, p. 72.
9 The Standish Group International, Inc. CHAOS: A Recipe for Success, 1999. Extreme CHAOS, 2001.
10 Hal Mooz, Kevin Forsberg,, Howard Cotterman, 2003. Communicating Project Management, Hoboken, New Jersey: John Wiley & Sons, p. 259.


Kathleen Hass, PMP, is the Senior Practice Consultant for Management Concepts, Director at Large, Chapter Governance Committee chair and contributing author of the Business Analysis Body of Knowledge for the International Institute of Business Analysis (www.theiiba.org). Kitty has more than 25 years of experience in project management and business analysis, including project office creation and management, business process re-engineering, organizational development, software development, technology deployment, project management training, mentoring and team building. For more than a quarter of a century, Management Concepts, whose mission is to unleash the potential of people, has provided quality training and performance improvement solutions for the mind at work. For further information, please call 1.703.790.9595 or visit the company website at www.managementconcepts.com.

Read 61603 times

© ProjectTimes.com 2017

macgregor logo white web