A short note on project complexity
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:
- Time / cost
- Team size
- Team composition
- Competing demands
- Problem / solution clarity
- Stability of requirements
- Strategic importance / political implications / number of stakeholders
- 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.