Here is a programme that did everything right. It hit its date. It came in on budget. It cut over with no critical defects and a war room that stood down after 48 quiet hours. Champagne, retrospective, team disbands. Eighteen months later the finance close is no faster than before, half the promised process changes have been worked around, and the business case that justified the whole thing has quietly been filed under "strategic." Nothing failed. And yet it failed.
This is the adoption gap, and it is the least discussed failure mode in enterprise systems precisely because it doesn't look like failure. There is no outage to point at, no missed deadline, no red line in a status report. There is only the slow divergence between the way the system was designed to be used and the way people actually use it — a gap that opens after the spotlight has moved on.
Why go-live is the wrong finish line
Go-live measures whether the system works. The business case promised something quite different: that the organisation would work differently, and that working differently would produce a measurable result. Those are not the same achievement, and they don't happen at the same time. Cutover is an engineering event; adoption is a human one, and human change is slow, reversible, and prone to relapse under stress. The moment the new system does something unfamiliar during a busy period, people reach for the workaround they trust — and every workaround is a small withdrawal from the value the business case banked on.
Cutover proves the system works. It says nothing about whether the organisation now works differently — which was the whole point.
Value leaks quietly, and no one is watching
The cruel timing is that value is decided in the twelve to eighteen months after go-live, which is exactly when the people who understood the design have rolled off, the programme budget has closed, and no one owns the number any more. The gauges that would show the leak — is the close actually faster, are invoices actually touchless, did the manual reconciliations actually stop — are rarely instrumented, so the drift is invisible until someone asks, years later, what the investment bought. By then the answer is unrecoverable, because there is no baseline left to compare against.
What sustaining value actually takes
Treating go-live as a milestone rather than an outcome changes what you build. It means defining, before launch, the two or three measures that prove the new way of working held — and instrumenting them so they keep reporting after the team is gone. It means someone owning those measures into steady state, with the authority to intervene when they drift. And it means treating a workaround not as a user quirk but as a signal: a place where the design and the work diverged, and value is escaping. Adoption is not a training deliverable you tick off in week one. It is a condition you monitor, defend, and keep re-earning.
The uncomfortable ownership question
All of this runs into the same wall as everything else in this series: the party best placed to declare go-live a success is the delivery team, and their mandate ends at the very moment the outcome starts being decided. Someone independent of the launch has to keep watching the gauge — because the people who built it have every reason to call it done, and none to keep checking whether it stayed done.
Where we sit. Roltrader's Sustain layer exists for exactly this window — keeping the value measures instrumented and owned after the SI leaves, and turning the drift back into action. But the discipline is available to anyone: name the outcome measures before go-live, instrument them, and give them an owner who is still there a year later. The milestone is easy to celebrate. The outcome is the only thing that was ever worth buying.