There is a document that exists in almost every organization and is read by almost nobody after the week it was approved: the business case for a large system implementation. It is usually excellent. It identifies a problem, quantifies the cost of not acting, projects savings over five years, and produces a return on investment figure comfortably above the hurdle rate. It is reviewed by finance, approved by a steering committee, and filed. Then the project runs for two years, goes live, and nobody ever compares what happened to what the document said would happen. Coming out of the 2008–09 downturn, this became conspicuous. Capital was scarce, every project competed against every other project, and boards began asking a question they had not asked before: what did we get from the last one? The answers were frequently unavailable.
How Business Cases Get Inflated
Overstatement is rarely dishonest. It is structural, and the structure is worth understanding because it is reproducible in any organization. The business case is a funding instrument, not a forecast. Its purpose is to secure approval. Everyone involved knows the number needs to clear a threshold, and estimates are assembled with that outcome in view. This is not fraud; it is the predictable behaviour of people who need a yes. Vendor benefit models arrive pre-inflated. Software vendors and implementation partners supply benefit benchmarks drawn from their best references. Those references are real, and they are also selected. Using them as the planning assumption imports someone else's best case as your base case. Savings are counted that will never be realised. The most common inflation is efficiency converted to money. A process that takes 20% less time saves 20% of a salary line only if headcount actually reduces or the freed capacity is redeployed to something of value. Neither usually happens, and neither is usually planned for. Benefits are attributed to the system that were going to happen anyway. Revenue growth, margin improvement and error reduction arising from market conditions, process redesign or a management change get credited to the implementation because it was the visible event. One-time costs are systematically understated. Internal staff time is treated as free because those people are already on payroll. Change management, data cleansing, parallel running, backfill for seconded staff and the productivity dip after go-live are the costs that consume contingency, and they are the ones least likely to appear in the model. Ongoing costs disappear into the future. Subscription escalation, additional modules, integration maintenance, upgrade effort and the permanent internal team required to run the platform. A five-year model that treats year one support pricing as constant is understating the denominator.
Why Nobody Checks
The absence of benefits realisation review has causes as structural as the inflation itself. The sponsor who approved the case has usually moved on, been promoted, or has no interest in a review that can only embarrass them. The baseline was never measured precisely enough to compare against — if you did not record the pre-project cost per invoice, you cannot demonstrate improvement. The organization changed around the project, giving everyone a legitimate reason to say the comparison is not meaningful. And admitting shortfall calls the next business case into question, which nobody in the approval chain wants. So the review does not happen, and the absence of review is precisely what allows the next case to be equally optimistic. The feedback loop that would correct estimation is missing by design.
Building a Case That Survives Contact
- Measure the baseline before you start, in operational units. Cost per invoice, days to close, order-to-cash cycle time, error rate, hours per reconciliation. Money figures can be argued about; operational measures are harder to dispute and easier to compare.
- Separate hard from soft benefits explicitly. Hard benefits change a line in the budget — a licence retired, a contract cancelled, a position not backfilled. Soft benefits are real but do not produce cash. Present both, and justify the investment on the hard ones.
- Name an owner for every benefit. Each line in the model should belong to a named executive who accepts it into their budget or their operational targets. Unowned benefits are, without exception, unrealised benefits.
- State when each benefit lands. Benefits that appear in year one are different in value and credibility from benefits appearing in year four. Most implementations deliver a productivity dip for the first two quarters, and a model that ignores this is already wrong.
- Build your own benefit model. Use vendor benchmarks as a sanity check, not as an input. Your processes, data quality and adoption capacity are what determine the outcome.
- Include internal cost at a real rate. Staff time is not free. Pricing it properly changes the answer on marginal projects, which is exactly what it should do.
- Run a documented downside case. What the return looks like if the timeline extends by 50% and benefits arrive at 60% of plan. If the project is still worth doing, you have a robust decision; if it is not, you have learned something valuable cheaply.
- Schedule the review at approval, not afterwards. Fix the date — twelve months after go-live — in the approval document itself, with the measures specified. A review agreed at the start is one that actually happens.
Record a baseline
Use operational measures before starting
Classify each benefit
Separate cash changes from released capacity
Name an owner
State who accepts the benefit and when
Cost the work
Include internal effort and ongoing operations
Compare after delivery
Review outcomes against the original assumptions
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What Honest Review Produces
Organizations that institute genuine benefits realisation consistently report the same experience. The first review is uncomfortable. The second is more accurate. By the third cycle, business cases across the organization have become noticeably more realistic, because the people writing them know a comparison is coming. The value is not in catching anyone out. It is in restoring a feedback loop. Estimation is a skill that improves only with calibration, and an organization that never compares forecast to outcome is systematically incapable of improving its forecasts. There is also a portfolio effect. Once a few projects have been honestly reviewed, leadership develops a sense of which types of initiative genuinely deliver in their environment and which reliably disappoint. That judgement is worth considerably more than any individual review.
The Current Version of the Same Problem
AI business cases in 2026 read exactly like ERP business cases in 2010, including the specific failure modes. Hours saved per employee, multiplied across headcount, converted to salary cost, presented as annual savings. The same conversion error: saved minutes distributed across many people do not aggregate into a budget reduction unless something structural changes. Vendor-supplied productivity benchmarks drawn from best-case deployments. Implementation cost limited to licences, with nothing for data preparation, integration, governance, evaluation or the ongoing work of keeping the thing accurate. And the same missing discipline. Very few organizations have measured a baseline they could compare against in a year, which means that when the review question arrives — and after this much investment, it will — the answer will again be unavailable. The remedy has not changed in fifteen years. Measure before, name the owner, book the review date in the approval, and count only the benefits that change a number someone is accountable for.
Common Questions
Why are IT business cases usually overstated?
Because they function as funding instruments rather than forecasts. Estimates are assembled to clear an approval threshold, vendor benchmarks import best-case outcomes, efficiency gains are converted to cash savings that never materialise, and internal effort is treated as free.
What is the difference between hard and soft benefits?
Hard benefits change a budget line — a retired licence, a cancelled contract, a position not backfilled. Soft benefits, such as improved decision quality or employee experience, are real but do not produce cash. Investment decisions should rest on the hard benefits.
Why do organizations rarely review whether benefits were achieved?
The original sponsor has usually moved on, the baseline was never measured precisely, the organization has changed enough to make comparison contestable, and demonstrating shortfall undermines the next business case.
How do you make benefits realisation actually happen?
Fix the review date and the specific measures in the approval document itself, assign every projected benefit to a named executive who accepts it into their targets, and record an operational baseline before the project begins.
Benefits Realization Review — Outpace measures what your systems were supposed to deliver against what they actually did, and builds business cases with numbers that survive the review twelve months later.