Eight to Late

Sensemaking and Analytics for Organizations

A short note on project complexity

with 2 comments

The adjective complex is often used to describe projects that are in some sense hard. I’ve used the term without defining it in a few of my previous articles on this blog  (see my post entitled, rumours of a new project management paradigm, for example).  I’m sure most project managers (PMs) have at least a qualitative notion of what makes a project complex. However, if you ask a bunch of PMs what the term means, you’d probably get answers varying from, “large projects involving many people” to “projects involving unfamiliar or new technologies”. It is worth gaining a general understanding of  the term because it is often used in project management practice and research. Hence my motivation for this short, critical look at a few definitions and measures of project complexity.

A good place to start is with Dr. Lew Ireland’s paper entitled Project Complexity: A Brief Exposure to Difficult Situations. In the paper, Dr. Ireland identifies two dimensions of project complexity:

  • Technical Complexity: This includes all technical aspects of the project, such as,
    • Number of technologies involved
    • Familiarity of team with technologies
    • Bleeding edge or well established technology.
    • Number of technical interfaces
  • Management Complexity: This includes all business and organisational aspects of the project, such as,
    • Project staffing and management (team composition, size, management hierarchy etc.)
    • Number of parties involved (external vendors, internal departments etc.)
    • Change-related issues.
    • Stability and complexity of requirements
    • Political issues
    • Time / cost issues etc.

Dr. Ireland also highlights the need to identify and understand the elements of complexity in every project.  He does this by describing a few real-life cases of complex projects which went wrong.

The approach described above is similar to that outlined in The Project Manager’s Desk Reference by James Lewis. In the book, Lewis identifies four kinds of projects on the basis of the two dimensions listed above (note that he uses the term business complexity instead of management complexity). These are:

  • Type IV (Routine project): low technical and business complexity
  • Type III: low technical complexity but high business complexity
  • Type II: high technical complexity but low business complexity
  • Type I (Complex Project): high technical and business complexity

One can get quite specific in defining dimensions, but some caution is necessary. As the number of dimensions increase, individual dimensions become narrower in scope and there’s a danger that some elements of complexity will not be captured.  How this might happen is best illustrated through an example. Consider this project complexity model which uses the following eight dimensions:

  1. Time / cost
  2. Team size
  3. Team composition
  4. Competing demands
  5. Problem / solution clarity
  6. Stability of requirements
  7. Strategic importance / political implications / number of stakeholders
  8. Level of change

Question: Look at these measures carefully. Is there something missing?  

Answer:  All the listed measures relate to business complexity. There is no measure of technical complexity!

So I end  this note with the following: It is important to understand what is meant by project complexity because the term is often used by project management professionals in conference presentations, trade journal articles and research papers (and blogs!). However, it is equally important to ensure that the elements used in a definition capture all relevant aspects of complexity in projects.

Written by K

May 1, 2008 at 9:22 pm

Posted in Project Management

2 Responses

Subscribe to comments with RSS.

  1. […] This should sound extremely familiar to IT project managers.In an earlier post I looked into definitions of project complexity. In a nutshell, there are two dimensions of project complexity: technical and management (or […]


  2. […] of management and technical factors. I have used the term in this sense in my post entitled a short note on project complexity. This kind of complexity is relatively easy to measure, at least qualitatively if not […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: