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, T1 is the earliest delivery time and T2 is the latest. The median of T1 and T2 is the sweet spot in terms of ‘being on time’. Q1 and Q2 correspond to quality and C1 and C2 correspond to cost. Similarly for Project Blue. O1 is the point of origin. If your organisation is itself going through change (and which organisation isn’t?) then O1 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
Barnaby Davies is a career project and programme management professional who helps businesses achieve their project delivery objectives.
7 comments
Log in to post a comment, or create an account if you don't have one already.
Hi Barnaby - thank you for this post. I am establishing a complex and complicated programme and this was an interesting prompt for ways to examine and understand the projects and stakeholders interests. I wonder if you have compared this with the scales sestablished by the IP
. . . by the IPA for project complexity assessment in the new Project Routemap framework https://www.gov.uk/government/publications/improving-infrastructure-delivery-project-initiation-routemap. P.S. Apologies for the two-part response - due to my fat fingers on the touchscreen keyboard!
Hi Barnaby, certainly a challenging response. There's a clear distinction between Complicated and Complex, at least in the APM assessment for RPP, and it's the same distinction made in NHS and some other organisations. I wonder if you are confusing the two words. Complicated means it's predictable but there are lots of steps, lots of cogs. Complex means that it's less predictable, typically a change to one part (such as favouring one stakeholder) has consequences which create difficulties (such as another stakeholder deciding to block further progress simply out of spite - yes, even at a corporate or public sector organisation scale). This response might be predictable, but steering a path that keeps both stakeholders on board is that much more complex because of these human responses. The same might occur when deciding whether to re-introduce wolves to Cumbria. The example of stakeholders with different agendas and different maturities was an example (in NHS environment) that I used for my RPP. Incidentally, NHS has a fourth step (after Simple, Complicated, and Complex) - Wicked. This refers to environments where the feedback between systems tends to be positive rather than negative, where a small problem is amplified into a gigantic problem, a small faux pas becomes a major diplomatic blunder and outright war.
A project isn't only Work, how this work is embedded in an organisation. Models of difficulty should look at the challenge of the work (complicated, complex, wicked are all useful concepts) but the capacity of, and work associated with, the organisations that are to perform it. You could have a) a simple organisation attempting complex work, or b) a cluster of firms running around each other (because organisationally complex) to manage a straightforward project scope. Sometimes this (mis)matching makes it way into models, e.g. Ashby's Law of Requisite Variety implies that the project organisation should have enough structure to cope with whatever the structure of the work at hand happens to be. In other words, a) won't work but b) might.
On the link to Melanie McBride's (Intel) complexity model, I'd argue that this isn't a model at all, but a *complexity scaling tool* that is essentially model-free. It is packaged with a list of complexity drivers, which may have come from a model, but could just be things on their worry list for other reasons. It's nevertheless a good exercise to compare elements in a programme in this sort of consistent way.
Thank you all for the responses. I can't 'reply' in line so I'll make a couple of points here. In terms of any nomenclature regarding complexity and complication. This is a difficult area as there are multiple sources, no definitive authority and conflicting interpretations. And example of it being argued both ways can be found at the two following links: https://sloanreview.mit.edu/article/the-critical-difference-between-complex-and-complicated/ https://english.stackexchange.com/questions/10459/what-is-the-difference-between-complicated-and-complex The only safe bet seems to be to define it oneself on an as needed basis.
To Adam Dear - thank you for your link to the Project Routemap framework. I make the distinction that complexity is manageable and can be quite separate to simple but difficult projects. Equally - I didn't realise this at the time, but my model at least offers the opportunity for an arms length assessment of difficulty from just the data in the plan. That's potentially quite a nice thing to have - particularly if you warehouse all your project plans. The idea to simply analyse the plan (and this could be done programmatically) to assess project difficulty is really attractive. That assumes my model is 'good enough' and there is an actual positive correlation between what my model suggest is difficult and what the PM's actual experience is. I guess the real question is whether the model I propose can actually be a predictor of project failure (on the basis that difficult projects must by definition fail more often).