Characterising, mischaracterising and re-characterising project complexity

Project complexity models exist. That could come as a surprise to some because they are rarely seen in the wild. Here is an example of the sort of thing you might come across.

Does complexity matter in projects? What even is complexity and why do we care? Without invoking some specific and narrow definitions, complexity must at least infer the state of being complex. Something that is complex, is composed of more than one, or of many parts. Invariably the latter.

Yes, complexity does matter, but are we measuring the right thing in projects? Project complexity is not the same as project difficulty; any correlation between the two is questionable. Simple projects are far from being necessarily easy projects but the terms ‘simple’ and ‘easy’ are too often used interchangeably.

Are we saying complexity when what we want is a measure of a project’s difficulty? I think we might be – I would far rather have an assessment of a project’s difficulty than its complexity. We have tools and knowledge for how to deal with project complexity, but not necessarily difficulty.

We need to reacquaint ourselves with the unabashed use of the work ‘difficult’. If a project is politically charged, comprises a mix of stakeholders with polarised views and has elements of uncertainty then it is going to be a difficult project. This is regardless of any inherent complexity or lack thereof. Project managers must not shy away from the use of the word ‘difficult’ for fear of scorn alone. Not admitting to ‘difficulty’ can be counterproductive despite it not always being what the sponsor or customer want to hear.

More often than not, we tiptoe around admitting when there’s a tough project by branding it as complex. The first means that the project may very well not succeed, the second simply means it's complex. When we can admit that there are difficult projects, we’ll be better placed to do something about them.

Ideally, we want a mechanism to assess project difficulty; it needs to be consistent, reusable, quantified and ideally qualified. Above all, it needs to be simple and lightweight; if we could use existing data held within the project in some way that would be advantageous. Since we’re modelling project difficulty, we should accept a few rounding errors in our assessment provided that the output is useful. A little wrongness is okay.

We should also focus on the relative assessment of difficulty. That we know one project is more difficult than another is enough provided that our system of measurement is data driven and objective. This will enable us to establish meaningful thresholds for difficulty in the organisation in which we are working. Below the line – we can probably manage it. Above the line – the record is less clear.

My mechanism below is visual, and progressive. We don’t want to do a huge amount of work upfront – we may never do this. But this allows us to assess a project via a process which progressively elaborates difficulty; and this, is optimal.

So what if it is a difficult project? If time is tight, then we might ensure intensive care of all activities on the critical path. If profit margins are tight and the possibility of further funding remote, then we make sure that project change (and the sources of change) are managed. If there can be little compromise on quality, then efforts can be made to bolster testing and assurance. In short, where we see ‘difficulty’, we can identify mitigations.

In the visual there are two projects: Project Red and Project Blue. For Project Red, T₁ is the earliest delivery time and T₂ is the latest. The median of T₁ and T₂ is the sweet spot in terms of ‘being on time’. Q₁ and Q₂ correspond to quality and C₁ and C₂ correspond to cost. Similarly for Project Blue. O₁ is the point of origin. If your organisation is itself going through change (and which organisation isn’t?) then O₁ is ‘moving’.

Which project is more difficult? Project Red or Project Blue. If you know the answer, then I’ve achieved some measure of what I set out to do.

On occasion, producing this sort of modelling may be unduly onerous and that’s fine. Simply visualising projects (or just single tasks) in this way as a purely thought based activity achieves many or all of the same benefits.

The model above is far from perfect. What do you think are the limitations? How might they be addressed?

_{Diagram: Barnaby Davies}