I get sent a lot of documents called “business cases” that are actually use case descriptions with a spreadsheet stapled to the back. The spreadsheet usually has a big number at the top labelled “expected annual value” and a smaller number labelled “estimated cost,” and the difference is the return. That is not a business case. That is a wish.
A real business case is a testable argument about how a specific intervention will change a specific business outcome, with enough structure that both champions and sceptics can identify where it might break. The best ones read a bit like scientific papers: hypothesis, method, evidence, risks, and next steps. The worst ones read like sales decks.
This article is about the six components that separate the two, and how each of them should be built so the case survives contact with finance, with reality, and with the messy middle of implementation.
Component one: the value hypothesis
Everything starts here. The value hypothesis is a testable statement of the form: this intervention will change this metric by this much for this reason, and we will know we were right if we see this evidence.
Look at what that sentence requires. A specific intervention (not “AI in customer service” but “an AI assistant that drafts case responses in the payments dispute queue”). A specific metric (not “efficiency” but “average handle time on dispute cases”). A magnitude (not “significantly” but “18 to 25 percent reduction”). A causal mechanism (why should the intervention move the metric?). And an evidence standard (what would convince you the change was real?).
Most business cases fail because they skip the mechanism and the evidence standard. If you cannot explain in plain language why the intervention should move the metric, you probably do not understand the workflow well enough to be investing in it. And if you cannot say in advance what evidence would prove or disprove the hypothesis, you will never be able to say the project succeeded, because success will keep drifting to match whatever happened.
I dig deeper into value hypothesis frameworks in BCR-03. For now, the point is that this component is the foundation, and if it is soft, nothing above it holds.
Component two: the cost model
The second component is a complete accounting of what the intervention will actually cost, over the full period the value hypothesis covers. This is where most business cases hide the most damage.
The visible costs are the model licences, the platform team salaries, and the infrastructure line. The invisible costs are data preparation, evaluation infrastructure, human review workflows, monitoring, incident response, security review, compliance work, change management, and the cost of the workforce time spent adopting the tool. For every dollar of visible cost, I typically see three to five dollars of surround, and BCR-04 breaks this stack down in detail.
The cost model also needs a time dimension. Costs do not distribute evenly. Setup is heavy in the first quarter. Inference costs scale with adoption, so they climb as the tool gains usage. Refresh cycles hit when the underlying model changes, which in 2026 is happening roughly every six months at the frontier. A cost model that shows a flat monthly line is almost always wrong.
Component three: the risk register
Figure 1 shows how the six components fit together. Notice that the risk register sits alongside the value hypothesis and cost model, not underneath them. That is deliberate. Risks are not caveats you disclose at the end. They are inputs that reshape the expected value calculation.
A serious risk register enumerates the specific ways the project could fail to deliver, assigns probabilities and impacts to each, and describes what would trigger a mitigation or an escalation. For AI projects specifically, the risks that keep showing up are: adoption below plan (the single largest driver of business case failure), model performance drift over time, cost overruns from inference scaling faster than expected, regulatory changes affecting the use case, and reputational risk from a visible failure.
The dependency arrows in Figure 1 show why: risks feed back into the value hypothesis and the cost model, adjusting the expected numbers rather than sitting off to the side as caveats. The risk register also needs to include the concentration risks that traditional IT cases often skipped. What happens if your model provider changes pricing? What happens if a competitor releases a materially better model and users start expecting that quality? What happens if a new regulation restricts the deployment? These are not theoretical: Gartner projects that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, largely because of these kinds of external forces.
Component four: the adoption plan
I am putting the adoption plan as a separate component because I have seen too many cases assume adoption happens automatically once the tool is available. It does not. Individual productivity gains are real but they do not translate into enterprise value without a deliberate plan for how the tool becomes part of how the work is done.
The adoption plan needs to answer: which teams and roles will use the tool, in what order? What training and enablement will they receive? How will managers know if their teams are using it effectively? What incentives are in place? What friction is being removed from existing workflows to make room?
The WRITER 2026 survey found that organisations achieving significant ROI shared specific patterns: defined priority use cases, executive owners for each, established KPIs, and benchmarks to track against. The organisations stuck at individual productivity had none of those in place. The tool was available; nobody owned the transition to sustained use.
Adoption also drives the timing of value in the cost model. If your case assumes value starts landing in month three but adoption realistically takes six months to reach the threshold where workflow gains kick in, your NPV is going to be materially wrong.
Component five: the milestones and gates
A business case for a multi-quarter or multi-year AI investment should not commit the full budget upfront. It should specify the stages, the checkpoints, and the criteria for continuing to the next stage. Each gate should have explicit go, hold, and stop conditions.
This is the practical application of real options thinking, which I cover more fully in BCR-08. Rather than treating an AI investment as a single yes/no decision, treat it as a series of smaller decisions, each of which resolves some of the uncertainty in the previous one. The pilot resolves technical feasibility. The controlled rollout resolves adoption. The scaled deployment resolves cost economics.
Structuring the case this way protects the organisation from committing to a five-year runway when the six-month evidence is going to tell you whether to double down or pull back. It also gives finance a defensible reason to underwrite the investment: they are not approving all of it, they are approving the first stage plus the option to continue.
Component six: the governance model
The final component often gets left out entirely, and I think that is a mistake. A business case should specify how the project will be governed as it moves through the stages. Who owns the outcome? Who has decision authority on scope changes? What review cadence is in place? What triggers escalation? How will the value hypothesis be validated once evidence starts coming in?
For AI projects, governance has an extra dimension: model and data oversight. As models refresh and workflows evolve, someone has to be accountable for the fact that the tool in production today may not be the tool the business case underwrote. Without that accountability, drift is inevitable.
What this looks like in practice
Figure 2 shows how these components come together in a document. There is no fixed length; I have seen strong business cases that fit on eight pages and weaker ones that ran to forty. What matters is that all six components are present, that each one is specific enough to be tested, and that the relationships between them are visible.
The template in Figure 2 is not a formatting exercise; it is a discipline. If I had to pick the single test that separates good business cases from bad ones, it is this: can a sceptical outsider read the document and identify the specific claim they would want to see evidence for before approving it? If yes, the case is serious. If no, it is marketing.
The rest of this track will build out each component in more depth. In BCR-03 I get into value hypothesis frameworks in detail. BCR-04 and BCR-05 cover the cost side. BCR-07 gets into the finance-grade financial model that finance will actually accept. BCR-10 and BCR-11 come back to the measurement side. Together they form the toolkit for building cases that survive.
The point of all this is not to make business case writing harder. It is to make it survive contact with reality. Cases built around specific, testable claims can be defended when things go sideways in the middle, because you can look at the evidence and see where the hypothesis held and where it broke. Cases built around aspirational numbers cannot be defended, because there is nothing specific to point at. That is the difference this anatomy is trying to enforce.