A little over three years ago I was asked to review a transformation programme at a manufacturing group that had spent eighteen months and a seven-figure budget replacing its core operational platform. The brief was flattering in its vagueness: “come and tell us why it feels harder than it should.” I remember the phrase precisely, because it turned out to be the most honest description of the situation anyone in the building had offered.
On paper the programme was healthy. Fortnightly steering committee. A RAID log with several hundred entries. A delivery partner with a respectable name and a methodology with an even more respectable acronym. Integration, data-migration and change-management workstreams, and a PMO producing a status pack thick enough to prop open a fire door. By every conventional measure of programme governance, it was being run correctly.
And yet nothing moved. A decision that should have taken an afternoon took three weeks, because it touched four workstreams and no one could say which one owned it. A configuration change that looked trivial in the demo required sign-off from a forum that met monthly, so a two-hour task waited twenty-eight days for permission. The programme was not failing dramatically. It was quietly strangling itself.
Here is the thing that took me too long to understand about digital transformation failure, and that I now look for first: the problem is almost never scope, and it is almost never effort. It is complexity, and complexity is something a programme does to itself.
Complexity Is Not Scope
The word “complexity” gets used loosely, and that looseness is part of how the problem hides. People routinely conflate complexity with scope, and the two are not the same thing.
Scope is the volume of work a transformation intends to do, the number of processes, systems and users in the target state. Complexity is the number of interdependencies between the parts, and the degree to which those interdependencies are hidden, undocumented, or governed by different owners. You can double the scope of a programme and, if the parts remain loosely coupled, barely increase its difficulty. You can hold scope perfectly constant and, by adding a few cross-cutting dependencies and a couple of extra approval gates, make it structurally unmanageable.
This distinction matters because almost every instinctive management response to a struggling transformation adds complexity in the name of reducing risk. A decision keeps going wrong, so a new approval step appears. Two teams keep colliding, so a coordination forum is created. A supplier delivers something unexpected, so a more detailed specification process is mandated. Each intervention is locally rational. Each adds an interdependency, a handoff, or a gate. The aggregate effect, which no single intervention is responsible for and no single owner is accountable for, is a system harder to change than the one it replaced.
Fred Brooks drew the underlying distinction forty years ago in No Silver Bullet: some complexity is essential, inherent to the problem you are solving, and some is accidental, an artefact of how you chose to solve it. His argument was about software. It applies with more force to transformation programmes, because programmes generate accidental complexity through governance in a way codebases generate it through architecture, and unlike code, nobody refactors a governance structure.
Complexity of this kind is structural rather than individual. It emerges from the relationships between parts of the programme, not from the competence of anyone within it. You can staff a transformation with excellent people and still watch it seize up, because no individual is positioned to see the whole dependency graph. Each person optimises their own workstream; the interactions between workstreams are nobody’s job. This is why “the team needs to try harder” is the wrong diagnosis. Effort applied inside a badly coupled system does not reduce the coupling. It usually tightens it.
What follows is the framework I use to name the specific forms this takes. There are five, and they are deliberately chosen to be non-overlapping: each addresses a different surface of the programme, how the work is divided, who is allowed to say yes, what the past left behind, what the future is being bent into, and what the programme can see about itself.
The Five Complexity Traps
1. The Coupling Trap, the work is divided against the grain of change
This is the one strangling the manufacturing programme above. It shows up in two symptoms that are usually treated as separate problems: coordination overhead (people spend more time synchronising than doing) and dependency chains (nothing can move until something else moves first, and the critical path becomes a critical web).
They are the same disease. Both occur when boundaries between teams, workstreams or delivery stages have been drawn across things that change together. Conway’s observation that systems mirror the communication structures that build them runs in reverse here: draw your workstream boundaries badly and you will spend the programme paying a coordination tax to reassemble what you split.
The escape is to redraw the boundaries, not to coordinate better across them. Concretely:
Take the last twenty significant decisions the programme made. For each, record which workstreams had to be involved before it could be settled. This takes an afternoon and requires no new tooling.
Count the crossings per boundary. A boundary that is crossed by most decisions is not a boundary; it is a seam running through the middle of a single piece of work.
Merge across the highest-crossing seams into one team, one owner, one backlog. If two workstreams cannot decide without a joint forum, they are one workstream with a bad boundary, and merging them eliminates the forum rather than improving it.
For what genuinely must stay separate, sequence so that each stage can complete and deliver value before the next depends on it, accepting some duplicated effort as the price. Slack in the schedule is not waste; it is the shock absorber that stops one delay becoming ten.
The instinct to change the whole estate at once, process, data, platform, integration and org design in a single synchronised push, is usually justified on efficiency grounds. It is the single most reliable way to build a critical web.
2. The Permission Trap, too many people can say no
Formal approval gates and informal veto points look like different problems and are managed by different people, but they are one mechanism: someone must say yes before the work can move. Governance boards, review ceremonies, sign-offs, and the accumulating stakeholders who each acquire an opinion and a veto, all of them add latency to the same path.
Governance that is never pruned grows monotonically. Each gate is added in response to a past failure and none is ever removed, until a programme spends more energy asking permission than making progress. Meanwhile, as a transformation grows visible it accumulates stakeholders, and past a threshold it starts optimising for internal consensus rather than for outcomes. Consensus is not a governance model; it is the absence of one.
The escape is to audit permission as a cost and delegate it downward. Concretely:
List every forum, board and sign-off. For each, write down three things: what decisions it actually owns, its cadence, and the last time it rejected something. A gate that has never rejected anything is not a control, it is a queue.
Set a threshold. Route routine decisions below a defined cost or risk line to a single named individual inside the delivery team, and reserve the forum for what sits above it. Most programmes discover that the large majority of decisions are routine.
Publish decision rights explicitly, in advance: for each decision class, who decides, who is consulted, and who is informed. The value is not the document; it is that writing it forces the argument about authority to happen once, in the open, rather than continuously and by ambush.
Put an expiry date on every new forum. A gate that must justify its renewal is a gate someone will eventually let lapse.
I have never once seen a transformation suffer from too little governance. I have seen many suffocate under too much.
3. The Data Trap, the estate is dirtier than the plan assumes
Transformations routinely underestimate the complexity hiding inside their own data: undocumented business rules, special cases encoded in spreadsheets, fields whose meaning drifted years ago and are now maintained by one person in finance who is retiring in March.
The trap is not the mess itself. It is discovering the mess late, after the plan has hardened around an assumption of cleanliness and the budget has been committed.
The escape is to go looking for it before it ambushes you. Concretely:
Profile the production data, not the schema. Schemas describe intent; data describes what actually happened. Run distributions on every field that will be migrated and look at the tails, the nulls, the outliers, the sentinel values someone used because there was no proper field for it.
Find the shadow systems. Ask each operational team which spreadsheets they maintain and why. The answers map the business rules that never made it into the platform, and they are the ones that will break the migration.
Interview the exception handlers, not the process owners. Process owners describe the designed process; the people who handle exceptions know the real one.
Price remediation as its own budget line, established before design freezes. Data cleanup funded out of the change budget competes with functionality and always loses.
Do this in the first eight weeks or you will do it in the last eight, at four times the cost.
4. The Customisation Trap, the standard platform becomes a bespoke one
This is the slow bending of a standard platform to match every existing quirk of the organisation, until the off-the-shelf system is a bespoke one that must be maintained forever and cannot be upgraded. Each individual customisation is justified by a real process need. The aggregate re-creates the complexity the platform was bought to eliminate.
Note that this trap and the Data Trap are mirror images: one is complexity inherited from the past, the other is complexity being manufactured for the future. They need opposite disciplines, curiosity about the first, resistance to the second.
The escape is a standing presumption in favour of the vanilla process. Concretely:
Require every customisation request to name a lifetime owner: the person or function accountable for maintaining and re-testing it at every upgrade for as long as the platform lives. Requests frequently evaporate at this step.
Force the request to state what the process difference is worth, in cost avoided or revenue enabled, not what it is. “This is how we do it” is a description, not a justification.
Track the customisation count as a headline programme metric with an agreed ceiling. Once the ceiling is a number on the front page, the trade-off becomes visible to the people making it.
Time-box the exception. Approve customisations with a review date at which the default is removal unless someone re-argues for it.
The question is never “can we configure this?” It is “is this difference worth carrying forever?”
5. The Measurement Trap, the programme cannot see its own complexity
This is the most insidious, because it disguises the other four. It occurs when a programme measures activity, tasks closed, workshops held, documents produced, RAID entries logged, rather than outcomes, so a transformation drowning in complexity reports itself as busy and therefore healthy. The status pack that propped open the fire door was a monument to this trap.
The escape is to measure the things complexity actually degrades. Three signals, none of which can be improved by working harder, because effort is precisely what they hold constant:
Decision latency, time from a question being raised to an answer being given.
Change lead time, time from request to live. This one is borrowed directly from the DORA research on software delivery performance, where it has been validated at scale; it transfers to transformation programmes with no modification.
Rework rate, proportion of delivered work that has to be redone.
Decision latency is the least standard of the three and the one people most often ask how to instrument, so specifically:
Keep a single decision register. Every request for a decision is logged with the date raised, the named owner, and the date an answer was given. Report the 90th percentile, not the mean, the mean is dominated by the trivial decisions and hides exactly the ones that are hurting you. Two things will try to defeat this. The first is people stopping logging, which you solve by making the register the only route to an answer: an unlogged question does not get one. The second is gaming through pre-approval, where a team makes latency look good by waving through decisions that deserved scrutiny. That is why the three metrics are reported together, pre-approved bad decisions surface as rework two months later, so latency and rework rate check each other. Neither number means much alone.
Making Subtraction Politically Survivable
Every escape above takes something away from someone: a forum they chaired, a sign-off that signalled their importance, a customisation their department fought for. This is the part most frameworks skip, and it is where most of them die. Organisations are far better at addition than subtraction. Three things help:
Do it at a natural boundary. Replans, phase gates, budget cycles and partner changes are moments when structural change is expected. Proposing a merge of four workstreams mid-phase reads as a criticism of four owners; proposing it as part of a replan reads as planning.
Give displaced owners something to own. The person whose forum you delete needs a role in what replaces it, ideally a more consequential one, the delegated decision authority, the named owner of the merged backlog. Complexity removal fails far more often on dignity than on logic.
Let the numbers make the argument. “Your board is a bottleneck” is a personal accusation. “Configuration decisions have a p90 latency of twenty-eight days and eighty per cent of them fall below the risk threshold” is an observation about a system. The metrics from Trap 5 are not just diagnostics; they are the political instrument that makes subtraction discussable.
What Actually Changed at the Manufacturing Group
We did not add anything. That was the first and hardest decision, because every instinct in the room was to install a new control.
We spent two weeks mapping the actual dependency graph, which decisions touched which workstreams, and which forums had authority over what, and the map made the Coupling and Permission traps impossible to ignore. There were eleven standing forums. Four existed only to reconcile the outputs of the other seven.
We collapsed the four workstreams that were colliding most often into a single team with a single owner and a single backlog, which eliminated the reconciliation forums entirely because there was no longer a boundary to negotiate across. We took the monthly configuration-governance board and gave its routine decisions to a named individual in the delivery team, reserving the board for changes above a defined cost and risk threshold, turning a twenty-eight-day wait into a same-day answer for roughly four in five requests. And we replaced the front page of the status pack with three numbers: decision latency, change lead time, open rework. The first fortnight those numbers were embarrassing, which was the point. They were the first honest signal the programme had produced in a year.
Within two months the programme was visibly moving again, not because anyone worked harder, but because friction had been removed from the paths that mattered.
The standardisation discipline did not work, at least not immediately. The organisation had committed to a raft of customisations before I arrived, and unwinding a decision is far more expensive than not making it. We stopped the bleeding on new customisations and had to live with those already in flight. That is the honest version: some traps you escape, and some you have merely stopped digging deeper into.
Where This Framework Breaks Down
A framework that claims to explain everything explains nothing, so the limits matter.
Complexity reduction has a floor. Some transformations are genuinely, irreducibly complex, a core banking migration, a safety-critical systems replacement, and past a point, stripping out coordination or governance does not simplify the work; it removes controls that were legitimately holding a dangerous thing together. Distinguishing accidental from essential complexity, in Brooks’s terms, is a judgement this framework informs but cannot make for you. Apply the escapes indiscriminately and you will eventually decouple something that needed to be coupled, or delete the one gate standing between you and a regulatory breach. The audit questions in Trap 2 are designed to surface this: a forum that regularly rejects things is doing work.
The political fixes are not reliable. The three moves above improve the odds; they do not guarantee outcomes. In more than one programme the diagnosis was correct and the recommendation still failed, because the person who owned the redundant governance forum also owned the budget. Naming a trap does not neutralise the interests that built it.
The metrics can become the disease. Goodhart’s law applies here as everywhere: a measure that becomes a target stops being a good measure. Pairing latency with rework raises the cost of gaming but does not eliminate it. These three numbers are a diagnostic instrument, not a steering wheel, and the moment a programme is managed to them rather than informed by them, they have joined the Measurement Trap they were meant to expose.
Five is a working taxonomy, not a natural law. I have stopped finding categories that do not reduce to these five, but the value is not in the number. It is that a trap with a name can be governed, and one without a name feels like the weather.
The Deeper Pattern
Underneath all five: complexity is not something that happens to a transformation. It is something a transformation does to itself, one locally sensible decision at a time, in the sincere pursuit of control.
Nobody sets out to build a programme that strangles itself. They set out to manage risk, and they manage it the only way most organisations know how, by adding structure. Past a certain density, the structure built to hold the risk becomes the risk.
The organisations that transform well are not the ones with the most sophisticated governance. They are the ones with the discipline to treat every unit of complexity as a liability that must continually justify its existence, to ask of every forum, gate, customisation and dependency not “is this useful?” but “is this useful enough to be worth what it costs us in speed?”
Most complexity fails that test. Adding it was never the hard part.