Eight to Late

Sensemaking and Analytics for Organizations

Search Results

A model of project complexity

with 4 comments


The lack of a clear definition of project complexity has lead to much confusion amongst project management academics and practitioners regarding what makes a project complex to manage. A recent paper by Harvey Maylor, Richard Vidgen and Stephen Carver, entitled Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice, is a step towards changing this situation. In the paper Maylor and his co-workers  present a qualitative empirical model which captures both structural (static) and dynamic1 elements of  managerial complexity in projects. I summarise and review the paper below.

Background and Objectives

The authors make the observation that project management methodologies (as codified in the various “bodies of knowledge”) contain what is deemed as accepted practice rather than best practice.  The point being that there is never any proof offered that the practice in question is indeed the best, or even better than others. Such proof is impossible because methodologies are highly prescriptive and  ignore context (i.e. the particular environment and quirks of individual projects).  This dogmatic, “our way is the best way” attitude is inconsistent with the diversity of situations and factors that make projects hard to manage. Hence the need to develop a understanding of what makes a project complex.

It may thus be helpful to consider projects as complex adaptive systems. As a first step, the authors discuss various characterstics of such systems, in particular those that might apply to projects. I have covered much of this material in an earlier post, so my coverage here will be brief. The main points the authors make are as follows:

  1. The components of a complex system interact and produce outcomes that are unpredictable and nonlinear.
  2. One cannot understand a complex system by studying the individual components that comprise it.
  3. A complex system displays path dependence (i.e. dependence on history) and sensitivity to initial conditions.
  4. Adaptive systems can change and “learn” from experience.

There have been several models of project complexity proposed by researchers. Each of these propose various dimensions (or factors) that capture complexity. Some of these factors are:

  1. The number of physical elements of a project and their interdependencies. (Baccarini)
  2. Organisational, technical and resource complexity.
  3. Organisational and technical complexity, and structural and dynamic interactions between the two. (Xia and Lee)

Although earlier models have been useful, organisations have found that other factors (unaccounted for in existing models) contribute to managerial complexity in projects. With this in mind, the authors’ aim to develop a comprehensive empirical model of managerial complexity in projects and thus answer the question: What makes a project complex to manage?

The Model

The  model  was developed through workshops that involved a large number of practising project managers. I will not go into details of research methodology here; please see the original paper for details.  What is important to note is that the model includes input from a broad range of practitioners. With that said, I’ll move straight on to a description of the model.

The model describes both structural and dynamic elements of managerial complexity. The authors find that structural complexity in projects comprises of the following broad dimensions: Mission,  Organisation, Delivery, Stakeholders and Team. Following a distinctly academic penchant for acronymisation (to coin a term), the authors call their model MODeST, taking the first letter or two from each of the above dimensions.

The hierarchy below lists each of the above dimensions along with their sub-dimensions. Further, the lowest level of the hierarchy (sub-dimension level) lists representative questions that can be used to characterise each sub-dimension.  (Note: Please see the paper for full details).

  • Mission
    • Objectives
      • Is there a clear vision?
      • Are the goals clear?
    • Scale
      • Long timescale?
      • Large number of resources?
    • Uncertainty
      • Are there interdependencies with other projects?
      • Are there interdependencies within the project?
      • Does it involve new technology?
      • Has the project been done before?
    • Constraints
      • Are there legislative or compliance constraints?
  • Organisation
    • Time
      • Are there multiple timezones?
    • Space
      • Are team members colocated?
      • Is there face-to-face communication between team members?
    • Geography
      • Are there multiple languages?
    • Project / organisation fit
      • Is there a mismatch between project team structure and organisational structure?
    • Organisational change
      • Does the project involve organisational restructuring?
  • Delivery
    • Administration
      • Is project reporting accurate, adequate and does information get to people who need it?
      • Is project data collection accurate, true and complete.
    • Decision Making
      • Is there effective governance of project decision making?
      • Are too many levels of management involved in decision making?
    • Change management
      • Is the change management process cost effective?
      • Is it flexible?
    • Project processes
      • Are project processes defined, standardised but not overly bureaucratic?
      • Is there a clear responsibility for tasks and deliverables?
    • Project management methodology
      • Is there a common methodology used throughout the project?
    • Resources – Human
      • Are human resources shared across projects?
      • Who controls human resources for the project?
      • Does the project manager have control over resource selection?
    • Resources –  Technology
      • Does the project have tool support?
    • Resources – Financial
      • How flexible is the project budget?
  • Stakeholders
    • Stakeholder Identification
      • How many stakeholders are there?
      • Are there any unidentified stakeholders?
    • Support for project
      • Do stakeholder groups interfere with the project?
      • Do stakeholders have sufficient time for the project?
      • Do they respond to project needs in a timely manner?
    • Relationship basis
      • Is the relationship between the project and stakeholders contractual?
    • Experience
      • Do the stakeholders have realistic expectations of the project?
      • Do they have domain experience?
      • Do they have project management experience?
    • Power
      • Do the stakeholders have power to make decisions.
    • Key stakeholders
      • Is there senior management support?
    • Sociopolitical
      • Are there hidden agendas or unsurfaced assumptions?
      • Do stakeholders have conflicting priorities?
      • Are there any conflicts between requirements of different stakeholders?
    • Interdependencies
      • Are there interdependencies between stakeholders? (e.g. between suppliers)
  • Team
    • Project staff
      • Do team members have sufficient prior experience?
        Does the project involve multiple technical disciplines and languages?
      • Are the team members knowledgeable and competent in all aspects of the project (business, technical and project management)?
      • Are the team members motivated?
    • Project manager
      • Is the project manager an effective communicator?
      • Does the project manager have authority?
    • Group
      • Are there cultural differences between team members?
      • Are there personality clashes or is there any rivalry within the team?
      • Does the team have a shared vision for the project?

The above dimensions and sub-dimensions characterise the structure of managerial complexity in projects. However, that isn’t all: the authors mention that many workshop respondents emphasised that elements (i.e dimensions) that make up the model interact thereby “multiplying” managerial complexity. This is one aspect of dynamic complexity. The authors also note that interactions can occur within a single element – for example, within interdependencies between suppliers and stakeholders. Analysis of the data showed that there is a dynamic element corresponding to every structural element of the model. Further still, dynamics of an individual structural element can be affected by interactions with other structural and dynamic elements. That is, the dynamics of one part of the system can be altered by other changes in other parts. The model thus captures structural, dynamic and interactive aspects of managerial complexity in projects.

The authors report that workshop participants also recognised their own role in adding to managerial complexity. For example, a project manager who fails to recognise task dependencies in early stages of a project contributes to complexity down the line. Project managers are thus, ” key actors embedded within the conceptualisation of the complexity of their projects rather than external observers.” The authors suggest that this indicates that many elements of managerial complexity can in fact be tamed by proper management. That, arguably, is what a project manager’s job is all about.

Implications and Discussion

The authors observe that projects are ubiquitous within organisations. Yet, current project management practices as codified in well-known methodologies fail to account for variations in context between projects. Managerial complexity varies with (and is defined by) a particular project’s context – for instance, a project may have several stakeholders with conflicting requirements whereas another may have only one stakeholder. The model developed by the authors describes managerial complexity using five dimensions and several sub-dimensions. These structural elements can change in time and also interact with each other, so the model is also capable of describing dynamic complexity in projects.

To illustrate expand on the last point of the previous paragraph, consider stakeholders – the “S” in the MoDest acronym. The authors point out that, “from an organisational theory perspective, a project can be seen as being constituted from the entire set of relationships it has with itself and with its stakeholders.” Project managers need to understand not only the power and legitimacy of each of the stakeholders, but also the relationships or interactions between them.  Moreover, the relationships between stakeholders evolve in time – i.e they are dynamic. Similarly, the other four dimensions of the model also display dynamic behaviour.

This dynamic behaviour is merely a restatement of the obvious:  in projects things change, sometimes rather quickly and unexpectedly. Standard project management practice offers techniques such as risk management, configuration management and change control to manage these. However, the authors suggest their data shows that,  “the nature of change considered by existing approaches is limited and that such programmatic responses may be inappropriate.” They go on to state, “Such dissatisfaction with traditional requirements engineering and command-and-control project management strategies has lead to an interest in agile project management approaches.” These statements will ring true for  those who have been burned by  the limitations of traditional project management methodologies.  Agile techniques embrace change; traditional methodologies seek to control it (and do so unsuccessfully, one might add).  The implicit acceptance of change in agile methodologies make it consistent with the dynamic model of managerial complexity proposed by the authors.


The paper describes an empirical model of managerial complexity in projects. From my (admittedly incomplete) reading of the literature, the model is more comprehensive than those that have been proposed heretofore. Further, it captures structural, dynamic and interactive aspects of elements that make a project complex and hard to manage. The model challenges current practice as embodied in traditional, “big-bang” approaches to running projects, but is consistent with Iterative/Incremental methodologies which form the basis of agile techniques.

The authors end with a brief description of some areas for further research. Some of these include:

  • Refining the dimensions of complexity and finding the key drivers of each.
  • Determining whether compexity can be quantified.
  • Exploring the possibility of managing complexity.

We are still a long way off answering these questions, and thus developing a quantitative, controllable understanding of project complexity. Yet, the model presented provides at least a partial answer to the question: What makes a project complex to manage?


Maylor, Harvey.,  Vidgen, Richard, & Carver, Stephen., Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice, Project Management Journal, 39 (Supplement), S15-S26. (2008).


1 See this post for more on structural and dynamic complexity.

Written by K

September 18, 2008 at 11:08 pm

Project complexity redux

with 5 comments

In recent years there has been much discussion on complexity in project management (see this book or this standard, for example).  Unfortunately, the term “complexity” has been interpreted in all kinds of different ways, creating more confusion than clarity. So, despite all that’s been written and said, project management practitioners are still left wondering what is meant when the words “project” and “complex” (or its variants such as “complexity”) are strung together. This post is aimed at clarifying some of the confusion.

In the natural and social sciences, the term complexity is used to describe systems that consist of several interacting parts.  However, there’s more to complexity than just that. Complex systems  display several characteristic features including nonlinearity, continuous interactions with their environment (open systems) and complex feedback loops. Many complex systems also display emergent behaviour – i.e. behaviour that is more than a sum of the the behaviour of individual components. The collective behaviour of bird flocks is an example of emergence: individual birds follow a relatively simple set of behaviours or rules based on the movements of their neighbours, giving rise to a stable flying pattern on the scale of the entire flock. This large-scale flocking pattern is an emergent phenomenon, not easily discernable from the simple rules followed by individual birds.

Now, as I’ve mentioned in a prior post,  the term complex is used in at least two distinct senses in the project management literature. These are:

  1. Projects that are difficult or complicated because they are high risk or involve a multitude 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 quantitatively. 
  2. Projects that are complex in the sense of complex systems as discussed above. This type of complexity is typically hard to measure, even qualitatively.

Although it is possible (and not uncommon) for projects to be complex in both senses described above, it is important to make a distinction between the two for reasons that I discuss below.

For starters,  to ensure consistency with other disciplines the adjective “complex” should (ideally) be used to refer to projects that are complex in the second sense. That brings us to the nub of the matter: how are we to know if a project is complex in this sense or not? This question remains open at this time. As yet no one has devised a metric, scale or even a definition  by which one would be able to determine whether a project is truly complex or not. Nevertheless, it is worth looking at project complexity from a couple of  perspectives in order to get a feel for what a definition of a complex project might look like. I do this in the next few paragraphs, with the caveat that my discussion is more vignette than panorama. Those looking for the latter may want to read the review paper published by Cooke-Davis and others in 2007. If wading through a research paper sounds uninviting, I can recommend my post entitled rumours of a new project management paradigm, which is basically a summary and review of the paper.

Moving on, in a recent paper, Jon Whitty and Harvey Maylor discuss the nature of complexity in projects. They point out that there are two elements to complexity – structural and dynamic. In the context of projects, the structural aspect consists of individual elements that make up the project and its environment – stakeholders, project tasks, etc. – and the interactions between these. In contrast, the dynamic aspect refers to changes in elements, the consequent changes in their interactions, and the further changes in the elements as a result of changing interactions. Whitty and Maylor suggest that a project be termed complex only when it displays both structural and dynamic complexity.   By this token, many projects currently classified as complex are incorrectly deemed so, because they display mainly structural, not dynamic, complexity. Put another way, they exhibit complexity in the first sense described earlier, but not the second. For example, many large projects consist of a large number of interacting elements (and hence display structural complexity), but the elements and their interactions are relatively stable (and hence not dynamically complex).  At the other end of the spectrum, one could have small projects that do display dynamic complexity. Size by itself is not a good measure of dynamic complexity.

Whitty and Maylor’s discussion suggests that structural complexity maps to complexity in the first sense  described above (i.e. complicated projects) and dynamic complexity to the second (i.e. truly complex projects). In what follows below, the term complex should be read as dynamically complex. 

Although the definition of a (dynamically) complex project is still an open question, Whitty and Maylor look into what might be meant by “managing a complex project”. In general, it is difficult (and often impossible) to predict long-term emergent behaviour in complex systems. In complex projects this lack of predictability is a consequence of complicated, dynamic interactions between various project elements such as resources, tasks etc. Note that this is lack of predictability, in principle – i.e.  it is not  a consequence of incomplete knowledge (such as incomplete scope definition) or any other controllable cause. This being the case, many of the tools used in conventional project management, which includes all Big Design Up Front methodologies, would simply not apply to complex projects. For example, how can one build a (long-term) schedule if one doesn’t know what’s going to happen? Further, it is also clear that any methodologies that use short development cycles, which includes all  iterative / incremental approaches, would have a much better chance of success here. In this context, the terminology used by the adaptive approach is particularly apt: faced with uncertainty, one doesn’t plan, one speculates. To sum up, although we don’t know what exactly a complex project is, we do know – broadly speaking – which project management approaches might work with them (and, more importantly, which won’t!).

For another perspective on project complexity, let’s turn to a paper entitled, Dilemmas in a General Theory of Planning, published by Rittel and Webber in 1973. The paper focuses on the characteristics of many social problems or issues – such as education, crime etc. – which can’t be solved (or even formulated!) in a conventional, scientific sense. The authors coin the term wicked problem to refer to such problems.  In contrast, problems that can be analysed and solved using known techniques are referred to as tame problems. In their paper, Rittel and Webber propose the following as defining characteristics of wicked problems:

  1. There is no definitive formulation of a wicked problem.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not true-or-false, but good or bad.
  4. There is no immediate and no ultimate test of a solution to a wicked problem.
  5. Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
  6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
  7. Every wicked problem is essentially unique.
  8. Every wicked problem can be considered to be a symptom of another problem.
  9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
  10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).

Although these characteristics are qualitative, they are relatively unambiguous – i.e.  given a problem, we can figure out whether it is wicked or not.  Looking through the list, it is tempting to draw a link between wickedness and complexity. Although I’m out on a limb here, other writers have commented on  the similarity between complex systems and wicked problems too. 

In an article  published in 2002, Mary Poppendieck dubbed a wicked project as a project that tackles a wicked problem as though it were a tame one. I would simplify the definition to: a wicked project is one that tackles a wicked problem. Then, assuming a  connection between wickedness and complexity exists, one would have the basis for a qualitative definition of a class of complex projects. I say “a class” because even if it is true that wicked problems are complex, the converse doesn’t necessarily hold – i.e. not all complex problems are wicked.

All the above – some of which is speculation –  leaves open the question of how a project is to be deemed complex or not. This, as mentioned earlier, awaits an unambiguous definition (and measure) of project complexity. We’re a long way off from that at present.  So, at least for now, one has to be careful when labelling a project “complex” because the term has a very precise meaning in the social and natural sciences.  Given this, it may be best to refer to so-called complex projects by other adjectives such as complicated, difficulthardintricateconvoluted or  even labyrinthine. Any synonymous term would get the point across, whilst sparing the project management community a whole lot of confusion.

Written by K

July 2, 2008 at 9:40 pm

Posted in Project Management

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

%d bloggers like this: