Why most technology business cases collapse after go-live
The business case got approved. The project was delivered on time and broadly to scope. And then, quietly, nothing changed.
This is the pattern I see repeatedly across enterprise technology programmes. A well-argued business case secures the investment. The technology gets built and deployed. And then the benefits that justified the entire programme simply do not materialise at the scale or speed that the case predicted.
The failure is almost never in the technology itself. It is in the assumption that deployment equals adoption, and that adoption automatically produces the outcomes the business case modelled.
Three patterns that collapse business cases after go-live
Benefits ownership disappears at go-live. During delivery there is a programme manager, a project board, and regular governance. At go-live, the project closes and responsibility for realising the benefits transfers to nobody in particular. The operational teams who inherit the system were not part of the original business case conversation. The projected savings are not in anyone’s performance targets. Nobody is accountable for whether the benefit actually materialises.
Adoption is assumed, not managed. Business cases routinely assume 80 to 90% adoption within a few months of go-live. In practice, adoption in an established organisation is a change management problem, not a technology problem. If you have not invested in training, communication, and process redesign at the same scale as the technology, the adoption curve will disappoint the model.
The baseline shifts before you can measure. Organisations do not stand still while you deliver technology. Headcount changes. Processes evolve. Market conditions shift. By the time you attempt to measure the benefit against the original baseline, the baseline no longer exists in a comparable form. This makes it easy to claim success, and equally easy to bury failure.
What changes the outcome
Appoint a benefits owner before go-live: someone whose role explicitly includes tracking and reporting on benefit realisation for at least twelve months after deployment. Give them a measurement plan with defined metrics, not just a benefits register.
Build benefits tracking into your operational dashboards from day one. The metrics that prove ROI should be visible to the people who can actually influence them, not locked in a programme spreadsheet that nobody opens after the project board disbands.
Model adoption explicitly in the business case. If you are assuming 80% adoption in month three, show your workings. What change management activity supports that assumption? Who owns it? What happens to the ROI if adoption reaches only 40%?
The technology is rarely the reason business cases collapse after go-live. The reason is that we treat go-live as the end of the investment story, when it is actually the beginning of it.