TL;DR
A transformation programme is structured to conclude. The end date, the seconded team, the temporary authority and the external partner are all withdrawn at closure, which is the moment new behaviour most needs support. What decays afterwards is not the technology, which stays installed, but the conditions that made people work the new way. Two or three years later the same symptoms return, a new programme is proposed, and the cycle costs more than the original because the organisation has learned that change is something that happens to it and then stops. A rate has no closure event, so nothing is withdrawn and there is nothing to decay from.
The closure meeting is usually a good one. The programme director thanks the team, the steering group signs off the benefits case, the partner presents a handover pack, and somebody takes a photograph. The mood is genuine. Most of what was promised has been delivered.
Eighteen months later the business has the system and not much else. The new process is followed in two teams and worked around in the rest. The governance forum stopped meeting in the spring. The person who understood the design has been promoted into something else, and their replacement inherited a document instead of a reason.
Nobody did anything wrong. The programme was closed exactly as designed, and closure is the problem.
What a programme actually installs
A transformation programme installs two things, and the business only pays attention to one of them.
The visible one is the technology and the process design. That part persists. Nobody uninstalls a platform when a programme ends, and the process documentation stays on the intranet.
The invisible one is a temporary operating system running alongside the real one. For the duration of the programme there is somebody whose whole job is this change. There is a forum that meets weekly with senior attendance. There is permission to override normal priorities. There is an external partner who will chase things and whose invoice creates urgency. There is a reporting line straight to an executive who asks about it.
That second system is the reason new behaviour happens. And every component of it is designed to be withdrawn at closure.
Why closure is the worst possible timing
New behaviour is at its most fragile just after it becomes routine.
At go-live people are attentive, supported and a little anxious, which is a good combination for doing things properly. Three months later the attention has moved on, the workarounds have started reappearing at the edges, and the question of whether the new way is really compulsory is being quietly tested.
That is the moment the programme structure disappears. The forum stops. The dedicated owner returns to their previous role. The partner’s contract ends. The executive attention moves to the next thing on the agenda, which is usually a different programme.
So the support is removed at the exact point where its absence has the greatest effect. What follows is not a collapse. It is a slow return towards whatever the organisation found easiest before, which is what it was always going to do once nothing was holding it.
What decay actually looks like
Decay is undramatic, which is why it is rarely reported.
A field stops being filled in properly because the report that used it was retired. A stage gets skipped when the month is busy, then skipped when it is not. Two teams develop slightly different interpretations of the same step, and both are defensible. A spreadsheet appears alongside the system, first as a temporary workaround during a busy period, then as the real record.
None of these is a failure anyone would escalate. Each is a small local judgement made by someone acting sensibly under pressure. The sum of them is the operating system reverting.
By the time it becomes visible, usually through a customer complaint or a number that stops making sense, the original design is two years old and the people who understood the reasoning have moved on. What is left is a set of rules that nobody can justify, which is the worst possible condition for any process, because rules without reasons get followed badly or not at all.
The restart cycle
Here is what makes this expensive, not merely disappointing.
The symptoms return. Someone proposes a programme to address them. The business case is written against the same symptoms as last time, often by people who were not there for the last one. A partner is appointed. A forum is convened. The temporary operating system is stood up again, and for eighteen months things improve.
The second cycle costs more than the first, for reasons that have nothing to do with the work. There is scepticism to overcome, because a proportion of the organisation remembers the last attempt and has concluded that these things do not stick. There is accumulated complexity, because the previous design is still partly in place and cannot simply be replaced. And there is the cost of relearning what the last programme knew, which was never written down in a form anyone could use.
A business on its third cycle has usually spent more on repeated transformation than a continuous alternative would have cost, while ending up roughly where it started. The unit of failure is not the individual programme, which may have run perfectly well. It is the pattern.
Where programmes are the right answer
Some changes genuinely have an end state, and treating those as continuous work would be a mistake.
A core system migration finishes. A merger integration finishes. A site closure, a regulatory implementation with a statutory deadline, a rebrand. These have a defined completion, a temporary structure is appropriate, and closing it afterwards is correct because there is nothing left to do.
The error is applying that shape to something with no end state. Improving how decisions get made, how work moves between teams, how standards hold under pressure: none of these has a completion date, and giving them one guarantees the decay.
What Business Evolution addresses is whether the business works well the day after a programme completes. It is the deliberate, continuous building of organisational capability at the rate a business’s ambition requires. Deliberate means designed instead of assumed. Continuous means it has a rate instead of a completion date, which is the property that does the work here.
What a rate requires
A rate is not a smaller programme running forever. It is a different structure, and six conditions sustain it.
An owner who does not disband, so improvement belongs to a permanent role instead of a temporary one. A cadence inside the management rhythm that already exists, because a new improvement forum is the first meeting cancelled when things get busy. A limit of three to five live improvements at any time, since fifteen agreed actions that drift are worth less than a handful that complete. Removal alongside addition, so the operating system does not get heavier with every cycle until people route around it. A review that catches decay while it is still small, because a blurred definition can be corrected in a conversation and left for two years it becomes culture. And leadership reinforcement under pressure, since any system looks disciplined in a quiet month.
None of these needs a budget code. All of them need somebody to still be responsible in eighteen months.
The question worth asking at closure
If you are near the end of a programme now, there is a more useful question than whether the benefits case was met.
Which specific things are currently holding the new behaviour in place, and which of them disappear next month?
Write the list. It is usually shorter than people expect and it is almost always entirely made of temporary structures. Whatever is on it is what you need a permanent version of, and it is far cheaper to arrange before closure than to rebuild after the decay.
If a programme in your business is approaching closure, write down what is currently holding the new behaviour in place. The dedicated person, the weekly forum, the partner, the executive who asks about it. Then mark which of those disappears within a month of sign-off. That list is your decay risk, and arranging a permanent version of it now costs a fraction of rebuilding it in two years.
Series navigation
This is the first of five articles setting out the case for Business Evolution. Each stands on its own, and they build in order.
Previously: Capability is the connection between AI spend and business value. Two businesses buy the same tool and get different outcomes, and six measures make the difference observable. Read it at Capability is the link between AI spend and business value
Next: Three altitudes of change: organisation, workflow, task. The same weakness looks different depending on how closely you look at it, and choosing the wrong altitude is why improvement efforts miss. Read it at
The full definition sits on the pillar page: What Business Evolution is.
The five
- Your AI business case assumes a capability you may not have.
- Capability is the connective tissue between AI spend and business value.
- Why transformation programmes keep failing the businesses that buy them. You are here.
- Three altitudes of change: organisation, workflow, task.
- What a management discipline needs before it earns the name.
Most do not fail during delivery. They deliver the technology and the process design, then decay afterwards, because the structures holding the new behaviour in place are designed to be withdrawn at closure. The dedicated owner, the governance forum, the temporary authority and the external partner all end on the same day, which is shortly after new behaviour has become routine and is at its most fragile.
Programme decay is the gradual return of an organisation towards its previous way of working after a change programme closes. It is undramatic: a field stops being filled in, a stage gets skipped in a busy month, two teams develop different interpretations, a spreadsheet appears alongside the system. Each is a sensible local judgement, and the sum of them is the design reverting.
Three reasons, none of them about the work. Scepticism, because part of the organisation remembers the last attempt and believes these things do not stick. Accumulated complexity, because the previous design is still partly in place. And the cost of relearning what the last programme knew, which was rarely written down in a usable form.
When the change has a genuine end state. System migrations, merger integrations, site closures, regulatory implementations with statutory deadlines. These complete, a temporary structure is appropriate, and closing it afterwards is correct. The error is applying that shape to work with no completion date, such as how decisions get made or how standards hold under pressure.
An owner who does not disband, a cadence inside the management rhythm that already exists, a limit on how many improvements are live at once, removal alongside addition so the system does not get heavier, a review that catches decay while it is still small, and leadership reinforcement when the business is under pressure. None of these needs a budget code.
Alastair Jupp writes on organisational capability and the practical adoption of AI. The argument here is developed at length in Workflows, Decisions, Discipline: The Operating System Behind Every High-Performing Business, published by Edge151 later this year. Details and publication updates.
Discover more from Edge151
Subscribe to get the latest posts sent to your email.