Business case: definition, purpose, structure, and examples
Key takeaways
A strong business case turns a proposal into a decision by making value, costs, and risk explicit.
- Use a business case when resources are limited and there are credible alternatives, including a do-nothing baseline.
- Make roles clear: an author drafts, finance and risk challenge, and an executive sponsor owns benefits and alignment.
- Anchor the case in a measurable baseline, defined objectives, and KPIs so outcomes can be tracked after delivery.
- Compare options transparently using full costs, quantified benefits, and appraisal methods such as ROI, NPV, IRR, and payback.
- Separate risks, assumptions, constraints, and dependencies, and include mitigations and a post-implementation review plan.
Definition
In project and investment contexts, a business case is a documented rationale for undertaking a course of action. It typically sets out the problem or opportunity, defines measurable objectives, evaluates options analysis (alternatives), and recommends a preferred option supported by evidence. It is commonly used to obtain approval for resources and funding and to establish a baseline for benefits realisation and performance measurement using key performance indicators (KPIs).
For a general definition and background, see the reference overview of the concept of a business case on Wikipedia.
When to use a business case
A business case is most useful when there is a meaningful decision to be made and competing ways to allocate limited resources. Common situations include:
- New investments such as software, equipment, facilities, or hiring.
- Change initiatives such as process improvement, automation, or organisational redesign.
- Project approval when funding depends on demonstrating value and feasibility.
- Regulatory or risk-driven work where costs are clear but benefits are mainly risk reduction.
- Competing priorities where opportunity cost (what you give up by choosing one option) is material.
Many organisations require a business case before progressing from idea to funded delivery, particularly where governance frameworks and portfolio management are in place.
Who creates and who approves a business case
Ownership and approvals vary by organisation, but a typical model looks like this:
- Author: a project manager, product manager, business analyst, or subject matter expert drafts the business case with input from finance and operational teams.
- Accountable owner: the executive sponsor (often a senior stakeholder) is accountable for the case, ensuring it aligns with strategy and that benefits are owned.
- Reviewers: finance teams validate costs and investment appraisal; risk and compliance functions challenge risks and controls; procurement validates supplier assumptions.
- Approvers: a steering group, investment committee, portfolio board, or senior leadership approves the recommended option and budget.
Clear stakeholder roles reduce rework and ensure that assumptions, constraints, and delivery responsibilities are agreed early.
Key components of a business case
A well-structured business case is easy to scan and trace from problem to recommendation. Most high-performing cases include the following components:
- Problem or opportunity: what is happening now, why it matters, and what will happen if nothing changes (the baseline).
- Objectives: what success looks like, including measurable targets and timeframes.
- Scope and constraints: what is included and excluded, plus constraints such as time, budget, technical limitations, and regulatory requirements.
- Stakeholders: who is affected, who must contribute, and who will own benefits.
- Options analysis (alternatives): a shortlist of credible options, including a do-nothing or do-minimum baseline where appropriate.
- Recommended option: which option is proposed and why it is preferred.
- Benefits: quantified and non-quantified benefits, and how they support strategy.
- Costs: one-off and ongoing costs (capital and operational), including training, support, and change management.
- Investment appraisal: methods such as return on investment (ROI), net present value (NPV), internal rate of return (IRR), and payback period.
- Risks: key risks, mitigations, and residual risk.
- Assumptions and dependencies: what must be true for the case to succeed and what it relies on (for example, data quality or supplier delivery).
- Implementation plan: phases, milestones, resourcing approach, and indicative timeline.
- Metrics and KPIs: how progress and outcomes will be measured, including benefits tracking.
- Governance and approval: decision points, review cadence, and post-implementation review plan.
How to write a business case
- Define the decision to be made: state what approval is requested (funding, people, procurement authority) and by when.
- Describe the current state and baseline: quantify today’s performance, costs, cycle times, or risks so improvement can be measured.
- Set objectives and success criteria: define outcomes and KPIs, including benefits ownership and expected timing.
- Identify feasible options: include at least a baseline option and 1 to 3 credible alternatives; capture key constraints.
- Estimate benefits: quantify savings, revenue uplift, risk reduction, or service improvements; link to benefits realisation plans.
- Estimate full costs: include acquisition, implementation, training, transition, and ongoing running costs; note opportunity cost where relevant.
- Run financial appraisal: calculate ROI, NPV, IRR, and payback period; document discount rate and major assumptions.
- Assess risks, assumptions, and dependencies: rate likelihood and impact, define mitigations, and identify decision-critical unknowns.
- Recommend the preferred option: provide a clear recommendation and explain trade-offs (value, risk, feasibility, timing).
- Outline the implementation plan and governance: include timeline, milestones, responsibilities, and a post-implementation review to validate outcomes.
A more detailed guide to writing a business case is on our web site.
Financial analysis methods
Business cases often combine narrative justification with investment appraisal. Common methods include:
- Return on investment (ROI): a simple ratio comparing net benefits to costs. It is easy to communicate, but can hide timing and risk.
- Payback period: how long it takes for cumulative benefits to repay the initial investment. Useful for liquidity constraints, but ignores value after payback and time value of money.
- Net present value (NPV): discounts future cash flows back to today using a discount rate, reflecting the time value of money. A positive NPV indicates value creation under the model assumptions.
- Internal rate of return (IRR): the discount rate at which NPV equals zero. It supports comparison between investments, but can be misleading with non-standard cash flows.
Background explanations for these appraisal concepts are available from reference sources for cost–benefit analysis, net present value, and internal rate of return.
Benefits vs costs (simple structure)
| Category | Examples | How to quantify |
|---|---|---|
| Benefits | Time saved, fewer errors, faster sales cycle, improved compliance | Labour cost reduction, avoided rework, revenue uplift, avoided penalties |
| Costs | Licences, implementation, training, change management, support | Quotes, internal day rates, vendor contracts, total cost of ownership |
| Opportunity cost | Delay to another project, diverted staff time | Estimate value of displaced work and include in narrative or sensitivity |
Risks, assumptions, constraints and dependencies
Decision-makers need to understand what could undermine delivery or benefits. Good business cases separate:
- Assumptions: statements treated as true for planning (for example, adoption rates or volume growth).
- Constraints: fixed limits (for example, deadlines, budget caps, mandated technology).
- Dependencies: external items required for success (for example, data migration readiness, vendor delivery, approvals).
- Risks: uncertain events that could harm outcomes (for example, low user adoption, security gaps, scope creep).
Risks and mitigations (example)
| Risk | Impact | Mitigation | Owner |
|---|---|---|---|
| Low user adoption | Benefits not realised, process rework | Change management plan, training, champions, KPI tracking | Executive sponsor and operations lead |
| Data quality issues | Errors, low trust in reporting | Data profiling, cleansing, acceptance criteria | Data owner |
| Supplier delivery delay | Timeline slippage, higher costs | Milestone-based contract, contingency, parallel workstreams | Project manager |
Example business case
Scenario: A mid-sized service business proposes implementing a CRM to reduce manual admin, improve sales follow-up, and increase conversion rates.
Assumptions and baseline
- 40 sales and service users.
- Current admin time lost to manual updates: 2 hours per user per week.
- Average loaded labour cost: GBP 35 per hour.
- Expected time saving after rollout: 60% of current admin time.
- Revenue uplift from better follow-up: GBP 60,000 per year (conservative estimate).
- Discount rate for NPV: 8% per year (illustrative only).
Estimated costs
| Cost item | Timing | Amount |
|---|---|---|
| Implementation and configuration | Year 0 (one-off) | GBP 45,000 |
| Training and change management | Year 0 (one-off) | GBP 10,000 |
| Licences and support | Annual | GBP 24,000 |
Estimated annual benefits
- Time saving: 40 users x 2 hours/week x 52 weeks x 60% x GBP 35/hour = GBP 87,360 per year.
- Revenue uplift: GBP 60,000 per year.
- Total benefits: GBP 147,360 per year.
- Net annual benefit after licences: GBP 147,360 minus GBP 24,000 = GBP 123,360 per year.
Simple ROI, payback and NPV illustration
- Initial investment (year 0): GBP 55,000.
- Payback period: GBP 55,000 divided by GBP 123,360 is about 0.45 years (about 5 to 6 months).
- Simple ROI (year 1): (GBP 123,360 minus GBP 55,000) divided by GBP 55,000 is about 124%.
- NPV (3 years, 8% discount, simplified): NPV = -55,000 + 123,360/(1.08) + 123,360/(1.08^2) + 123,360/(1.08^3) = approximately GBP 262,000.
Interpretation: Under the stated assumptions, the business case supports approval because value is positive, payback is short, and risks can be mitigated through adoption and data-quality controls. In practice, include sensitivity analysis (best case, expected, worst case) for decision confidence.
Further business case examples are available on our web site.
Business case template
Use this template as a starting point. Keep language factual and include sources for material numbers.
Download a business case template from our web site.
1. Summary and decision request
- Decision required
- Recommended option
- Funding/resources requested
- Target decision date
2. Background and context
- Current situation and baseline performance
- Problem/opportunity statement
- Strategic alignment
3. Objectives and success measures
- Objectives
- KPIs and targets
- Benefits owners and timing (benefits realisation)
4. Scope, constraints and dependencies
- In scope
- Out of scope
- Constraints (budget, time, technology, compliance)
- Dependencies (data, suppliers, approvals)
5. Stakeholders and governance
- Executive sponsor
- Key stakeholders
- Decision-making forum (board/committee)
- Reporting cadence
6. Options analysis (alternatives)
- Option 0: do nothing / do minimum
- Option 1
- Option 2
- Evaluation criteria (value, risk, feasibility, time to benefit)
7. Recommended option and rationale
- Why this option is preferred
- Trade-offs accepted
8. Benefits, costs and investment appraisal
- Benefits (quantified and qualitative)
- Costs (one-off and ongoing)
- Opportunity cost considerations
- ROI
- NPV (discount rate and period)
- IRR
- Payback period
9. Risks and mitigations
- Top risks
- Mitigations and owners
- Residual risk
10. Implementation plan
- Approach and phases
- High-level timeline and milestones
- Resourcing plan
- Change management
11. Review plan
- How KPIs will be tracked
- Post-implementation review date and method
Business case vs business plan
These documents are related but serve different purposes. Clarifying the difference helps prevent rework and mismatched expectations.
Business case vs business plan
| Business case | Business plan |
|---|---|
| Justifies a specific investment, change, or project. | Explains how a business or product will operate and grow over time. |
| Centres on options analysis, investment appraisal, and approval. | Centres on market, strategy, operations, and financial forecasts. |
| Often used for internal governance and funding decisions. | Often used for external funding, partners, or internal planning. |
| Includes KPIs for benefits realisation and post-implementation review. | Includes broader performance targets and business milestones. |
Business case vs project charter
| Business case | Project charter |
|---|---|
| Explains why the work should be done and whether it is worth doing. | Authorises the project to start and defines roles, scope, and high-level plan. |
| Focuses on value, options, costs, benefits, and decision-making. | Focuses on delivery authority, governance, and initial project boundaries. |
Business case vs feasibility study
| Business case | Feasibility study |
|---|---|
| Recommends an option and seeks approval based on value and risk. | Assesses whether an option can be done, and under what conditions. |
| May include feasibility findings as evidence. | Often precedes or feeds into the business case. |
Governance and lifecycle
Business cases commonly follow a lifecycle so that approvals are controlled and benefits are validated:
- Draft: initial rationale, early estimates, and a shortlist of options.
- Review: finance and subject experts challenge costs, benefits, and assumptions; risks and constraints are refined.
- Approval: stakeholders and an executive sponsor endorse the recommendation; funding and authority are granted.
- Delivery updates: the implementation plan is tracked; changes that affect benefits or costs are assessed against the approved case.
- Post-implementation review: benefits realisation and KPIs are evaluated against the baseline; lessons learned inform future decision-making.
Strong governance improves transparency and reduces the chance that a business case becomes a one-off document that is never revisited.
FAQs
What is a business case?
A business case is a structured justification for a proposed investment, change, or project. It supports decision-making by comparing options and explaining expected benefits, costs, risks, assumptions, and the plan for implementation and measurement.
What should a business case include?
Most business cases include: the problem or opportunity, objectives, options analysis, the recommended option, benefits and costs, ROI/NPV/IRR and payback period, risks, assumptions, constraints and dependencies, stakeholders and executive sponsor details, an implementation plan, KPIs, and governance and approval steps.
How long should a business case be?
Length depends on complexity and risk. Many internal business cases are 2 to 10 pages plus appendices for calculations and evidence. The key is that decision-makers can understand the recommendation, numbers, risks, and obligations quickly.
Who approves a business case?
Approval is usually given by a governance body such as a steering group, investment committee, portfolio board, or senior leadership team. The executive sponsor is typically accountable for endorsing the case and ensuring benefits owners and stakeholders commit to delivery and measurement.
What is the difference between a business case and a business plan?
A business case justifies a specific initiative and asks for approval, focusing on options, value, and risk. A business plan describes how an organisation, product, or business unit will operate and grow, covering market approach, operating model, and broader financial forecasts.
How do you calculate ROI and NPV in a business case?
ROI is commonly calculated as (total benefits minus total costs) divided by total costs over a defined period. NPV discounts future cash flows using a chosen discount rate and sums them with the initial investment; a positive NPV indicates value under the model. Document the discount rate, time horizon, and key assumptions, and consider sensitivity analysis.
What makes a business case compelling?
A compelling business case has a clear baseline, credible options analysis, transparent assumptions and constraints, realistic costs and benefits with sources, an explicit risk and mitigation plan, and measurable KPIs with named benefits owners. It also explains opportunity cost and shows how governance will control change.
When is a business case required?
A business case is often required when requesting funding, committing significant resources, changing customer-facing services, or introducing material operational or compliance risk. It is also commonly required for projects that compete for prioritisation in a portfolio.