Infrastructure South Australia’s assurance framework contains a quiet admission. It provides for health checks where the time between gateway reviews is excessive. Read that again. A gate-based assurance regime, conceding in writing, that the gaps between the gates are where the risk lives.

Now apply that logic to the one gate almost every programme treats as final.

Go-live is the last gate most technology programmes have. There is no gateway review scheduled after it, because after it there is no programme. The steering committee that met monthly to protect the investment meets once more, notes the successful cutover, thanks the team, and stands down. By the framework’s own reasoning, everything that follows go-live is the largest gap in the entire lifecycle. It is also the only gap for which nobody commissions a health check.

This is where the value goes.

Not in the build. The build is watched by everyone: vendor, integrator, PMO, sponsor, steering committee. The business case is at its safest when the most people are paid to look at it. The benefits that justified the programme are lost afterwards, in the first year of business-as-usual, when the watching has stopped and the case that promised them is a filed document with no owner.

The first ninety days

Watch what actually happens in the ninety days after a successful go-live.

The system integrator demobilises. This is not a failure, it is the contract working as designed. The solution architects and senior configurers, the people who know why the system was built the way it was, move to their next client within weeks. What remains is a support arrangement scoped for defects, not for benefits.

The programme team disbands. Contractors finish. Seconded staff return to roles that were backfilled in their absence, or discover those roles no longer exist in the same shape. The programme’s institutional memory walks out the door in ones and twos, politely, with handover documents nobody will read.

The sponsor goes back to the day job. Sponsorship is attention, and attention is finite. A sponsor who spent eighteen months defending a programme’s funding has eighteen months of neglected priorities waiting. The forum that held them to the case no longer meets.

And the measurement, the baseline, the tracking, the benefits register, was almost always scoped as a project deliverable. The project closed. The deliverable was delivered. Nobody now produces it.

None of these people did anything wrong. Every one of these dissolutions is scheduled, budgeted and correct. That is precisely the problem. The structure that owned the benefits case dismantles itself on plan, and no equivalent structure is stood up in its place. The business case survives closure. Its custodians do not.

Why this is not a change management problem

The standard answer to post-go-live value loss is adoption. Invest in change management, drive usage, and the benefits will follow.

Adoption is necessary. It is nowhere near sufficient.

A workforce can use a system perfectly while the benefits it justified quietly fail to arrive. Logins are healthy, transactions flow, tickets close. Meanwhile the efficiency saving assumed a team would be redeployed, and the team was never redeployed. The reporting benefit assumed a legacy platform would be switched off, and it is still running, still licensed, still being reconciled against the new one. The cycle-time improvement assumed a process would change around the system, and the process was rebuilt inside the old habits with new screens.

Usage tells you the organisation accepted the tool. It tells you nothing about whether the value arrived, because the value was never a property of the system. It was a property of decisions the organisation promised to make around the system. Those decisions have owners, or they have nothing.

This is why the value gap is a governance problem before it is a change problem. Change management gets people using the system. Governance decides who is accountable for the number the board approved, and what happens when reality diverges from it. After closure, most organisations have the first and not the second.

There is encouragement in that research rather than despair. Programmes in trouble are recoverable. Benefits in trouble are recoverable. But recovery is an act, and acts need actors.

The three things that must survive closure

Strip the discipline of benefits realisation to its load-bearing walls and three things remain. A programme that preserves all three past closure will find its value gap is small. A programme that preserves none of them has already decided the outcome, whatever the closure report says.

Named benefit owners with real authority. Not the programme director, who is leaving. Not “the business”, which is nobody. A named individual for each material benefit, senior enough to redeploy people, decommission systems and change processes, because those are the acts that convert capability into value. If the benefit owner cannot do any of those things, they are not an owner. They are a correspondent.

A baseline that predates go-live. You cannot measure a change you never measured into. If the cost, effort or cycle time of the old world was not captured before cutover, every later claim about improvement is an estimate wearing a suit. The baseline is cheap before go-live and impossible afterwards, which is exactly the order in which programmes deprioritise it.

A forum that can act on a variance. Somewhere the benefits register is read aloud by people with the authority to do something about it. Quarterly is enough. The test is not whether the forum meets. It is what happens when a benefit is off track. A variance noted is not a variance governed. If the answer to “we are behind on this saving” is a slide, the forum is theatre.

Three walls. Owners, baseline, forum. Everything else in the benefits literature is elaboration.

Who commissions the check

Here is the uncomfortable structural fact about the period after go-live: every party with delivery expertise has left, and every party that remains has a reason not to look too hard.

The integrator is gone, and was never accountable for benefits in any case. The vendor’s interest is the renewal, and the renewal argument is served by success stories, not variance analysis. The internal team that delivered the programme has an understandable stake in the narrative of its success. The finance function can see the spend but was rarely close enough to the programme to interrogate the operational assumptions underneath the benefits.

This is the assurance argument, applied one stage later than anyone applies it, and it is sharper after go-live than before it. During delivery, independent assurance competes with the integrator’s own quality processes, the PMO’s reporting and the steering committee’s oversight. After closure it competes with nothing, because nothing else is looking. It is the stage continuous assurance exists for.

An independent post-go-live check is not a large exercise. It asks whether the three walls are standing. Are the benefit owners named, senior enough, and still in the organisation. Does the baseline exist, and would it survive scrutiny. Has the forum met, and has it ever changed anything. It reads the original business case against what is actually being measured, and reports the distance between the two to the people who approved the spend, not to the people who delivered the system.

That last clause is the entire discipline. Assurance commissioned by the party being assured is a review. The value of the exercise is set by who receives the answer.

What good looks like, and how to test your own programme

A programme that has closed the value gap looks unremarkable from the outside. The benefits register is a standing agenda item somewhere real, with names against numbers. The legacy systems the case assumed would die are dead. The people the case assumed would be redeployed are redeployed. When a benefit fails, and some do, the failure is recorded, owned and either recovered or formally released, so the organisation learns what its cases are worth.

If you want to test your own programme, five questions will do it. They take one meeting.

Who owns the largest single benefit in the business case, by name, today. What was the measured baseline for that benefit before go-live. When did a forum with authority last review benefits against the case. What has that forum ever changed as a result. And if the answer to the first question is a job title, a team, or a pause, you have your finding.

Most organisations that run this test discover the same thing. The programme was governed to the last gate and no further, and the case that justified it is drifting, unread, in exactly the gap their own assurance regime would flag anywhere else in the lifecycle.

Go-live was never the finish line.

It was the point where the running stopped being watched.