Business Case: How to Write One in 5 Parts (Full One-Page Example)
"We need our own mobile app." Should anyone say yes to that? In this video I take one request from a made-up online shop and write a full business case for it: the 5 parts (need, options, costs and benefits, risks, recommendation), 5 steps to write one, simple payback with no scary finance, a stress test, and a finished one-page example you can copy. Plus the 5 mistakes that sink a business case.
Step by step
A business case is a decision tool
- A business case is not paperwork for something the boss already picked. The BABOK Guide from the IIBA says it justifies a course of action by comparing the benefits with the cost and effort to get the solution and live with it. The example here is a made-up online shop.
Explain like I'm 5: the puppy pitch
- Think of a kid asking for a puppy. "Everyone has one" gets a no. A good pitch states the need (lonely after school), the options (puppy, goldfish, walk the neighbour's dog), the costs and benefits, the risk (getting bored) and a recommendation: walk the neighbour's dog for 1 month first.
What the BABOK Guide puts in a business case
- In the BABOK Guide, business cases are technique 10.7. You use it in the task Define Change Strategy. The guide names 4 elements: need assessment, desired outcomes, assess alternatives and recommended solution. The 5 parts used here are a template built from these, not BABOK wording.
Prepare: who decides, and on what?
- Before writing, answer 3 questions. Who decides? (The shop owner.) How big should it be? (1 page for a small change.) Who has the facts? (Finance, customer service agents, developers.) Then write the decision as 1 question: not "Should we build an app?" but "How do we win back shoppers on phones?"
The request: we need our own app
- The request: the sales manager says "We need our own mobile app. Every big shop has one." That is a solution looking for a problem, not a business case. It may still be right, so test it with the 5 parts: need, options, costs and benefits, risks, recommendation.
Part 1: the need
- Part 1, the need: state the problem in numbers without naming a solution. 7 in 10 visits come from phones but only 3 in 10 orders do. Finance puts the gap at about $15,000 profit a month. The measurable outcome: 4 in 10 orders from phones within a year.
Part 2: the options
- Part 2, the options: list at least 3, and make one of them do nothing. A: do nothing. B: fix the website checkout for phones. C: build the app. For each, check scope (what's in it) and feasibility (can we really do it). Option B only appeared because we asked about the problem.
Part 3: costs and benefits
- Part 3, costs and benefits: count one-time costs (build, test, train) and running costs (hosting, support, updates). Benefits are more money in (extra orders) or less money out (fewer support calls). Give a source for every number, such as a developer quote or finance report.
Parts 4 and 5: risks and the recommendation
- Part 4, risks: for each option, list risks (the build runs late), assumptions (shoppers will download an app) and constraints (only 2 developers). Part 5, recommendation: pick 1 option, say why, and say exactly what you need, such as an amount and a yes by a date. A clear no is also a good result.
Step 1: prove the problem
- Step 1, prove the problem. Web numbers show phone shoppers drop off at the checkout. Support tickets repeat "I can't see the pay button on my phone". Watching 2 shoppers confirms the pay button hides behind the phone's keyboard. Nobody is asking for an app.
Step 2: check each option is real
- Step 2, check each option is real by asking the people who would deliver it. A: easy, but the problem stays. B: a 1-page checkout, bigger pay button and phone wallet payments, live in 3 months with the current team. C: the whole shop rebuilt for 2 phone systems, live in 9 months, with extra hires.
Step 3: put numbers on each option
- Step 3, put numbers on each option (made-up figures). A: $0 cost, $0 gain. B: $60,000 one-time, $6,000 a month extra profit, $1,000 a month to run, so $5,000 left. C: $300,000 one-time, $14,000 a month, $4,000 to run, so $10,000 left. The app does earn more.
Step 4: work out the payback
- Step 4, payback = one-time cost divided by what's left each month. B: $60,000 / $5,000 = 12 months. C: $300,000 / $10,000 = 30 months. Add the build time (3 and 9 months) and, from today, B pays back at 15 months and C at 39. Option A loses up to $15,000 a month.
Step 5: stress test it
- Step 5, stress test: what if profit is only half? B: $3,000 minus $1,000 = $2,000, so $60,000 pays back in 30 months. C: $7,000 minus $4,000 = $3,000, so $300,000 takes 100 months, over 8 years. Also list each option's assumption, such as phone wallets working with the payment provider.
Worked example: the finished one-page case
- The finished 1-page case: the need ($15,000 a month gap), the outcome (4 in 10 phone orders in a year), 3 options, costs and payback (B: $60,000, 12 months; C: $300,000, 30 months), the risks (100 months at half profit) and the ask: approve $60,000 for option B by month end, and review the app in 6 months.
Confirm it, then ask for the decision
- Play it back before the meeting. Ask finance if they would sign the numbers, check dates with the developers, and talk to the sales manager in private. With the owner, start with the recommendation, then the need, then the numbers. If asked "What if we say no?", the answer is up to $15,000 a month lost.
Where it goes, and keeping it alive
- Keep the numbers in Excel so anyone can change a guess and see the payback move. Put the case in Confluence and link Jira user stories back to it. The BABOK Guide warns cases often aren't updated after approval: recheck it if costs jump, and compare real results with the promise after launch.
5 common mistakes
- 5 common mistakes: starting with the answer and hunting for numbers, showing only 1 option, forgetting running costs, using numbers with no source, and filing the case away after the yes without checking results.
Recap
- Recap: a business case compares benefits with the cost and effort to get something and live with it. 5 parts: need, options, costs and benefits, risks, recommendation. 5 steps: prove the problem, check the options, add numbers, work out payback, stress test. Always include do nothing.
Common mistakes
- Starting with the answer. If the app is already chosen and you go looking for numbers to back it up, that's an excuse, not a case. Write the need first, with no solution named, as one question like "How do we win back shoppers on phones?"
- Showing only one option. With nothing to compare, nobody can really decide. List at least 3, including do nothing, so the decision maker can see what happens if they say no.
- Forgetting the running costs. The app's $4,000 a month to run is what pushed its payback to 100 months when profit halved. Count hosting, support and updates for every option, not just the build cost.
- Numbers with no source. The first person who asks where a number came from can sink the whole case. Note the source next to each figure, such as the developer's quote, the finance report or last month's orders.
When a business analyst uses this
A stakeholder asks for a new system in a workshop. Before anyone builds anything, the BA writes a 1-page business case comparing do nothing, a small fix and the full build, with payback for each. They check the numbers with finance before the sponsor's sign-off meeting, then link the approved case to the Jira epic.
Questions people ask
What is a business case?
It's a decision tool that justifies a course of action by comparing its benefits with the cost and effort to get it and live with it. A good one compares several options, including doing nothing, and ends with a clear recommendation.
How do you structure a business case?
Use 5 parts: the need, the options, the costs and benefits, the risks, and the recommendation. For a small change, all 5 fit on 1 page.
Is a business plan the same as a business case?
No. A business plan describes a whole business and how it will run. A business case supports one decision, such as whether to fix a checkout or build an app, by comparing the options.
