MODULE 4 · LESSON 3
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolWriting and Defending the Case
The one page
Everything a decision-maker needs, in a fixed order:
1. The decision requested. What you want, in one sentence, with the amount. "Approve £48,000 over nine months to automate invoice data extraction."
2. The problem today. Who does what, how often, how long it takes, what goes wrong. Numbers from systems.
3. The proposal. What the system does — the gate-1 sentence — and explicitly what it does not do.
4. The benefit. The chain from lesson 1, showing volume, coverage, adoption and unit value, and naming which of the three routes converts time to money.
5. The cost. Three buckets across three years, with the exception path explicit.
6. What has to be true. The assumptions, listed. This is where the case earns trust.
7. The risks and what happens when it is wrong. The error rate you expect, who catches it, what it costs.
8. The stop condition. From module 3.
9. What this leaves behind. The plumbing, data or capability the next project inherits.
Sections 6, 8 and 9 are the ones that distinguish a case written by someone who has done this from one written by someone who has read about it.
The six challenges
Prepare answers before the meeting; every one of these will come.
"How is this different from the last thing that did not work?" Frequently the first question and rarely anticipated. Answer specifically: name the previous failure, name what was missing, show that it is present now.
"What if the accuracy is worse in practice?" Point to the hundred-case sample, and to the exception path that catches the difference. Your case should not depend on optimistic accuracy — if it does, fix the case.
"Aren't we just moving work rather than removing it?" Sometimes yes. The exception-path arithmetic from lesson 2 is your answer: gross saving, exception cost, net. Having done that subtraction yourself is disarming.
"What happens when the vendor raises prices or is acquired?" Module 5 covers this properly. Have the exit position ready.
"Who owns this in two years?" Name a person and a budget line, or accept that the answer is nobody.
"Why not wait — this is all moving so fast?" The strongest challenge, and it deserves a real answer rather than urgency. Usually: the capability being built is durable even if the components change; waiting has its own cost in learning not accumulated; and the project is sized so being overtaken is survivable.
Ranges, not point estimates
A single number invites a single objection. A range with a stated basis invites a conversation.
"Benefit of 2,100 to 3,200 hours annually. The lower bound assumes 65% adoption, consistent with what we saw on the CRM rollout; the upper assumes 90%, which we have not achieved on any previous internal tool."
That formulation does something a point estimate cannot. It demonstrates that you know what drives the variance, it grounds both bounds in your organisation's own history, and it makes the ensuing discussion about the right thing — adoption — rather than about whether you are being optimistic.
Write it so it can be checked
The best discipline in this entire module: write the case so that in twelve months somebody can determine whether it was right.
That means every claim has a measurable form and a date attached. "Adoption of 85% by month six, measured as the proportion of eligible invoices processed through the system." Not "significant efficiency improvements".
The reason is not accountability theatre. It is that an organisation only gets better at AI investment if it can compare predictions with outcomes — and almost none do, because the original cases were written in language that cannot be checked. If your first three cases are checkable, your fourth will be substantially better than anyone else's.
Two managers in the same company, three weeks apart, both proposing document extraction.
The first. Twelve slides. Market context on AI adoption, three competitor examples, a vendor architecture diagram, and a benefit of "up to 60% reduction in processing effort" — a figure from the vendor's website. Cost was the licence quote. Risks were "change management" and "data quality", unelaborated.
It was rejected in eleven minutes. The finance director asked what "up to 60%" meant, and there was no model behind it. Then she asked what happened to the documents the system could not read, and there was no answer. The project never returned.
The second. One page, plus an appendix nobody needed to read.
The manager had hand-sorted a hundred documents: 81 straightforward, 13 awkward, 6 hard. Benefit was modelled at 81% coverage and 80% adoption, giving a range on stated assumptions. The exception path was costed at 19% of volume at roughly double the handling time, and subtracted. The route from time to money was named as absorbed growth — volume was forecast to rise 15% and the case was that no additional hire would be needed — and the operations director had agreed to that in advance. Cost ran three years including an estimated annual change figure, labelled as an estimate. The stop condition was accuracy below 75% on straightforward cases at week ten. What it left behind was a document-processing pipeline two other candidates were waiting on.
It was approved in nine minutes, and most of that was discussing whether the growth forecast was right — which was the correct thing to be discussing.
The difference was not effort or seniority. The second manager had already asked themselves every question the room was going to ask, and had done the subtraction that made the number smaller. A case that has survived its own scrutiny is very hard to dismantle, and one that has not is dismantled by the first person who tries.
Why should a business case present a benefit range with a stated basis rather than a single number?
The nine-section one page
Click to flipDecision requested, problem today, proposal, benefit, cost, what has to be true, risks and error handling, stop condition, and what this leaves behind.
Click to flip backPut the case on one page in a fixed order, and make sure it contains the three sections that mark experience: what has to be true, the stop condition, and what the project leaves behind. Prepare for the six challenges that always come, especially "why not wait". Present ranges tied to your own organisation's history rather than point estimates, and write every claim so that in a year somebody can check whether it was true.