One of the biggest technology disasters I’ve seen at ground zero is much more easily understood when it’s viewed through a Cynefin lens. And as you’ll see, this description of Disorder is particularly useful.

What is Cynefin?

If you don’t know what Cynefin is, it’s a classification framework that I’m finding increasingly useful in “what problem do we have?” situations. It consists of a number of domains of situations, each of which suggests a different approach.

Chris Matts’ summary is below, and you can read a longer description too.

Cynefin Brief Summary

The Cynefin model consists of four quadrants of “Simple”, “Complicated”, “Complex”, and “Chaotic” and a fifth quadrant “Unordered” for when you do not know which of the other quadrants you are in.

A “Simple” system is over constrained and has cause/effect behaviour.

“Complicated” is the realm of the expert.

“Chaos” means there are not enough constraints.

“Complex” means there are just enough constraints to create an emergent behaviour which can be nudged and tweaked into a system with desirable behviour.

“Complicated” means an expert can reduce the problem to component parts with predictable behaviour.

“Complex” means there are feedback loops, agents and limits that create an emergent behaviour that cannot necessarily be predicted.

Essentially, the difference between the two can can be distilled to “A complex system interacts with its context and evolves as a result, and a complicated system does not interact with its context or evolve.”

Chris Matts
Cynefin's 5 domain mode

Cynefin’s 5 domain model, based on a great illustration by Rob England


At the outset, this project was Simple in concept. It was a national retailer, whose Point of Sale system ran on Windows 95, which was already out of support. So, when your bicycle chain falls off, you put it back, and when your tills go out of support, you upgrade them to WinXP or Vista as the then latest Microsoft OS. Simple.

OK, rolling this out across a national network in a rapid, non-disruptive way did have Complicated elements of scheduling, but the problem at heart was definitely Simple. At First.

No, Complicated

In the original negotiation and contracts phase, it was decided that not only were the tills to be simply replaced (the upgrade also meant some hardware upgrades too), all the stores (and central) would move to a full Active Directory setup to create all kinds of future options for management.

OK, so there are quite a few ways to do that, and which one you want takes some analysis to determine the most effective configuration. And now it definitely takes expertise in design, planning and implementation. So, we’re Complicated, right?

We should be able to just plan the work and work the plan. In this context, a fair amount of BDUF is warranted, or perhaps a lighter design, with a pilot just to be certain and help the design/planning process cope with the level of detail it’s hard to know in advance. So maybe just a touch of Complexity, but only at the very detailed level, which always is Complex, because that’s life.

But this is the deal we signed up to and is absolutely clearly what’s in the contract. A large number of deliverables, starting with designs and plans, proceeding through code and configuration and then the changes landing in stores in an orderly way. And payments tied to achieving them. As I said, this is reasonably sane, given a Complicated context.

My job in all this is to make sure we get paid by managing the Deliverables process through to approval, linked to an integrated plan, with forecast back to our base about when the pretty substantial lumps of money might arrive, with material affect on our quarterly results.

Ah but now it gets Interesting.

Wheel in the Consultants and NOW we have Complexity

Someone far cleverer than me had a bright idea. Rather than replacing like with mostly-like-with-upgrades, that someone realised we had business consultants on hand (and on the bench), with specialism in retail and some bright ideas about how a PoS could work in the future.

So somehow the scope now included changing the till software to something whizzy. Which had many many options for how it could work.

And those consultants did the most dangerous thing for a Complicated project: they asked the customer’s own people open-ended questions (along with prodding with blue sky ideas) about what they wanted.

And now we have many stakeholders, in both customer and delivery organisation, each with multiple ideas about what the PoS of the future could be, all with expectations that it could and (more importantly) should be included in the scope of this very large project.

We’ve all seen this, right? The whole “Well, while we’ve got the lid open…” open door to all the crazy ideas that have been floating around for a while, combined with the joint honey pots of a large budget and an overall initiative that is deemed business critical and therefore uncancellable.

So now our Complicated analysis of the options that Microsoft offers in the desktop & networking infrastructure space (albeit one specialised area) has become Complex as multiple agendas are being floated.

Enter the Chaos Monkies

From some of the customers’ key stakeholders, including many in their enterprise architecture community and almost all of their business continuity people, this is terrifying.

PoS is the only means by which this organisation takes in money. It is absolutely the heart of the business. And we’ve gone from an absolutely necessary transplant which is risky enough, to one which is designing a bionic heart as it goes along using technology which has only been read about in a few airline magazines.

Our absolutely terrified architects happen to be critical reviewers and approvers of all the design documents. And the code deliverables. And our absolutely terrified biz continuity people happen to be critical reviewers and approvers of the implementation plans.

So they refuse to accept any of the deliverables, and in some cases, block any progress very early in the review process. Despite the fact that contractually we have the right to force them through (because the contract was written in the Complicated phase which still recognised a significant Cost of Delay impact), we don’t.

So our Chaotic situation keeps resolving itself unhappily: deliverables are not accepted. We miss key milestones that depend on them. We don’t get paid for any of the 100+ people working on the programme.


At the working level, hands on with the actual content, we’re in Complexity.

Commercially, and in our overall Program Management we’re in Chaos.

The Program’s management back at our base think we should just enforce compliance with the Complicated contract.

And the customer’s execs view this as a Simple (albeit large) problem whereby their tills are still out of support and every day this brings risk (and large sums of money to Microsoft).

We can’t get out of this situation because the different communities don’t agree on what the situation is.

And we spin like this for months. And months. And months.

Biggest delivery disaster I ever saw? It’s hardly a surprise, is it?

Follow me
Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 Disorder: A Cynefin Disaster Movie by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: