How to Write a Business Case

A practical, structured guide to writing business cases that get approved — with a section-by-section breakdown, financial analysis tips, and what decision-makers actually look for.

What Is a Business Case?

A business case is the document that justifies an investment — it answers the question: ‘Should we spend this money, and why?’ It presents the problem, the options for addressing it, the recommended approach, the expected costs and benefits, the risks, and the proposed delivery approach.

Business analysts write business cases because they’re positioned to do the analytical work required: understanding the problem deeply, identifying and comparing options, quantifying benefits, and building the financial model. The business case is one of the most high-stakes documents a BA will produce — getting it right determines whether a project proceeds.

Business Case Structure — Section by Section

1. Executive Summary

Write this last, but it goes first. The executive summary (1–2 pages) is the only section most senior decision-makers will read. It must stand alone and convey: the problem, the recommended solution, the key financial numbers (investment, benefit, ROI, payback period), and the decision being sought.

If the executive summary doesn’t land, the rest of the business case doesn’t matter. Clear, direct language. No jargon. Assume the reader has 3 minutes.

2. Problem Statement

Define the problem you’re solving with precision. A weak problem statement is vague: ‘Our current system is old and inefficient.’ A strong one is specific: ‘The current procurement system processes 1,200 purchase orders per month with an average 4.2-day cycle time. Industry benchmark is 1.8 days. The gap creates $340,000 in annual contract penalty exposure and 0.8 FTE of manual workaround cost.’

The problem statement should quantify the current pain where possible. Numbers give decision-makers confidence that you understand the scale of the problem.

3. Strategic Alignment

Connect the investment to the organisation’s strategic goals, regulatory obligations, or risk management requirements. A project that addresses a compliance mandate or a stated strategic priority is easier to approve than one that stands alone. Even if alignment isn’t perfect, articulate the connection clearly.

4. Options Analysis

Every business case should present at least three options:

• Option 0: Do nothing — document what happens if the organisation doesn’t act. What does the current situation cost? What risks materialise? This is the baseline all other options are compared against.
• Option 1: Minimum viable solution — the smallest intervention that addresses the core problem.
• Option 2: Recommended solution — the full preferred approach.
• Option 3 (optional): Enhanced solution — a more comprehensive approach, typically at higher cost.

For each option, document: description, estimated cost, estimated benefits, key risks, and fit with strategic requirements. The options analysis is what transforms a business case from a sales pitch into an analytical document.

5. Financial Analysis

The financial section is where most business cases are won or lost. It needs to show:

• Total cost of ownership (TCO): implementation cost + ongoing operational cost over the analysis period (typically 3–5 years)
• Benefits breakdown: distinguishing hard benefits (quantifiable, committed savings or revenue) from soft benefits (efficiency gains, risk reduction, compliance value). Be conservative — overstated benefits destroy credibility.
• Net benefit / ROI: (Total benefits – Total costs) / Total costs × 100%
• Payback period: months until cumulative benefits exceed cumulative costs
• Net Present Value (NPV): for investments over 2+ years, NPV accounts for the time value of money and is often the preferred decision metric

For a business case template with a pre-built financial model, see the free BA templates library.

6. Risk Assessment

Identify the key risks to the investment — delivery risks (technical complexity, resource availability), benefit risks (assumptions about savings materialising), and strategic risks (market changes, regulatory shifts). For each risk: likelihood, impact, and mitigation approach. A risk that isn’t named becomes a surprise. A named risk with a mitigation plan becomes a managed assumption.

7. Recommended Option and Rationale

State clearly which option you recommend and why. Reference the criteria used in the options analysis: financial return, risk profile, strategic alignment, and delivery feasibility. Decision-makers want a clear recommendation, not a ‘it depends’ conclusion that pushes the analysis back to them.

8. Implementation Overview

A high-level view of how the recommended option will be delivered: key phases, milestones, resource requirements, dependencies, and governance approach. This section gives decision-makers confidence that the recommendation is deliverable, not just theoretically sound.

9. Approvals and Next Steps

Specify: who needs to approve this business case, what the approval process is, and what happens after approval. Include a clear call to action — what are you asking decision-makers to authorise?

What Decision-Makers Look For

Senior decision-makers reviewing a business case are asking four questions:

1. Do I trust the numbers? — Have the costs and benefits been developed rigorously, with clear assumptions documented?
2. Is this the right solution? — Has the team genuinely considered alternatives, or is this a foregone conclusion dressed up as analysis?
3. What happens if it goes wrong? — Are the risks understood and managed, not just acknowledged?
4. Is the team capable of delivering this? — Does the implementation plan reflect realistic understanding of what’s involved?

Business cases that fail approval usually fail on one of these four grounds. Before submitting, test your document against each question.

Common Business Case Mistakes

• Treating it as a sales document — a business case should be an objective analysis, not a pitch. Decision-makers can smell advocacy dressed as analysis. Present the weaknesses alongside the strengths.
• Overstating benefits — conservative, credible benefit estimates build more trust than optimistic ones that get challenged. Under-promise and over-deliver.
• Ignoring the do-nothing option — skipping Option 0 makes the analysis look incomplete and raises questions about objectivity.
• Weak problem statement — a vague problem makes every solution look equally valid. Specificity in the problem statement is the foundation of a strong business case.
• Technical language in the executive summary — senior decision-makers often don’t have technical context. Plain language, clear numbers, and business outcomes — not system names and technical specifications.

Frequently Asked Questions

What should a business case include?

A complete business case includes: executive summary, problem statement, strategic alignment, options analysis (minimum 3 options including do-nothing), financial analysis (costs, benefits, ROI, payback), risk assessment, recommended option with rationale, implementation overview, and approvals/next steps.

How is a business case different from a project proposal?

A project proposal describes what you want to do. A business case justifies why it should be funded — it’s more analytical, includes financial modelling and options analysis, and is the document that secures investment approval. The project proposal typically follows the business case once funding is approved.

Who writes a business case?

Business analysts most commonly write or coordinate business cases, often working with finance, subject matter experts, and the project sponsor. The sponsor owns the business case and presents it to decision-makers; the BA provides the analytical rigour and documentation.

Further reading: How to Write a BRD | 15 Essential BA Techniques | Free BA Templates | Requirements Gathering Guide