Writing a Project Business Case: A Practical How-To Guide

Projects fail for many reasons, but a surprising number run into trouble before a single task is executed — because they were approved without a clear articulation of why they should exist. The project business case is the document that answers that question. Done well, it forces the project sponsor to be honest about what problem is being solved, what the realistic options are, what it will actually cost, and whether the benefits justify the investment. Done poorly — or not at all — it leaves the project without a clear mandate and without the baseline it needs to demonstrate success.

What a Business Case Actually Is

A business case is not a project plan and it is not a benefits wishlist. It is a structured argument for a specific investment decision, addressed to whoever controls the budget and has the authority to approve or reject the project. Its purpose is to give decision-makers the information they need to make an informed choice — including the option to do nothing. The business case should survive a challenge: someone who is sceptical about the project should be able to read it and understand both the reasoning for proceeding and the genuine risks of doing so.

The Core Components

1. Executive summary. A one-page distillation of the problem, the recommended option, the total investment required, the expected benefits, and the key risks. Decision-makers who read nothing else should be able to make an informed vote from the executive summary alone.

2. Problem or opportunity statement. What is the specific situation that justifies this project? Be precise. Avoid generic language like "improve efficiency" — instead, define what is currently happening, why it is a problem, what it is costing the organisation, and what the consequence of inaction is. Quantify wherever possible.

3. Options analysis. A credible business case always evaluates more than one option. The minimum set is: do nothing (the baseline); minimum viable intervention (the least investment that addresses the core problem); the recommended option (the preferred solution with full scope); and, where relevant, a gold-plated option (full scope plus enhancements) to illustrate the cost of additional scope. Each option should be assessed on cost, benefit, risk, and strategic fit.

4. Costs and benefits. Quantify both sides of the equation. On the cost side, include capital and operating costs, internal labour, change management, and post-project operating cost changes. On the benefit side, separate financial benefits (cost reductions, revenue increases, productivity gains) from non-financial benefits (risk reduction, regulatory compliance, customer satisfaction, strategic positioning). For financial benefits, show the payback period, net present value (NPV), and internal rate of return (IRR) if the investment is material.

5. Risks and assumptions. What has to be true for this business case to be valid? List the key assumptions explicitly and assess what happens if they are wrong. Identify the top risks to delivery and to benefits realisation, with a mitigation strategy for each.

6. Recommended option and rationale. State clearly what you are recommending and why. Connect the recommendation to the strategic objectives of the organisation. Explain why the other options were not selected.

Common Mistakes That Undermine Business Cases

• Showing only benefits, not costs: a business case that presents a compelling benefits story while underestimating or omitting costs will either be rejected by a scrutinising governance body or, if approved, will create an impossible expectation that the project team cannot meet.

• Ignoring non-financial value: some of the most important benefits — risk reduction, regulatory compliance, employee experience — do not appear in a financial model. A business case that reduces everything to a payback period may recommend against projects that are strategically essential and approve those that look good on paper but serve no strategic purpose.

• Underestimating implementation costs: project cost estimates that exclude internal labour, change management activity, post-go-live support, and the cost of temporary performance dips during transition consistently understate the true investment required.

• Not reviewing the business case after project close: the business case is not just an approval document — it is the instrument against which project success should be measured. If no one re-reads it at the post-implementation review, the organisation loses the feedback loop that would improve future investment decisions.

Keeping the Business Case Alive During Delivery

A business case written at initiation and filed away is a compliance exercise, not a management tool. On projects of any significant duration, the business case should be reviewed at each stage gate to confirm that the investment still makes sense given what has been learned. Scope changes, cost increases, and market changes can all shift the economic logic of the project. A project whose business case no longer stacks up should be re-scoped or stopped — continuing because "we've already spent the money" is the sunk-cost fallacy, and it is expensive.

XNM supports organisations in structuring and evaluating project investments, from business case development through to benefits realisation. Learn more about our .