How to Write a Business Case

A good idea is not enough to win approval and funding. To get a decision-maker to commit money, people or time, you usually need a business case: a structured argument that explains why something is worth doing and what the organisation gets in return. Done well, a business case turns a vague proposal into a clear choice. This guide walks through how to write one, section by section, so your next idea actually gets approved.

What a business case is

A business case is a document that justifies a proposed investment or project by setting out the problem, the options for addressing it, the costs and benefits, and a recommended way forward. It exists to help someone make a decision — usually to approve, amend or reject a proposal.

Crucially, a business case is not a project plan and not a sales pitch. A project plan describes how you will do the work; a business case argues whether the work should happen at all. And while it should be persuasive, it earns trust by being honest about costs, risks and alternatives — not by hiding them.

A typical structure looks like this:

1. Executive summary
2. The problem or opportunity
3. The options considered
4. Costs and benefits
5. Risks and assumptions
6. Recommendation and next step

You can adapt the order, but those building blocks should all be present.

Start with the problem, not the solution

The most common mistake is leading with the solution — "we should buy this software" — before establishing why anything needs to change. Decision-makers want to understand the problem first.

State clearly:

• What is wrong, or what opportunity exists. Be specific and, where you can, quantify it ("orders take five days to process" beats "our process is slow").
• Why it matters now. What is the cost or risk of leaving it unaddressed?
• Who is affected. Customers, staff, the wider business.

Frame the problem so well that the reader is nodding before they reach your recommendation. If they accept the problem is real and worth solving, half your work is done.

A sharp problem statement also keeps the rest of the document honest: every option and benefit should trace back to solving this problem.

Lay out the options

A recommendation is only convincing if it is a genuine choice between alternatives. Present a short list of realistic options — usually three to five — and always include the "do nothing" baseline.

For each option, briefly describe what it involves and its main pros and cons. Typical options might be:

• Do nothing — keep the status quo (shows the cost of inaction).
• A minimal fix — cheaper, faster, partial.
• The recommended option — your preferred route.
• A premium option — more ambitious, more expensive.

Comparing options does two things: it proves you have thought broadly, and it makes the trade-offs visible. The "do nothing" line is especially powerful, because it puts a price on standing still. Tools like a SWOT analysis can help you pressure-test each option's strengths and weaknesses before you write them up.

Weigh costs and benefits

This is the financial heart of the business case, and it rewards discipline.

Costs. Separate them clearly:

Benefits. Do the same:

• Tangible benefits can be measured in money — extra revenue, reduced costs, time saved (which you can value at a labour rate).
• Intangible benefits are real but harder to price — better customer experience, reduced risk, improved morale. Name them, but do not pretend they are cash.

Where possible, show the return: how the benefits compare to the costs over a sensible period, and roughly when the investment pays back. You do not need a finance degree — even a simple, clearly-stated comparison beats hand-waving. Linking the case to the metrics you already track, your key performance indicators, makes the expected benefit concrete and measurable later.

Be honest about risks and assumptions

Every business case rests on assumptions — about demand, costs, timelines or behaviour. Listing them is a sign of rigour, not weakness. State the key assumptions plainly, and flag the main risks along with how you would manage them.

Decision-makers are wary of proposals that look too clean. A short, candid risk section ("the main risk is that adoption is slow; we will mitigate with training and a phased rollout") builds far more confidence than silence. This kind of clear-eyed thinking is exactly what good operational and strategic advisers bring to the table; for an example of how disciplined operations work is framed in practice, CM Beyer's operations and delivery consulting illustrates the same emphasis on weighing options, costs and risk before committing.

Make a clear recommendation

End with a recommendation that leaves no doubt. State which option you recommend and why, in a sentence or two, tied back to the problem and the costs and benefits you have set out. Then make the ask explicit: what exactly are you requesting the reader to approve, and what is the next step?

A strong close looks like: "We recommend Option 3. It solves the processing delay, pays back within roughly a year, and carries manageable risk. We are asking for approval to proceed and a budget of X to begin in the next quarter."

Finally, add a short executive summary at the top once the rest is written — busy readers often decide from that alone, so it should capture the problem, recommendation and ask in a few lines. If the case supports a bigger move such as launching something new, our guide on pricing your product or service helps you sanity-check the revenue assumptions behind it.

The bottom line

A business case is a structured argument for a decision: it frames the problem, compares realistic options including doing nothing, weighs costs against benefits honestly, owns its risks and assumptions, and ends with a clear recommendation and a specific ask. Keep it as short as the decision allows, lead with the problem rather than the solution, and quantify wherever you can. Write it that way and you give decision-makers what they actually need — confidence that the choice is sound.