Two posts in. step 0.5 is done, including a notebook full of stakeholder conversations, complete with contradictions, half-thoughts, and a few people I'm not entirely sure I made coherent. Time to write the business case.
Ask ten BAs what a business case is and you'll get ten variations on "a document that describes the project." Kinda vague and oversimplified in my books.
The Permission Slip
I like to think of a business case as a sales pitch. Someone with a budget has to read it and decide whether to fund the work, and every word in the document should help them say yes. The audience is the person you're asking to spend money. Once you internalize that, everything about how to write it changes. The business case is closer to a sales letter than to a spec sheet.
Most BAs write business cases like project plans. They describe what they're going to do: the scope, the team, the timeline. They assume the reader will see the value. The reader doesn't. They're busy, skimming, and weighing this project against five others on their desk. If the document doesn't make the value obvious in the first paragraph, they move on.
I've written many business cases like project plans. I assumed that if I laid out everything, the exact value proposition would jump out.. news flash, it doesn't. I came to realize I was the only one with the full picture, and with the pic, it's easy to assume everyone sees it the way you do.... NOBODY DOES!
The business case is for the person paying for it.
Who's Actually Reading This
The reader is someone with the authority to say yes. A director, a VP, a CFO, an executive sponsor with budget. They're an executive. Busy, often not technical, and maybe don't know what FNOL means.. A big maybe!
What they want to know, in order: what's the problem, how big is it, what does it cost us today, what would the solution cost, what's the payback. Five things.
Answer those five clearly in the first page, and you've already won half the room.
The mistake is starting with the solution. "We're going to build an AI triage system." That's not it. The right opening line is the problem itself. "Five hundred FNOL calls a day, three to five minutes each, and Definity has shown it can be cut by forty percent." Now the reader knows why they should care. The solution becomes the answer to a question they're already asking themselves.
The Shape of It
The order is roughly:
- The problem, stated in numbers if you can. Five hundred calls a day, three to five minutes each, the agent burnout and the misclassifications that follow. Make it concrete.
- What it costs today. Time, money, customer goodwill, whatever you can quantify. This is what the company is losing right now by not acting.
- The proposed solution, in plain language. Skip the architecture diagrams and the tech stack. Just describe what you'd build and how it solves the problem.
- The cost and timeline, with the math behind them. Be honest about uncertainty.
- The risks, including the risk of doing nothing. Most BAs leave this last one out. It's the most powerful part of the case.
Many BAs skip the risk-of-inaction section because it feels uncomfortable to write. You're essentially saying "and if we don't do this, here's what'll happen." But that's exactly why executives respect it. It tells them you've thought about the downside, and it's the line that turns a maybe into a yes.
That's the shape. Problem, cost, solution, cost-to-fix, risk.
If This Were a Real Project
Here's the part I have to be honest about. In a real project, you don't write the business case in one sitting and ship it. You write a draft, share it with two or three people who'll tell you it's wrong, listen to what they say, and rewrite. Then you do it again. Most business cases that get approved went through four or five drafts before they were submitted.
And the truth is, the rewriting is the actual work. Each draft sharpens the argument. By the time you submit, you've already had the executive's objections in your head and answered most of them.
I can't fully simulate that in a blog series. When you see the business case I publish next, it'll be tidier than a real one would be. In an actual project, the first draft would be ugly. The numbers would be wrong. The problem statement would be too vague. I'd take it to a director, get told the cost number was off by a factor of three, and come back with a sharper version. That's how it actually works.
The next post is about exactly that first draft. The problem statement, and why the first version is always wrong.
Sayonara.
The business case stands or falls on its problem statement. Post four is about writing that first ugly draft, getting it torn apart, and what comes out the other side.
