Ensuring Project Complexity has been Properly Assessed and Acted Upon

We've had an initial look at how we typically understate risks, but there's another question:  Are you implementing into a stable organisation?

It's a bit of a trick question, isn't it?  You'd love to say "yes", but you know the more accurate answer is "no". You know you live and work in an evolving and changing organisation in which any structure that you can clearly perceive is already the past, and what instead matters most may be the "perturbations" on the edge of the current structure, which have the potential to manifest a substantive change.  But will that change your implementation plan?  The temptation to make the assumptions that the organisation is simple, linear, equilibrium-seeking and isolated is extraordinarily strong, because it gives you the feeling of control.  But it is illusory.

For the sake of this discussion, let's define a scale of complexity to describe the organisation as a system (in the engineering sense):

• Simple  - Least complex
• Complicated
• Complex - Learning to predict outcomes is expensive
• Chaotic - Practically unpredictable (but not technically random)

If the organisation was a Simple system, changes would be easy - you would simply categorise the problem and apply a best practise that addressed the issue.  Experience tells me that this works occasionally, usually on a very small scale.  On the other hand, I've seen many implementations of ERP systems trying to apply "best practises". Typically the organisation finds its own approach once the consultants leave.  So once the implementation group exceeds about a dozen, then it is no longer appropriate to describe the organisational behaviour as Simple.

Some organisations can be categorised as Complicated systems.  Such organisations respond well to expert intervention; examples of these organisations are certain kinds of industrial operations.  In these organisations toolkits such as Six Sigma and the Theory of Constraints (Lean) work well.  If the organisation can be disassembled into components, optimized, and then reassembled to create a better functioning whole, then this is the domain you are in, and you should follow the Six Sigma mantra of "DMAIC" - Define, Measure, Analyze, Improve, Control.  But remember that manufacturing and distribution is only a component of what the organisation does, and these tools may not be appropriate elsewhere in the organisation.  And how can you tell in advance whether your industrial operation is suitable for intellectual disassembly?

I hate to think of organisations as Chaotic, because it's possible I'm being led by fashion, however in my opinion most sizable organisations are certainly Complex, and possibly Chaotic in their behaviour.  They respond to changes in ways that aren't obvious.  And when you change a component of the organisation defined by the scope of the project, it has interfaces into the rest of the organisation:  The scope is not the change!

We often hear quoted the idea that "insanity is doing the same thing again and again and expecting different results" - variously attributed to Albert Einstein and Benjamin Franklin.  However, for organisation systems with high degrees of complexity, insanity may well be doing the same thing twice and expecting the same results - because you make the changes at different times, the system you are changing is different!  Because you've already made a change to a part of the system, then the system you are changing is different!  This is the domain for which the famous "butterfly effect" is a metaphor.  Tiny changes in initial conditions may (or may not) yield substantially different end results.

In such complex organisational systems, the expert is powerless, and you are left with testing, piloting, rolling-out and correcting - an organic, evolutionary approach to change, in which you attempt to learn as you go along, but should not be surprised that you fail!

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Complexity, Chaotic