An AI business case should be argued with, not admired

Most AI business cases are written to be approved. A savings figure on the first page, a payback period, a chart that turns positive in year two. They are persuasive, and the approval meeting rarely asks the questions that matter, because the document was written so that they would not come up.

A business case is far more useful as something to argue with. Its job is not to make the number look right. It is to make visible what the number rests on, so the people approving it can test it and the people running it can tell early when it is going wrong.

Three costs, separately

Build. The one everybody includes. Engineering, integration, data work, and the evaluation that shows the system does what it should.

Run. The one most often understated. Usage costs that grow with volume, monitoring for quality rather than just uptime, the people who check what the system produces, and the work every time the model provider changes something. The running cost of an AI system rises with how much it is used — which is exactly the number the business case hopes will go up.

Change. The time people spend learning a new way of working, the dip in output while they do, and the hours of the managers who carry it. Usually absent, or reduced to a paragraph.

Hours saved are not money saved

The most common value line in an AI business case is time: so many minutes per case, so many cases, therefore so many hours. Hours are not money until somebody decides what happens to them. The same team handles more volume without hiring, or a backlog clears, or a cost actually goes down. If the business case does not say which, the saving will be real and invisible, spread across a team as slightly less pressure.

That is not necessarily a bad outcome. But it is not the one the payback chart promised, and the difference should be settled before approval, not discovered after it. The honest version often names a mix, and says which part of it the sponsor will be held to.

Infographic

A case built for approval, and one built for argument

Built for approval

• –One savings figure on page one
• –Build cost, no running cost
• –Hours counted as money
• –No baseline measurement
• –Success described with an adjective

Built for argument

• →Assumptions written down with their source
• →Build, run and change costed separately
• →A decision on what happens to the hours
• →Measured before anything changes
• →A condition under which we stop

Assumptions, written so they can be attacked

Every business case rests on a handful of assumptions: the volume, the share of cases the system can handle, how long a person needs to check its output, how quickly people adopt it. Write each one down, together with where it came from — a measurement, an estimate, a vendor’s claim.

Then ask which one, if it turned out half as good as assumed, would sink the case. That is the assumption to test first, ideally before anything is built. Often it is the time a person needs to check the system’s work: rarely measured, and decisive for most of the value.

The list earns its keep later as well. When results start drifting from the plan, it tells you at once which assumption to check first, instead of starting the whole argument over.

A baseline and a stop condition

Three things make a business case checkable later.

A baseline measured before anything changes. Actual volumes, cycle times and error rates, captured now. Without it, six months later the comparison is between the new system and people’s memory of the old process, and memory is a poor witness.

A condition under which you stop. What result, at which checkpoint, would make you scale the work down or end it? Written down before the start, it is a decision. Discussed for the first time when results disappoint, it is an argument nobody wins.

A named owner for the numbers. Somebody who will report on those same measures at the checkpoint, and whose own targets depend on them. Without that person, the business case is a document that was true once and is never opened again.

The case against

Finally, the strongest argument for not doing it. Fixing the process might deliver most of the value. Cleaning up the data might be the actual project. The volume might be too low to justify a running cost. If the business case cannot state its best objection and answer it, it has not been tested — only drafted.

Every candidate in an AI strategy engagement comes with exactly this structure: what it takes to build, what it costs to run, what the change involves, the assumptions written down where they can be challenged, a measurable definition of success, and the case against.