Transformation Debt: Inheriting the Unfinished Work of the Last

Why programme closure and transformation completion are not the same thing

Most transformation plans are very clear about what will start. The new system, process, roles, controls and measures all have owners and milestones. What is often much less clear is what the organisation will stop doing once the new way arrives.

So the new platform goes live, but the old spreadsheet stays, just in case. A new approval route appears, but the email sign-off survives. A dashboard is launched and the old report is still produced. People learn the new process, then find that another team still uses the old one. Each task looks reasonable on its own. Together, they turn one job into two. That's transformation debt.

Over the years, I've come to think that we are much better at introducing the future than retiring the past. We then wonder why the expected productivity does not appear and why people find themselves working across several versions of the same organisation.

If nothing actually stops, transformation has not changed the work. It has added another layer to it.

The work that accumulates between programmes

The problem is not only that programmes overlap. Each new programme tends to assume the last change is already part of normal work. Often it is not, so unresolved decisions and temporary workarounds become the starting point for whatever comes next.

A portfolio chart can keep the programmes in neat columns. A working day cannot. The same person may be expected to use a new system, follow an old approval, report against a revised measure and maintain a local workaround because the official process still cannot handle every case. When those demands meet in one role, somebody has to decide which process really applies and which measure matters this week.

The effect is often discussed through adoption, engagement or readiness. Those things may matter, but they can obscure a more practical cause. Old expectations remain, new ones arrive, and the work expands without anybody making a deliberate choice about what should disappear.

A useful way to think about that residue is as transformation debt: the operational cost left behind when change is delivered but never fully integrated into how work happens.

It includes the old system that must still be maintained, but it is wider than technology. It also lives in duplicate decisions, measures, controls and workarounds that people must continue to service.

There may be something very human beneath this. Across eight experiments published in Nature, people asked to improve objects, ideas or situations tended to search for additions and often overlooked useful subtractive changes. Organisations reward much the same instinct.

Starting a programme is visible and launching a tool looks like progress. Removing an old report, approval or system attracts less attention and often involves a harder decision. Yet capacity is only created when people can actually stop doing something.

Programme closure is not operational completion

Birmingham City Council offers a stark example of the distance that can open up between implementation and working reality. Its Oracle system went live in April 2022.

For 2024/25, the council allocated £5.3 million for Transaction Services staff to run manual workarounds and provide backfill so subject-matter experts could be released to support the work. I’ve experienced this myself during a finance transformation in a global business, so the gap between implementation and working reality is not confined to one industry or function. The £5.3 million figure exposes the human cost of unfinished change. People reconciled the numbers, maintained the workarounds and kept services moving. The system was live, but the organisation was still paying for people to bridge the gaps around it. Implementation isn't transformation - Integration is.

In January 2026, the council postponed an April relaunch until at least the summer after reviewing testing and operational readiness. Accuracy of staff pay was one reason given for allowing more time. After what had happened, the decision recognised that a date could not stand in for a functioning way of working.

The Scottish Government's March 2026 closure report for its shared HR, Finance and Purchasing platform offers a candid counterpoint. The system went live in October 2024 and the first programme phase closed in March 2025. The report says the goals were achieved while acknowledging persistent Time and Labour issues, deep frustration for some colleagues, EPM functionality still due in 2026 and further work to optimise operating models. Its warning was clear: the greatest risk would be to stop at phase closure. Closing a delivery phase and completing the transformation are not the same event.

Systems make unfinished work unusually visible, but the same debt can sit unchecked in a recurring meeting, an inherited approval, a duplicated measure or a decision that nobody now owns.

There are valid reasons to run old and new systems together for a period. Service continuity, data integrity and risk matter. The problem begins when the overlap has no credible end, or when nobody has the authority, evidence or confidence to turn the old way off. Parallel running becomes permanent working.

A stop list therefore cannot be a line added to the project plan just before launch. It changes how the transformation is designed and forces different questions earlier. Which task will disappear? Which system will be retired? Which report will no longer be requested, and what evidence will make it safe to let go?

Stopping is a leadership decision

Stopping is not a tidying exercise. Old tasks survive because they once protected something important. A report has an executive audience. An approval gives someone comfort. A spreadsheet contains knowledge the new system has not yet earned. Nobody wants to remove a control and then discover why it existed. In my experience, old work rarely disappears through common sense alone. It needs an owner and an explicit decision.

Letting go safely requires cross-functional judgement. Operations understands the consequence. Technology knows what can be switched off. Risk and compliance can separate a real obligation from a habit that has grown around it, while Finance can test whether the benefit is appearing. HR and learning can help people build the judgement and confidence the new work requires.

But people also need clarity about which old rules have ended, and leaders have to remove the old demand and stand behind that decision.

The leadership test is practical. For every material change, can we say what people will no longer have to do? Do we know who has the authority to stop it, when it will disappear and what will be monitored afterwards? Can we show that the time saved has been returned to the work it was meant to improve, rather than filled with another layer of activity? Asking these questions early gives the organisation a better chance of removing complexity rather than relocating it into somebody's working day.

A transformation should leave people with fewer contradictions and clearer decisions, not two versions of the truth because the difficult work of letting one go was never finished.

The next transformation can begin by finishing what the last one left behind. If the start list grows and the stop list stays empty, we are not transforming work. We are asking people to carry more of it.