Every large ERP programme is justified by a business case, and almost every business case has a quiet flaw baked in from the first draft: it was written to get the money released, not to be measured after the money is spent. Those are genuinely different documents. One needs to be persuasive; the other needs to be falsifiable. When the persuasive version is the only version that ever gets written, the programme sets off with a number it can never be held to — and a benefits case that quietly converts into strategic narrative the moment anyone tries to check it.
The tell is the language. "Improved efficiency." "Better decision-making." "A platform for growth." These phrases pass a funding committee precisely because they cannot fail — and they cannot fail because they cannot be tested. A benefit you cannot test is not a benefit. It is a hope with a spreadsheet attached.
Approvable is not the same as measurable
A number designed to be approved optimises for size and confidence: it wants to look big enough to justify the spend and certain enough to survive scrutiny. A number designed to be measured optimises for something else entirely — traceability. It needs a named metric, a current baseline, a target, a date, and an owner who will answer for the gap. Most business cases carry the first kind of number and none of the second, which is why the benefits case so often can't be reopened at the end: there was never anything concrete enough to reopen.
A benefit you cannot describe precisely enough to measure is not a benefit. It is a hope with a spreadsheet attached.
The four things every claimed benefit needs
Before a benefit belongs in a business case, it should survive four questions — and if it can't, it belongs in the narrative, not the numbers.
Test every benefit against these
- What exactly will change? Named metric, not a direction of travel
- What is it today? A baseline measured now, while the old system still exists
- By when, and how much? A target and a date you can pass or fail against
- Who owns it? A person accountable for the number after go-live
Baseline it while you still can
The second question hides the sharpest trap. A benefit is a comparison — the new state against the old — and the old state can only be measured while the old system is still running. Programmes routinely defer baselining until after go-live, at which point the legacy system is being decommissioned, the reports that would have captured the starting point are gone, and the comparison becomes impossible. The window to establish what "before" actually was closes at cutover, and it does not reopen. If you have not measured the baseline before you migrate, you have not deferred the measurement — you have lost it.
Fewer, harder numbers
The instinct under funding pressure is to pile on benefits until the total looks irresistible. The discipline is the opposite: name the two or three benefits that genuinely justify the investment, describe each one precisely enough that it could embarrass you if it doesn't land, baseline them, and let the softer benefits live honestly in the narrative where they belong. A business case with three measurable claims you can be held to is worth more than one with thirty you can't — because only the first kind can ever be proven true.
Where we sit. Roltrader's PRAIS layer builds the pre-decision case from your own data, and our assurance layer captures the baseline while the legacy system still exists — so the value can actually be proven, not just promised. But the rigour is yours to apply: name the metric, measure the baseline now, set a date, assign an owner. Describe the value precisely at the start, or forfeit the right to claim it at the end.