This column will be a bit of a departure from the previous few. Here I am not going to be talking about technology, or business, or government policies. But to some extent I am going to talk about the place where they all meet. The Project – and the management thereof.
By project I mean, specifically, the project that delivers a product or a service that has been contracted for by a customer with a supplier. Most of the time, I am going to be thinking specifically of projects run by government to develop, procure, maintain, and sustain some particular new piece of hardware or software – or both. The discussion is not limited to government projects though. The concept of complexity in project management applies pretty much anywhere.
In the context of project management complexity has a very specific meaning. The term was “coined” by David Snowden and Mary Boone, two researchers working in knowledge management. It was part of a framework they developed that they dubbed Cynefin (pronounced “ku-nev-in”) which is a Welsh word that means roughly “place” or “habitat” but really also implies a sense of “where are we and how did we get here.”
This Cynefin framework is a way of categorizing problems or challenges in terms of how ordered they are and how predictably they respond to decisions and actions. The are four categories of problem in order of increasing degree of difficulty are “Obvious,” “Complicated,” “Complex,” and “Chaotic.”
There is a whole body of research on this topic and I don’t really want to go any further down that rabbit hole here. My experience of this material is strictly from the perspective of a “user” of the material – as opposed to being a “developer” who understands it in great technical detail. For me the most important distinction is between Complicated and Complex. Here is how I see the difference.
I am going to describe it in terms that make sense to me as a physicist (by training). A Complicated system is one that has many interacting pieces – but it is a “closed system.” All of the interactions are internal to the system. All of those interactions are, or can be, well characterized and understood. It is therefore possible to predict the systems behaviour to changing any of the inputs or the operational “parameters.”
This ability to document, characterise and then change a projects reaction to various stimuli is central to the traditional approach to project management.
Complex projects, on the other hand, are what a physicist would call “Non-Deterministic” and “Non-Linear.” In other words, their behaviour cannot be predicted accurately because they defy prediction both in terms of where they go and how fast they get there.
As such, they defy classic project management approaches which put a premium on collecting high quality data and making plans based on accurate predictions. The realization that the Cynefin model acknowledges is that complex problems are not just poorly understood versions of complicated ones.
Their unpredictability is unavoidable and natural.
But where does it come from?
Complexity arises because the interaction or a variety of forces – internal and external. These interactions cannot be predicted and often they cannot be controlled. They lead to “emergent behaviour.” Emergent behaviour means actions and reactions that were not predicted and were not part of the original model – even as a contingency.
It is very important to realize that emergent behaviour is not the result of failure of planning or execution. Emergent behaviour is the inevitable consequence of a system that simply cannot be fully understood and modelled from within the system.
Why is that realization so important?
It’s important because when standard project management practices are applied to complex projects they almost always fail. Often they fail dramatically. Often they make the problem worse. This is because standard Project Management practices put a premium on devising and then executing a plan. They put a premium on understanding how the plan is being deviated from, applying corrections and then measuring effect of those corrections.
But, as any experimental physicist – or test engineer – will tell you, this works fine in a system that is well characterized, and reasonably linear, and deterministic. In a system that is none of those things it doesn’t work well at all. Because the system is not well characterized or deterministic injecting new corrections tends to drive it unexpected directions – leading to even more emergent behaviours.
Because the system is non-linear, these effects can appear to be out of all proportion to the correction applied. When this process is iterated – adding more corrections to correct further variances – the whole process rapidly comes off the rails and management and the team end up spending their time looking backward and analysing their failures instead of looking forward and anticipating success.
Since analysis of failure becomes the primary mode of management, it creates an atmosphere on the project where it is more important to avoid blame for those perceived failures than to attempt to find ways to make the project successful in the end.
The really big issue is that this approach to working on projects can, and does, become a cultural value in an organisation. People within the system get acculturated to equating avoiding blame as being equivalent to achieving success.
It isn’t.
So, what can be done in the face of these odds. Well, tune in to the next one of these columns to find out.
