How to Write a Business Case: A Step-by-Step Guide With Examples

What Is a Business Case?

A business case is a structured document that presents the rationale for a proposed project, investment, purchase, or organizational change — providing decision-makers with the information they need to evaluate whether to approve it, reject it, or request further analysis. A well-constructed business case defines the problem being solved, quantifies the cost of inaction, presents and compares the available options, recommends a preferred approach, and makes a clear argument for why the expected benefits justify the proposed investment.

Business cases are used across industries and organizational functions: to justify capital expenditure, to secure budget for new software, to propose a new product line, to make the case for hiring additional headcount, or to obtain approval for a process change that requires resources. They are one of the most universally required documents in professional life, and one of the most frequently written poorly.

📌 TL;DR — Key Takeaways
• A business case justifies a proposed investment or project to decision-makers by documenting the problem, options, costs, benefits, and recommendation
• The executive summary is the most important section — many decision-makers read only this
• Quantify benefits wherever possible: vague claims about “improved efficiency” are less persuasive than specific time and cost savings
• Always present multiple options, not just your preferred one — including doing nothing
• Business cases are different from business plans: a business case argues for a specific decision, a business plan describes how a business will operate

Business Case vs Business Plan: What’s the Difference?

A business case and a business plan are frequently confused, and the distinction matters. A business case is an argument for a specific decision — it answers the question “should we do this?” and provides the evidence needed to answer it. It is typically produced within an existing organization to justify an investment, project, or initiative. A business plan describes how a new or existing business will operate, generate revenue, and achieve its goals — it answers the question “how will this business work?” and is typically produced to attract investors or guide organizational planning.

A business case is usually shorter, more focused, and more decision-specific than a business plan. It may form part of a larger procurement or investment process — for example, a procurement manager or project sponsor may need to produce a business case before they are authorized to issue an RFP, approve a software purchase, or initiate a capital project. The business case is what unlocks the budget; everything that follows depends on it being persuasive.

When Do You Need a Business Case?

Not every project or purchase requires a formal business case, but several situations reliably call for one. Any significant investment — typically anything above an organization’s pre-approved budget threshold, which varies widely by company size — will require formal justification before approval. Projects that involve multiple departments or cross-functional resource commitments generally require a business case to ensure all stakeholders understand the scope and rationale. Initiatives that involve organizational change — restructuring, process redesign, system migration — require business cases both to secure approval and to establish a documented baseline for measuring success.

Software and technology purchases often require business cases even for relatively modest spend, because they involve change management, integration effort, and ongoing operational costs that extend well beyond the license price. The business case for a software investment typically needs to account for implementation costs, training, productivity dips during transition, and the ongoing cost of the tool — alongside the benefits. Organizations that skip the business case for technology purchases and later cannot demonstrate ROI often find those tools cut in the next budget cycle.

The Structure of a Business Case

A well-organized business case follows a consistent structure that guides the reader from problem to recommendation in a logical, evidence-based progression. While the exact format varies by organization and context, most effective business cases contain the same core elements in roughly the same order.

The executive summary comes first and carries disproportionate weight. In most organizational contexts, the executive summary is the only section that every decision-maker will read. It must stand alone: someone who reads only the executive summary should understand the problem, the recommended solution, the key financial metrics, and the ask. It is written last — after the full analysis is complete — but placed first. If the executive summary does not make a compelling case, the rest of the document is unlikely to save it.

The problem or opportunity statement follows. This section defines the current situation, explains why it is a problem or why the opportunity matters, and quantifies the cost of inaction. The most persuasive problem statements are specific and quantified: not “our current process is inefficient” but “our team spends 120 hours per month on manual data entry that could be eliminated, at a cost of approximately £90,000 per year in labor.” Decision-makers approve business cases when they understand the cost of doing nothing, not just the benefit of doing something.

Options Analysis: Presenting the Alternatives

One of the most common business case writing mistakes is presenting only the preferred option. Decision-makers are more likely to approve a recommendation when they can see that alternatives were considered and found less favorable — it demonstrates analytical rigor and prevents the impression that the author has already made up their mind and is simply constructing a justification.

The options section should present a minimum of three alternatives. The first is always the do-nothing option: what happens if no decision is made and the current situation continues? This option is more powerful than it appears — quantifying the full cost of inaction often makes the case for action more compellingly than any amount of benefit enumeration. The second option is typically a minimal or low-cost approach: the smallest intervention that could address the problem. The third is the recommended option. Additional options can be included if the choice is genuinely complex, but three is usually sufficient.

Each option should be evaluated against consistent criteria: estimated cost, expected benefit, implementation timeline, risk level, and strategic fit. A simple comparison table that scores each option against these criteria gives decision-makers an at-a-glance view of the trade-offs and makes the recommendation feel earned rather than asserted.

Cost-Benefit Analysis: The Financial Heart of the Business Case

The cost-benefit analysis is where many business cases succeed or fail. Decision-makers in most organizations are ultimately evaluating proposals through a financial lens: does the expected return justify the required investment, and over what timeframe? A business case that cannot answer these questions with reasonable precision — even if some uncertainty is acknowledged — gives decision-makers no basis for a confident yes.

On the cost side, include all costs: the direct purchase or implementation cost, any one-time setup or integration costs, internal labor costs (including the time of your own team during implementation), training costs, and the ongoing operational cost over a defined period (typically three years). Business cases that present only the headline license fee and ignore implementation and change management costs routinely underestimate total cost of ownership, which damages credibility when the true cost emerges later.

On the benefit side, distinguish between financial benefits (cost savings, revenue uplift, productivity gains expressed in monetary terms), operational benefits (risk reduction, compliance improvements, quality improvements), and strategic benefits (market positioning, capability building, optionality for future initiatives). Financial benefits are the most persuasive; operational and strategic benefits support the case but cannot substitute for financial quantification when the decision is primarily economic. Express financial benefits in annual terms and calculate the payback period — the time required for cumulative benefits to exceed cumulative costs — as a headline metric. Net Present Value (NPV) and Return on Investment (ROI) are additional metrics worth including for larger investments where the time value of money is significant.

Risk Assessment: Addressing What Could Go Wrong

A business case that presents only the upside without acknowledging risks signals either naïveté or motivated reasoning, both of which damage credibility with experienced decision-makers. A short risk section that identifies the key risks, assesses their likelihood and potential impact, and describes how they will be managed demonstrates analytical maturity and gives decision-makers confidence that the proposal has been stress-tested.

Risks worth addressing include implementation risk (is the project technically complex or dependent on third parties?), adoption risk (will users actually use the new system or process?), financial risk (are the cost or benefit estimates based on assumptions that could prove incorrect?), and dependency risk (does the proposal depend on other projects, vendors, or decisions that are not yet secured?). For each risk, describe the mitigation — what specific action will reduce the likelihood or impact of this risk materializing? This turns the risk section from a list of concerns into evidence of planning.

The Recommendation Section

The recommendation section states clearly which option is being proposed, why it is preferred over the alternatives, and what specific approval or decision is being requested. This section should be direct. Many business case authors soften their recommendation in the hope of seeming balanced, which has the opposite effect — decision-makers want to know what the author recommends and why, not to re-derive the conclusion from the analysis themselves.

The ask should be equally specific: what budget is requested, for what purpose, over what timeframe, with what governance or reporting structure? A recommendation that asks for “approval to proceed with the project” is weaker than one that asks for “approval to invest £180,000 over twelve months to implement System X, with a steering committee review at month six.” Specificity builds confidence; vagueness invites questions.

How to Write an Executive Summary That Gets Read

The executive summary deserves its own treatment because it is the most high-leverage writing in any business case. It should typically be one to two pages for a document of moderate length, and it should contain: a one-sentence statement of the problem, the three most important facts about the current situation or cost of inaction, a brief description of the recommended option, the top-line financial case (investment required, expected return, payback period), and the specific decision requested.

Write the executive summary in plain language. Avoid jargon, acronyms, and technical detail. Assume the reader is an intelligent generalist who is not deeply familiar with the specific domain of the proposal. The goal is not to demonstrate expertise — that is the job of the analysis sections — but to give the decision-maker a clear, confident basis for their decision in the shortest possible time.

Business Case Example: Software Purchase

To make the structure concrete, consider a business case for a project management software purchase. The executive summary would state the problem (the team currently tracks projects across email, spreadsheets, and three separate tools, resulting in regular missed deadlines and an estimated 15% project overrun rate), describe the recommendation (implement a unified project management platform at a total first-year cost of £24,000), and state the expected return (estimated £48,000 in saved labor and reduced overruns in year one, representing a 2x ROI with a 7-month payback period).

The options section would compare three alternatives: do nothing (annual cost of status quo: £48,000 in inefficiency), a lightweight free tool (lower cost but insufficient for the team’s complexity, with significant integration gaps), and the recommended platform (full feature match, vendor support, integration with existing systems). The cost-benefit section would model three years of costs and benefits with conservative, base, and optimistic scenarios. The risk section would address adoption risk (mitigated by a structured onboarding program and a 30-day pilot), integration risk (vendor has existing connectors for the organization’s current tools), and budget risk (costs are contractually fixed for the initial term).

Common Business Case Writing Mistakes

Overstating benefits and understating costs is the most credibility-damaging mistake. Decision-makers who approve business cases and then discover the true cost or find the promised benefits did not materialize quickly learn to discount optimistic projections from future proposals. Conservatism and explicit uncertainty acknowledgment are more persuasive in the long run than confident precision that proves to be incorrect.

Writing for the author rather than the reader is a structural problem that affects many business cases. The author knows the problem intimately and may be tempted to lead with context, history, and detail that seems essential but is actually background. Decision-makers want the bottom line first. Structure the document for someone who will skim the executive summary and read the recommendation before deciding whether to read further.

Ignoring the do-nothing option makes the analysis feel incomplete and the recommendation seem predetermined. Always quantify what happens if the decision is not made. In many cases, the cost of inaction is the single most persuasive element of the entire business case.

Getting Approval: How Business Cases Are Evaluated

Understanding how decision-makers evaluate business cases is as important as knowing how to write one. Most organizational approvals are not purely analytical — they involve trust, timing, politics, and the relationship between the author and the approver. A technically perfect business case presented to the wrong person at the wrong time will fail; a reasonably good one presented by a trusted author at a strategic moment will succeed.

Pre-approval — discussing the proposal informally with key decision-makers before submitting the formal business case — is often more important than the document itself. Decision-makers who have already heard the idea, asked their questions, and had their concerns addressed informally are far more likely to approve the formal submission. A business case that surprises the approver is at a structural disadvantage from the moment it lands on their desk.

Alignment with organizational priorities is another critical factor. Business cases that explicitly connect the proposed investment to the organization’s current strategic priorities — whether that is cost reduction, growth, risk management, or compliance — are approved at higher rates than those that present the project in isolation. Understand what the decision-maker cares about most and frame the business case around that.

A Note on Business Cases in Software Procurement

For organizations evaluating software purchases, the business case is typically the document that authorizes the procurement team to begin a formal vendor selection process — issuing an RFP, running a competitive evaluation, and ultimately contracting with a vendor. For vendors competing in enterprise sales processes, understanding that the buyer has already produced an internal business case — and that your proposed solution needs to validate the assumptions in that business case, not undermine them — is a significant strategic insight. For teams whose work involves responding to the resulting RFPs and security questionnaires, Steerlab.ai automates the most repetitive parts of that response process.

Frequently Asked Questions

What is a business case?

A business case is a structured document that presents the rationale for a proposed project, investment, or initiative — defining the problem, comparing options, quantifying costs and benefits, and recommending a course of action. It provides decision-makers with the information they need to approve, reject, or request changes to a proposal.

What is the difference between a business case and a business plan?

A business case argues for a specific decision within an existing organization, answering the question “should we do this?” A business plan describes how a business will operate and generate revenue, typically produced to attract investors or guide organizational strategy. A business case is focused and decision-specific; a business plan is broader and more operational.

What should a business case include?

A complete business case includes an executive summary, a problem or opportunity statement, an options analysis (including the do-nothing option), a cost-benefit analysis with financial metrics, a risk assessment, and a clear recommendation with a specific ask. The executive summary should be able to stand alone for readers who will not read the full document.

How long should a business case be?

Length should match complexity. A business case for a small software purchase might be three to five pages. One for a major capital project or organizational transformation might run to twenty or more pages with detailed appendices. The guiding principle is that every section should earn its place: include what decision-makers need to make a confident decision, and omit what they do not.

How do you calculate ROI in a business case?

ROI is calculated as (Net Benefit ÷ Total Cost) × 100, where Net Benefit is the total financial benefit over the evaluation period minus the total cost. For example, if a £100,000 investment generates £250,000 in financial benefits over three years, the net benefit is £150,000 and the ROI is 150%. Also calculate the payback period: the point at which cumulative benefits exceed cumulative costs.

What is the most important section of a business case?

The executive summary. In most organizations, it is the only section that every decision-maker will read. It must stand alone, presenting the problem, the recommendation, the financial case, and the ask in a page or two of plain language. Write it last but place it first, and treat it as the single most important piece of writing in the document.

How do you make a business case more persuasive?

Quantify the cost of inaction, not just the benefit of action. Present multiple options rather than only your preferred one. Ground financial projections in conservative assumptions and acknowledge uncertainty explicitly. Connect the proposal to the organization’s current strategic priorities. And seek informal alignment with key decision-makers before submitting the formal document — a business case that surprises an approver is at a structural disadvantage.

When is a business case required?

Business cases are typically required for investments above a pre-approved budget threshold, projects involving multiple departments or significant resource commitments, technology or software purchases with material implementation costs, and initiatives involving organizational change. Many organizations have formal business case templates and approval processes embedded in their project governance and procurement frameworks.