The business case gets written for the approval meeting. It gets read properly once, roughly eighteen months later, by someone who wasn’t in that meeting and has no stake in the answer being flattering.

Write it for the second reader. It’s a different document.

Two audiences, opposite requirements

The approval reader wants to know whether this is a good idea. They’re broadly sympathetic, they have twenty minutes, and they’ll accept an assumption if it’s clearly labeled.

The eighteen-month reader wants to know whether the thing that was promised happened. They’re neutral at best, they have your document and a data extract, and they’ll treat every unlabeled assumption as a claim.

Cases written for the first reader tend to fail the second one in a specific way. Not because the numbers were dishonest. Because the numbers were never measurable in the first place, and nobody noticed at the time since nobody was going to check for a year and a half.

The review that finds nothing

Composite from a few operational deployments: a utility, field service scheduling, an optimization and dispatch problem across a workforce of about 600 engineers.

The case promised a twelve percent reduction in truck rolls. That figure is illustrative but the shape is exact: a double-digit percentage against a baseline established in a workshop, by asking three experienced dispatchers what they thought the current rate was.

The deployment went in. By most accounts it worked. Engineers liked it, dispatch preferred it to the old system, adoption was high without anyone being forced.

Eighteen months later, internal audit asked for the measurement. And there wasn’t one, because the baseline had been an estimate, the reporting had changed in the intervening year, and a depot consolidation had happened in month seven which moved the number for entirely unrelated reasons.

The tool may well have delivered twelve percent. It may have delivered twenty. It couldn’t be shown to have delivered anything, and at renewal that is operationally identical to having delivered nothing. The renewal went through, at a worse price, because the buyer had no evidence to argue with.

Three properties of a case that survives

A baseline measured before, from a system, with a date on it.

Not an estimate. Not a workshop consensus. A query, run against a production system, on a stated date, with the query saved. If the system can’t produce the number, that’s a finding, and it’s better as a finding in month one than as a gap in month eighteen.

Run the baseline before the vendors arrive. Once a vendor is in the building, every number becomes contested territory, and the baseline in particular becomes something people have opinions about for reasons connected to the outcome they want.

A stated counterfactual.

What else is changing in this period that could move the same number. Reorganizations, headcount changes, policy shifts, seasonality, that consolidation in month seven. List them in the case, in advance, as known confounders.

This looks like weakening your own argument. It’s the opposite. A case that names its confounders up front is enormously more credible at review than one that discovers them defensively afterward, and it protects you from the reverse problem too: the deployment that worked and got no credit because something else moved the number the wrong way.

A benefit owner who takes the number into their budget.

This is the test that decides everything, and it’s the one people avoid.

If the saving is real, some budget line goes down. Find the person who owns that line and ask them to accept the reduction. Not to agree the saving is plausible. To accept it into next year’s plan.

What usually happens is instructive. They’ll say the saving is real but won’t come out of headcount because the team is already stretched. They’ll say it frees capacity rather than reducing cost. They’ll say the number moves in a different line that belongs to someone else.

All of those may be true. None of them are cash. A benefit nobody will take out of their budget is a capacity benefit, and capacity benefits are legitimate but they are a different category and they belong below the line.

Structuring it honestly

The structural dishonesty in most cases isn’t in any individual number. It’s that costs and benefits get presented as symmetric when they aren’t.

Costs are near, certain, and mostly contractual. Benefits are distant, uncertain, and depend on human behavior you don’t control.

Present them that way:

• Costs: license, integration, internal effort in days, change and training, and the run cost in year two and three. Include internal effort at a loaded rate even though nobody will invoice you for it, because it’s the largest cost in a surprising number of cases.
• Cash benefits: measured baseline, target, owner named, appearing in that owner’s budget.
• Capacity benefits: quantified, below the line, explicitly not summed into the total.
• Risk and quality benefits: described, not monetized. A monetized compliance benefit is a number somebody invented, and the eighteen-month reader will find it.

Do not sum across those categories. A total that adds cash to capacity to a notional value of reduced risk is the single fastest way to lose a reviewer, and once they stop believing the total they stop believing the parts.

The section nobody writes

Add a short paragraph titled how we will know. Three sentences: the query we’ll run, who runs it, and on what date.

It costs you five minutes at writing time. It’s the entire difference between a review that confirms your judgment and a review that finds an absence.

I have written cases without it, more than once, and been unable to defend perfectly good work.

One thing to do differently

Take your largest claimed benefit to the person who owns that budget line and ask them to accept it into their plan for next year.

Whatever they say, you’ve learned the most important thing about your case before anyone approves it. If they’ll take it, you have a benefit. If they won’t, you have a capacity gain, it belongs below the line, and your total needs to come down before someone else brings it down for you.