The Business Case That Got Approved in Eleven Minutes

The finance director opened the pack, read the first page, turned to the sponsor and said "I've got no questions, have you?" It was 9:11 on a Wednesday. We'd booked ninety minutes. We used eleven of them, and eight of those were people arriving.

I'd presented a version of the same request four months earlier and it died in the room. Same team, same problem, roughly the same money. Here's what changed.

The first version opened with architecture. Of course it did. A diagram, the current pipeline, the proposed pipeline, some sensible words about maintainability and developer experience. I was proud of that page.

The second version opened with this, and nothing else:

Releases take us 9 days from merge to production. Our two closest competitors ship the same day. We're asking for £380,000 and about five months to get to same day. If we do nothing, the number gets worse, because the workaround scripts holding it together are maintained by two people and one of them is on the platform rota we're trying to reduce.

Four lines. A problem stated in the language of the business, a number, a timescale, and what happens if the answer is no.

The finance director doesn't care about your pipeline. He isn't being philistine about it, he simply has eleven of these packs this month and he's looking for the same thing in all of them: what's the problem, what does the fix cost, what happens if we don't. If he has to read to page six to find that out, he'll form his opinion on page one anyway, and you've let him form it from a diagram.

Write the four lines before you write anything else. If you can't, you don't have a business case yet. You have a preference, and preferences don't get funded.

The first version had a single number: £412,000. Precise, spreadsheet-derived, and wrong in a way everyone in the room could smell. Precision without confidence reads as a guess wearing a suit, and the moment anyone pokes it and it moves, your whole pack loses credibility.

The second version said £340,000 to £420,000, and then it did the thing that actually mattered. It said what sat between the two ends.

The low end assumed the two contractors we needed were available in September. The high end assumed we'd have to run a recruitment cycle and start in November, which meant a longer overlap with the existing platform work. One assumption, named, with a date attached, and the range moved for a reason a non-technical person could follow in one sentence.

Something interesting happens when you do that. The conversation stops being about whether your number is right and starts being about whether the assumption is right, which is a far better conversation to have and one you'll usually win, because you know the assumption better than anyone in the room. The finance director actually offered to help with the contractor route. He couldn't have offered that against a single number, because a single number invites a yes or a no and nothing else.

Estimate honestly, including the bit where you don't know. "We don't have a firm figure for the data migration yet, Priya has it by the 29th, our working assumption is £40,000" beats a confident fabrication every time, and it beats silence by even more.

This is the part that felt like self-sabotage and turned out to be the reason it passed.

The pack had three options. Rebuild the pipeline, which is what we wanted. Buy a hosted product, which was cheaper up front and which we'd genuinely considered and rejected. And do nothing, costed properly rather than treated as free.

For the hosted option we didn't build a straw man. We wrote the real case for it, including the fact that it would have got us to two-day releases within eight weeks, which was faster than our preferred option. Then we explained why we still didn't recommend it: the compliance team needed build artefacts retained in our own environment, and the product couldn't do that without a tier we'd have had to negotiate separately.

Doing nothing got its own costing. Two engineers spending roughly a day a week each maintaining the workarounds, the release window overtime, and the retention risk of the person who'd become the single point of knowledge.

Here's what that buys you. When the finance director reads a pack with one option in it, his job is to find the hole. When he reads a pack with three honestly argued options and a clear recommendation, his job becomes agreeing with your reasoning or not. You've handed him a decision instead of an audition, and you've demonstrated something no amount of enthusiasm can: that you looked at this like someone spending the company's money rather than someone who wants a new toy.

A business case is only as strong as its honesty about the alternatives. The pitch for your favourite option is the easy half and everyone can tell it's coming.

The architecture pack didn't disappear. It went to the technical review board, where it belonged, and where the questions were about blast radius and rollback and who carries the pager during the cutover. Good questions. Not the finance director's questions.

What I stopped doing was merging the two. A single pack that tries to satisfy a principal engineer and a commercial director satisfies neither, and it's usually the technical detail that wins the page count, because that's the part you enjoy writing.

Same facts in both. Different first page, different order, different depth. If the two versions ever contradict each other you've got a real problem, and you should find out about it in your own review rather than in a meeting where both people are present.

For completeness, because the failure taught me more than the win. The four-months-earlier pack had a slide titled "Technical Debt in the Release Process" and a paragraph containing the phrase "improved developer experience". No cost of inaction. One option. A single precise number.

The sponsor's actual feedback, later, over a coffee: "I believed you that it was a problem. I couldn't tell my boss why it was a problem this year rather than next year."

That sentence is the whole thing. Nobody was doubting my competence. They were doubting the urgency, and urgency is something you have to evidence rather than convey through tone of voice.

You almost certainly have a case sitting in a folder somewhere, half written. Open it and delete the first slide. Replace it with the four lines: the problem in business language, the cost, the timescale, and what happens if the answer is no.

Then send just that page, with nothing attached, to the least technical person whose judgement you trust, and ask them one question. "Would you fund this, and what would you want to know first?" Their first question is the one you're going to get in the room. Answer it before you go in.