Why transformations fail after go-live, and what to ask before you close the project

Most transformations do not fail at delivery. They fail after delivery.

The dashboard is green. The system is live. Training is complete. The closure report says successfully delivered. Then, six weeks later, teams are still using the old workarounds, managers are still following the old approval process, the new capability is technically available but operationally optional, and nobody can point to the business benefit that was supposed to justify the whole programme.

That is not transformation. It is administrative completion, and the two get confused constantly because they produce the same closure report.

A project manager asks whether the output was delivered. Did the system go live. Did training happen. Did the plan close on scope, time, and budget. Those are legitimate questions, and answering yes to all of them still leaves the real question untouched.

A transformation leader asks a different set of questions, and asks them after go-live, not before it. Who is actually using this. Which behaviours have changed. Which old processes have actually stopped, not just been made optional. What measurable benefit has been realised. Who owns adoption once the project team has been reassigned to the next thing. Delivery proves that an output exists. Adoption proves the organisation changed. Benefits prove the change was worth doing.

The incentive structure around most projects rewards the wrong finish line. The project team is measured on hitting go-live, the PM moves to the next assignment shortly after, and the people left holding the new capability, the line managers and frontline staff, were never given ownership of making it stick. Nobody is deliberately lying in the closure report. The report is simply measuring the thing that was easy to measure at the moment it was easiest to measure it, which is whether the system works, not whether anyone changed how they operate because of it.

That gap is invisible in the closure meeting because everyone in the room, sponsor included, wants the same clean answer. It becomes visible six weeks later, in the numbers nobody is tracking anymore because the project has already closed and moved off everyone’s dashboard.

A new capability being available is not the same as an old process being retired. If the previous approval route, spreadsheet, or workaround still functions, some part of the organisation will keep using it, usually the part under the most pressure, because reverting to a known process under stress is a completely rational choice for an individual manager even when it is the wrong outcome for the organisation.

This is why the system is live is such a weak signal of success on its own. The real signal is whether the alternative path has actually been switched off, made harder to use than the new one, or removed entirely. If nobody has done that deliberately, do not be surprised when adoption stalls quietly instead of failing loudly.

Run this before the closure report goes out, not after someone else asks the question you should have asked first.

Usage. Is anyone using the new capability without being reminded, chased, or mandated to, this week, not in the pilot phase?

Retirement. Has the old process actually stopped functioning, or does it still exist as an option someone under pressure will quietly fall back to?

Behaviour change. Can you name one specific way a manager or team now works differently, in their own words, not in the training deck’s words?

Benefit evidence. Can you point to one measured number, not an assumption, that proves the expected benefit is showing up?

Ownership after closure. Who is accountable for adoption and benefit realisation once your project team is reassigned, and do they know that responsibility has actually transferred to them?

The leadership shift underneath all of this is simple to say and genuinely uncomfortable to practise: do not manage only towards go-live, manage towards realised value. That usually means keeping a light version of the programme accountable for a period after go-live, with a named owner and a small number of adoption metrics, rather than declaring victory the moment the system is technically available.

This is exactly the conversation worth rehearsing before your closure or post-implementation review, because the sponsor questions in that room are rarely about whether the system works. They are about whether the change was real. PM Strategy Advisor helps you walk into that review with the five answers above already prepared, instead of finding out live which one you cannot answer.