How to Write a Business Case That Gets Approved

You have a great idea for a project. You know it will save time, reduce costs, and move the business forward. Now you need approval — from a manager, a client, a board, or a procurement committee. That approval lives or dies on one document: your business case.

Learning how to write a business case is one of the highest-leverage skills a project manager, consultant, or agency leader can develop. A weak business case loses budget to a competing priority. A strong one gets the green light, the resources, and often the credit.

This guide covers the exact structure, the financial logic, and the section-by-section approach that gets business cases approved.

What a Business Case Actually Is (and What It Isn't)

A business case is a structured document that justifies a proposed project or investment by analysing its costs, benefits, risks, and expected return. Its job is to answer one question for decision-makers: why should we invest in this?

It differs from a project charter (which defines scope and deliverables once a project is approved) and from a business plan (which covers an entire company's direction). A business case sits earlier in the process — it's the document that secures approval before the detailed planning begins.

Decision-makers at every level read business cases under time pressure. They scan for three things: the problem being solved, the financial case for action, and the confidence that the team can deliver. Structure your document to answer those three questions quickly, and you'll hold their attention to the end.

The Seven Sections of a Strong Business Case

1. Executive Summary

Write this section last, even though it appears first. The executive summary distils the entire document into one to two pages. It covers the core problem, the recommended solution, the key financial figures (cost, expected ROI, payback period), and the implementation timeline.

Many senior decision-makers read only the executive summary. Make it self-contained: a reader who stops here should have enough information to approve the proposal or ask a specific, informed question.

2. Problem Statement

Define the problem with precision. Vague problem statements produce vague buy-in. A strong problem statement quantifies the gap between current state and desired state.

Good: "Our client onboarding process currently takes 14 days. The industry benchmark is 5 days. This gap costs us an estimated £40,000 per quarter in delayed revenue recognition and increases churn risk for new accounts."

Weak: "Our onboarding process could be improved."

Include who is affected, how often the problem occurs, and what it costs in time, money, or competitive position. Concrete numbers turn an abstract concern into a compelling case for action.

3. Options Analysis

Present at least three options: the status quo (do nothing), a minimal intervention, and your recommended solution. Decision-makers need to evaluate your proposal against alternatives — presenting only one option looks like advocacy, not analysis.

For each option, summarise the approach, the estimated cost, the expected benefits, and the major risks. A simple comparison table works well here. The goal is to make your recommended option look like the obvious rational choice — let the data do that work.

4. Recommended Solution

Describe your recommended option in full. Cover what will be done, who will do it, how long it will take, and what resources it requires. Be specific about deliverables and milestones. The more concrete this section, the more confidence decision-makers have in the feasibility of the proposal.

5. Financial Analysis

This is the section most business cases get wrong — either too light on numbers or too buried in spreadsheet detail. The goal is clarity: a decision-maker should be able to read this section and know whether the investment makes financial sense within five minutes.

Include:

• Total cost of implementation — one-time and ongoing (CAPEX and OPEX)
• Expected benefits — quantified in revenue gained, cost saved, or time reclaimed
• ROI calculation — (Net Benefit ÷ Total Cost) × 100
• Payback period — how long until cumulative benefits exceed cumulative costs
• Scenario analysis — base case, optimistic, and conservative projections

According to data cited by distribute.so, the majority of B2B deals require a formal business case for finance or procurement approval. Decision-makers in those functions speak the language of ROI, payback periods, and NPV. Match their language, and your proposal moves faster through the approval chain.

For non-financial benefits — improved client satisfaction, reduced employee burnout, regulatory compliance — note them explicitly. Quantify where possible ("estimated 2 hours saved per team member per week across a team of 8 = 16 hours/week = £X annually").

6. Risk Assessment

Every project carries risk. Acknowledging risk clearly builds credibility; ignoring it destroys it. Present a risk register with the five to eight most significant risks, their likelihood and potential impact, and your mitigation plan for each.

Categorise risks: financial, operational, technical, and stakeholder. Decision-makers want to know that risks have been thought through — they're evaluating both the project and the team's judgment.

7. Implementation Plan

Close the business case with a clear implementation roadmap. Include phases, milestones, owners, dependencies, and a go-live date. If the project requires external vendors, note procurement timelines. If it requires internal resource reallocation, flag that now.

A realistic implementation plan tells decision-makers that the team has done the hard thinking. It reduces the risk of the business case getting approved in principle but stalling during execution.

How to Write a Business Case: The Financial Section in Detail

The financial section deserves extra attention because it's where most business cases either win or lose approval. Here's a practical framework:

Step 1: Define the cost baseline. What does the problem cost today? Time, money, and opportunity cost all count. Express this as an annual figure.

Step 2: Estimate total investment. Include all implementation costs — software, services, internal labour, training, and a 15–20% contingency buffer.

Step 3: Project annual benefits. Be conservative. A realistic benefit projection builds more credibility than an optimistic one that gets challenged. Include direct savings, productivity gains, and revenue impact.

Step 4: Calculate ROI and payback. If annual benefits are £120,000 and implementation costs £80,000, payback occurs in eight months. That's a compelling number — put it in the executive summary.

Step 5: Stress-test your assumptions. What happens if benefits come in at 70% of projection? At 50%? If the investment still makes sense under a conservative scenario, say so. This pre-empts the most common objection: "Your numbers seem optimistic."

Common Mistakes That Kill Business Case Approvals

Writing for yourself instead of your audience. Project managers write business cases for CFOs and general managers who evaluate dozens of investment proposals. Avoid jargon, explain acronyms, and lead with financial impact rather than technical detail.

Presenting only one option. A single-option business case reads as an instruction, not an analysis. Present the full options spectrum, and your recommended solution earns more credibility.

Underestimating implementation effort. Approval committees have been burned by projects that ran over time and budget. A conservative, well-reasoned implementation plan — one that accounts for change management, stakeholder alignment, and testing — signals maturity and increases approval confidence.

Burying the financial case in appendices. Keep costs, benefits, ROI, and payback in the main body. If the person who approves budget has to search for the numbers, the business case has already created friction.

Skipping the executive summary. The executive summary is read first and most often. A weak or missing executive summary means your strongest arguments never reach the people who matter most.

Presenting Your Business Case

A strong document deserves a strong presentation. If you're presenting to a senior stakeholder group, prepare a two-page visual summary alongside the full document. Lead with the problem, move to the financial case, and close with the implementation plan and the ask.

Expect questions about the financial assumptions and the risk register — those are the sections decision-makers probe hardest. Have your supporting data ready. Know your numbers without looking them up.

After the meeting, circulate the business case as a polished, professional document. Presentation quality signals execution quality. A business case that looks like it was assembled in a hurry creates doubt about whether the project will be managed any differently.

Make Your Business Case Look as Good as the Argument Inside It

You've built a rigorous case. The problem is defined, the financial logic is sound, and the implementation plan is credible. The last thing you want is a layout that undersells the work.

DocsAura turns your business case document into a professionally designed HTML page in under two minutes. Upload your Word document or PDF, choose a template, and get a polished, visually structured output ready to share with any stakeholder. No design skills required — and no more sending raw Word documents to the people whose approval you need most.

Your business case makes the argument. DocsAura makes sure it lands.