Most business cases fail not because the project idea is bad but because the document makes decision-makers work too hard to understand it. The investment case is buried. The risks are listed without being analyzed. The financial model assumes everything goes to plan. This guide explains what a strong business case actually requires and how to write one that gets approved.
A project business case is the document that justifies initiating a project by demonstrating that the expected benefits outweigh the costs and risks, and that the proposed approach represents the best use of the organization’s resources. It is both an analytical document and a persuasion tool: it needs to be rigorous enough to withstand scrutiny and clear enough to communicate quickly to decision-makers who have competing demands on their attention.
Understanding how to write a business case is a critical skill for project managers, program managers, business analysts, and any professional responsible for securing organizational investment in initiatives they are proposing.
Key Takeaways
A strong project business case answers five questions: Why do we need this? What are we proposing to do? What will it cost and what will it return? What are the risks? How will we know it succeeded? The HM Treasury Five Case Model is the most comprehensive framework for public sector business cases; the PMI provides equivalent guidance for commercial contexts. Financial analysis must include multiple scenarios, not just a best-case projection. Approvers are most often lost at the executive summary: if that section does not make the case clearly, nothing else matters.
of projects that fail cite poor business case definition as a contributing factor (PMI research)
maximum length most senior decision-makers will read before forming a view on whether to approve
higher approval rate for business cases that include quantified risk analysis versus those that list risks only
The Structure of an Effective Business Case
Different organizations use different templates, but the essential content of any strong business case is consistent. These are the sections that must be present and what each needs to accomplish.
Executive Summary
Written last but placed first. One to two pages maximum. States the problem or opportunity being addressed, the proposed solution in plain language, the headline investment required, the expected return, the key risk, and a clear recommendation. Decision-makers who read only this section should understand the case well enough to make an informed decision. If the executive summary requires the rest of the document to make sense, it has failed.
Strategic Case: Why This Project
Explains the problem, opportunity, or strategic need that the project addresses. Links explicitly to organizational strategy: which strategic objective does this project advance? What is the cost of not acting? What happens if the status quo continues? This section must make the reader feel that the problem is real and significant before they will engage seriously with the proposed solution.
Options Appraisal: Why This Solution
Presents a short list of realistic options for addressing the problem, including a do-nothing baseline, and compares them across cost, benefit, risk, and strategic fit dimensions. The recommended option should emerge clearly from this analysis rather than appearing predetermined. Approvers who see only one option presented without alternatives reasonably question whether alternatives were properly considered.
Financial Case: Costs, Benefits, and Return
The most scrutinized section. Must include: full cost estimate (capital and operating costs, internal resource costs, one-off and recurring), quantified benefits with timing, NPV or ROI analysis, payback period, and sensitivity analysis showing how returns change under different assumptions. All assumptions must be stated explicitly. Benefits should be categorized as financial (cashable savings, revenue growth), efficiency (time savings), and strategic (harder to quantify but still important to articulate).
Risk and Assumptions
Lists the key risks with probability and impact assessment, and the mitigation actions proposed. Also lists the key assumptions on which the financial case depends. Honest risk disclosure does not weaken a business case; it builds credibility. Approvers who feel risks have been minimized or glossed over discount everything else in the document. Quantified risk analysis, showing the financial impact of key risks materializing, is significantly more convincing than a risk register with red/amber/green ratings.
Commercial Case: Delivery Approach
Explains how the project will be delivered: the proposed methodology, build versus buy versus partner decision, procurement approach if external suppliers are involved, and the governance structure for delivery oversight. For projects involving external contracts, this section must also address commercial risk: supplier selection, contract terms, and performance management.
Management Case: How Success Will Be Measured
Defines the benefits realization plan: which metrics will be tracked, at what intervals, by whom, and how the project team will be held accountable for delivering the benefits stated in the financial case. Projects that cannot define measurable success criteria have not actually defined what success means. The management case also covers governance arrangements during delivery: reporting, decision-making authority, and escalation paths.
The Financial Analysis: What Approvers Actually Check
| Financial Metric | What It Shows | What Approvers Look For |
|---|---|---|
| Net Present Value (NPV) | Total value created by the project in today’s money, after accounting for the time value of money | Positive NPV; sensitivity of NPV to key assumptions; discount rate justification |
| Internal Rate of Return (IRR) | The discount rate at which NPV equals zero; the project’s effective return on investment | IRR exceeds the organization’s cost of capital or hurdle rate |
| Payback Period | Time to recover the initial investment from project benefits | Payback within the organization’s investment horizon; alignment with project lifecycle |
| Benefit-Cost Ratio (BCR) | Total benefits divided by total costs; how much value is created per dollar invested | BCR above 1.0; public sector typically requires BCR above 1.5 for major investments |
| Sensitivity Analysis | How the NPV or BCR changes when key assumptions vary (costs higher by 20%, benefits lower by 30%) | Case remains positive under realistic downside assumptions; author understands the key value drivers |
The Most Common Business Case Failures
Benefits inflation: Overstating or double-counting benefits to make the financial case work is the most common and most damaging business case error. Approvers who have seen inflated business cases before will scrutinize every benefit line. If any benefit cannot be defended under questioning, the entire financial case loses credibility.
Cost underestimation: Optimism bias in cost estimation is well documented. Reference class forecasting, comparing cost estimates to actual costs of similar completed projects, consistently reveals that initial estimates are too low. Adding a contingency range based on historical overrun rates for similar projects is more credible than a single-point estimate with no contingency.
No do-nothing option: A business case that presents only the proposed solution has not demonstrated that doing nothing is worse. The do-nothing baseline must be explicitly analyzed: what happens to costs, risks, and performance if the project does not proceed?
Weak executive summary: The most analytically rigorous business case fails if the executive summary does not make the case clearly in two pages or less. Decision-makers form a view from the executive summary and then read the detail selectively to confirm or challenge it. An executive summary that requires the full document to be understood first will not be read carefully.
Persuading decision-makers to approve a business case requires more than analytical rigor. Understanding your audience, anticipating their concerns, and structuring your argument to address those concerns directly are communication skills that are as important as the financial modeling. Our guide on building effective negotiation and persuasion skills covers the influencing techniques that complement analytical business case writing. For projects requiring cross-functional input and sign-off, our guide on cross-functional collaboration covers how to build the coalition of support that makes approval more likely.
Frequently Asked Questions
How long should a project business case be?
Long enough to make the case, short enough to be read. For small projects (under six months, single team), two to four pages is appropriate. For major capital programs, 20 to 50 pages is common, with a two-page executive summary that stands alone. The most common mistake is length: padding a business case with detail that does not change the decision adds bureaucracy without adding value.
Who should write the business case?
The project sponsor is accountable for the business case, but the writing is typically done by the project manager, business analyst, or a dedicated business case writer. The financial analysis requires input from finance. The risk assessment benefits from independent input rather than only the project team’s perspective. The executive summary should be written or heavily edited by the project sponsor to ensure it reflects their voice and commitment.
What is the difference between a business case and a project charter?
A business case justifies the investment in the project: it argues that the project should be done. A project charter (or project initiation document in PRINCE2) authorizes the project and defines how it will be managed: scope, objectives, governance, roles, and timeline. The business case comes first; the project charter is produced once the business case is approved.
How should benefits be classified in a business case?
Benefits are typically classified as cashable (direct cost reduction that can be removed from the budget), non-cashable efficiency (time savings that free capacity but do not reduce headcount), and strategic or qualitative (risk reduction, compliance improvement, customer experience enhancement). All three types should be included; cashable benefits carry the most weight but non-cashable benefits are often where the largest value lies.
How does methodology choice affect the business case?
The chosen delivery methodology affects how costs are structured (Agile costs are harder to estimate upfront), how benefits are realized (iterative delivery may produce earlier partial benefits), and how risks are managed (Agile manages scope risk differently from Waterfall). The business case should reflect the methodology choice in its cost model and benefits realization plan. Our guide on Agile vs. Waterfall vs. PRINCE2 covers how methodology choice affects delivery planning.
Develop the Project Leadership Skills That Drive Approval and Delivery
Rcademy’s project and process management courses build the analytical, financial, and leadership capabilities that project professionals need to write compelling business cases, select the right delivery approach, and manage complex projects to successful outcomes.
This Article is Reviewed and Fact Checked by Ann Sarah Mathews
Ann Sarah Mathews is a Key Account Manager and Training Consultant at Rcademy, with a strong background in financial operations, academic administration, and client management. She writes on topics such as finance fundamentals, education workflows, and process optimization, drawing from her experience at organizations like RBS, Edmatters, and Rcademy.