What Is a Business Case and When Do You Need One?
A business case is a formal document that justifies a proposed investment or initiative by demonstrating that its benefits outweigh its costs and risks. Business cases are required for any investment above a defined threshold (typically set by finance policy), for any initiative that requires cross-functional resources, and for decisions that carry material risk. A business case is different from a project charter (which defines how an approved project will be run) — a business case is the document that gets the project approved in the first place.
Structure of a Business Case
A business case typically follows a structure that mirrors how decision-makers evaluate investment proposals. The structure should guide the reader from understanding the current problem to endorsing your recommended solution.
- Executive summary: Recommendation, key benefits, and total investment required (1 page)
- Problem statement: Current state, pain points, and cost of inaction
- Options analysis: 3 options evaluated (Do Nothing, Partial Solution, Recommended Solution)
- Recommended option: Detailed description of the chosen approach
- Cost-benefit analysis: Financial and non-financial benefits vs. costs
- Risk assessment: Risks of proceeding and risks of not proceeding
- Implementation approach: High-level plan, timeline, and key dependencies
- Recommendation and next steps: Clear ask with decision criteria
Presenting the Options Analysis
Decision-makers are more likely to approve a recommendation when they see it evaluated against alternatives. A three-option structure works well: Option 1 is always "Do Nothing" — this establishes the cost of the status quo and makes the case for action. Option 2 is a partial or low-cost solution that addresses the problem minimally. Option 3 is your recommended solution, which should clearly dominate on value relative to risk. Evaluate each option against the same criteria: cost, timeline, benefit, risk, and strategic fit. A simple scoring table helps readers compare at a glance.
Building the Cost-Benefit Analysis
The cost-benefit analysis is the quantitative heart of the business case. It should translate all costs and benefits into financial terms wherever possible. Costs should cover total cost of ownership over a relevant time horizon — not just the initial investment. Include capital costs, operating costs, internal resource costs, and transition costs. Benefits should be similarly exhaustive, distinguishing between hard benefits (measurable cost savings or revenue increases) and soft benefits (improved quality, reduced risk, strategic capability). Calculate NPV and payback period as standard outputs.
- Use 3-year or 5-year time horizon for investment decisions
- Apply your organization's hurdle rate for NPV calculations
- Be conservative with benefit estimates — optimistic assumptions are a red flag
- Quantify soft benefits even if imprecisely — state your assumptions explicitly
Risk Assessment
Every business case needs a honest risk assessment. Decision-makers who are surprised by risks after they have approved a project feel misled — which damages your credibility for future requests. Document the key risks of the recommended option: what could go wrong, what the likelihood is, what the impact would be, and what you would do to mitigate it. Also document the risks of NOT proceeding (often the most powerful argument for approval): competitive disadvantage, regulatory exposure, increasing technical debt, or worsening operational performance.
Getting Executive Buy-In Before the Final Document
The most common reason business cases fail to get approved is that they are introduced in the approval meeting rather than socialized beforehand. Before submitting the final document, spend time in informal conversations with key decision-makers. Understand their top concerns and address them in the document. Find a senior sponsor who will advocate for the initiative in the room before the vote. Use the business case document to confirm a decision that the room is already leaning toward making, not to persuade a skeptical audience from scratch. This socialization process is often the difference between approval and deferral.