Most transformation business cases are written to secure approval rather than to inform a decision, and everybody involved knows it. The benefits are optimistic, the costs are partial, and the payback period lands conveniently inside the sponsor's tenure. The case then gets approved, and eighteen months later nobody can say whether it worked, because the baseline was never taken.

This is a method for doing it the other way round: building a case honest enough to be wrong in a useful direction, before a supplier has been chosen and before anyone is committed to a particular answer.

Key Takeaways

  • Only three benefit types survive scrutiny: cost removed, revenue enabled, and risk avoided. Everything else is a proxy for one of them.
  • Count your own organisation's time as a cost — it is frequently the largest omitted line.
  • Model a range rather than a point, and state the assumptions that would have to hold for the low case to be wrong.
  • Take the baseline before commissioning. A case with no baseline cannot be evaluated afterwards and will be judged on impressions.
  • If the case only works on the optimistic scenario, it is a decision about appetite, not about return — say so.

The Three Benefits That Survive Scrutiny

Cost removed. Work that no longer needs doing, licences no longer needed, infrastructure retired, error correction avoided. This is the most reliable category because it can be counted, and it is the one most often understated — teams count the headcount saving and omit the error correction, the rework, and the management time spent on exceptions.

The discipline is to be specific about what happens to the removed cost. Roles redeployed rather than removed are a capacity benefit, not a cost benefit, and calling them the latter is the single fastest way to lose the finance director's confidence.

Revenue enabled. Faster quote turnaround converting more business, a channel that now works, a product that can now be launched, retention improved by a better experience. Real, and harder to attribute, because revenue moves for many reasons at once.

The test is whether you can name the mechanism precisely. "Better customer experience increases revenue" is not a mechanism. "Reducing quote turnaround from five days to one recovers a share of the quotes that currently lapse before response" is, and it can be sized against the actual number of lapsed quotes.

Risk avoided. Regulatory exposure, outage cost, security incidents, key-person dependency on an unsupported platform. Legitimate and the hardest to quantify, so it tends to be either omitted or inflated.

The usable approach is expected value with the assumptions written down: the plausible frequency, the plausible cost, and the change the programme makes to either. A number derived that way can be argued with, which is the point.

Everything else — engagement, agility, culture, readiness — is a proxy for one of the three or it is not a benefit. That is not a dismissal; it is a requirement to say which of the three it eventually becomes and how you would know.

Infographic listing the three defensible benefit categories against the full cost lines including internal time, transition running costs, and the ongoing cost of the new arrangement

The Costs That Get Left Out

Your own people's time. Discovery, workshops, decisions, testing, training, and the ordinary friction of two organisations working on one estate. On a complex programme this can approach the external fee, and it is omitted from most cases entirely.

Transition running costs. Old and new run in parallel for a period that is always longer than planned. Both are paid for throughout.

The cost of the new arrangement. New platforms have licences, hosting, and support. A case comparing the old cost against zero forward cost is not a case.

Change and adoption. Training, documentation, the productivity dip while people learn, and the effort of getting a process actually used rather than merely available. Under-funding this is the most common cause of a technically successful programme delivering no benefit.

Opportunity cost. The programme consumes senior attention and delivery capacity that could have gone elsewhere. Not always worth quantifying, always worth stating.

Build a Range, Not a Number

A single figure invites a debate about whether it is right. A range invites a more useful debate about what would have to be true.

Model three scenarios. The low case assumes benefits arrive late and partially, costs run over, and adoption is slower than planned. The expected case is your honest estimate. The high case is what happens if it goes well.

Then apply the test that matters: does the low case still justify proceeding? If yes, the decision is straightforward. If only the expected case justifies it, the programme needs risk mitigation designed in before approval. If only the high case does, you are making a decision about appetite and strategic positioning, not about return — which is a legitimate decision, but it should be labelled correctly rather than dressed as a financial one.

Timing matters as much as magnitude. Benefits that arrive in year three are worth materially less than the same benefits in year one, and transformation benefits nearly always arrive later than planned because adoption lags delivery. Model the phasing, not just the total. Our framework for sequencing transformation work covers how the increment order affects that phasing.

Take the Baseline Before You Commission

This is the step that gets skipped and the one that determines whether the case can ever be evaluated.

Before any supplier starts, measure the things the case claims will change. Cycle times, error rates, cost per transaction, conversion, the hours spent on the work being automated. Measure them properly — sampled or instrumented, not estimated in a workshop — and write down the method so the same measurement can be repeated.

Two reasons this matters beyond evaluation. First, baselining routinely disproves part of the case before any money is spent, which is cheap learning. Teams frequently discover the process they were about to automate is faster than they believed, or that the error rate is concentrated in one product rather than spread across all of them — either finding changes the scope.

Second, a baseline gives the programme a defensible story later. Without one, benefit is asserted, and assertions lose to whoever presents most confidently.

Testing a Supplier's Business Case

Suppliers will offer to help build the case. That is useful and it is not neutral, so apply four tests.

Are the benchmarks from comparable organisations? Industry averages drawn from larger, differently structured firms are not evidence about you.

Does the case include your internal costs? Supplier cases usually model the supplier fee and omit your side entirely, which understates total cost substantially.

What happens in the low case? A supplier unwilling to model a pessimistic scenario is selling rather than advising.

What has to be true for this to work? The assumption list is the most valuable part of any business case and the part most often absent. If a supplier cannot produce one, the case has not been thought through.

None of this is an argument against supplier input. A partner who has done the work elsewhere has better priors than you do about what these programmes cost. It is an argument for testing the case rather than adopting it — the same diligence set out in our red flags and green lights for partner selection.

Reviewing It Afterwards

Set the review dates at approval, not later. Twelve months and twenty-four months, against the baseline, with the original assumptions revisited explicitly.

The valuable output of that review is not the verdict. It is the list of assumptions that turned out to be wrong, because that list makes the next business case better. Organisations that do this build genuine institutional skill at forecasting these programmes; those that do not repeat the same estimation errors indefinitely, which is why so many enterprises are on their third transformation programme with the same optimism as the first.

Conclusion

A usable business case has three defensible benefit categories, a complete cost picture including your own time, a modelled range rather than a point, and a baseline taken before anything starts. Most cases fail on the last two.

Ask whether the low case justifies proceeding. If only the optimistic scenario does, that is worth knowing and worth saying plainly — the decision may still be right, but it is a strategic one rather than a financial one. Set the review dates at approval and revisit the assumptions, not just the numbers. Talk to IdeaGCS if you want a case tested before it goes to the board.