How to write a business case: a practical guide for project approval

In brief

A useful business case compares realistic options and makes the evidence, expected value, costs, risks and decision clear. Follow the drafting method, review the worked example or explore the editable Business Case template.

A business case should help a decision-maker test a proposed investment. It should not simply support a solution that has already been chosen. It connects the problem or opportunity with credible evidence, realistic options and a recommendation whose assumptions can be challenged.

That does not mean every proposal needs a lengthy document or complex financial model. The right level of analysis depends on the size, risk and uncertainty of the decision. Terminology, approval thresholds, delegated authority, appraisal methods and assurance requirements also vary by organisation and jurisdiction.

This guide explains how to build a proportionate project business case, expose uncertainty and state exactly what you want an authorised person or body to decide.

What a business case is

A project business case brings together the reason for change, feasible options, expected value, costs, risks and a recommendation. It gives an authorised person or body evidence for an informed decision.

The Australian Government Department of Finance describes a business case as a key investment decision document. Its detailed guidance applies in a Commonwealth investment context. The underlying decision task is more broadly useful: explain the problem or opportunity, consider options and make the available evidence visible.

Depending on your organisation, the decision might concern funding, resources, option selection, further investigation or continued authority after a material change. The approval should identify what may proceed, any conditions and what remains subject to another decision.

What a reviewer should understand quickly

A decision-maker should be able to identify:

• the problem or opportunity and why a decision is needed now
• the exact decision being requested
• the realistic options considered and how they were compared
• the recommended option and the reason for recommending it
• the expected financial, non-financial or risk-reduction value
• the relevant implementation and ongoing costs
• the major risks, assumptions and evidence gaps
• the level of confidence in material estimates
• any conditions or limits attached to approval.

How it differs from related documents

A business case is easier to develop when each supporting artefact has a clear job.

• A project charter records the approved mandate, high-level boundaries and authority for the project or its next stage. In PMI terminology, a charter has a formal authorisation role. Organisations may use different names or combine these functions. If a separate charter is required, the Project Charter template and guide to writing a project charter can support the transition from investment decision to project mandate.
• A benefits realisation plan develops the ownership, measures and review arrangements needed to manage expected benefits beyond the initial case. A Benefits Realisation Plan template can help with that later work.
• A project management plan explains how an authorised project will be planned, managed and controlled.
• A detailed financial model examines financial relationships and scenarios. It may support a material case, but it does not replace an explanation of the problem, options, non-financial effects and decision.

These are functional distinctions, not a universal document sequence. Follow your organisation's approved lifecycle and combine or separate artefacts as required.

Who contributes

As a practical operating model, the sponsor owns or champions the case and its recommendation. The project manager can coordinate inputs and maintain the document. The business owner, finance reviewer, subject specialists and people affected by the proposal contribute evidence and challenge assumptions. A project management office (PMO) may advise on governance, proportionality and the decision pathway.

This allocation is not a universal standard. Confirm the actual owner, contributors, reviewer and delegated decision-maker for your organisation. A Stakeholder Register can help identify people who hold evidence, will assess the proposal or may be affected by the decision.

When to use a business case

A business case is useful when a proposed change needs an explicit investment or option decision. Common triggers include:

• an idea or opportunity needs funding, resources or executive authority
• several feasible responses need to be compared before commitment
• a governance body needs evidence of the investment rationale
• a proposal has material cost, risk, uncertainty or organisational impact
• an approved case has changed materially and its rationale needs to be reconsidered.

Use proportionate effort. A small, low-risk proposal may need a concise case built around the decision, evidence and main trade-offs. A large, uncertain or consequential investment may require deeper analysis, independent challenge and specialist financial, commercial, legal or technical input.

Do not force a full-scale document where an approved lightweight process provides enough evidence for the decision. Equally, do not use a short form to hide uncertainty that could materially affect the recommendation.

Gather evidence before drafting

Start with the best available evidence about the current situation. This might include operational data, user research, incident records, service measures, policy direction, prior decisions, cost information and lessons from related work. Confirm the source, date, owner and limitations of important evidence.

Separate observations from assumptions. If a baseline, estimate or target has not been validated, label it clearly. Explain how and when it will be tested. A transparent evidence gap gives the reviewer something specific to challenge or make a condition of approval.

How to write a business case

Develop the case iteratively. Options, costs, expected benefits and delivery risks will influence one another as the evidence improves. The sequence below keeps the decision visible without pretending the first draft will be final.

Step 1: state the decision requested

Write a provisional one-sentence request that names the decision, the preferred option if one has emerged, the authority sought and any known limits. Refine it as the analysis develops.

For example, a request to fund discovery and detailed design should not imply approval to procure a product or begin full implementation. The final case should make that boundary explicit.

Common mistake — leaving the decision vague: A recommendation such as ‘support the initiative’ does not tell the approver what they are authorising. State the action, funding or resources requested, the conditions and any later decisions that remain outstanding.

Step 2: define the problem or opportunity

Describe the present situation, who or what is affected, why action is being considered now and the likely consequence of maintaining the current position. Use evidence that is proportionate to the decision and acknowledge its limitations.

Common mistake — starting with the solution: Beginning with ‘we need a new system’ narrows the analysis before the need is understood. Describe the operational problem or opportunity first, then test different ways to respond.

Step 3: identify realistic options

Develop feasible alternatives that address the need at different levels of cost, change and risk. Include a business-as-usual, do-nothing or do-minimum baseline where it helps reviewers understand the consequence of not investing. A baseline is useful only when it clarifies the decision; it is not compulsory for every case.

Discard an option only for a stated reason. Compare the remaining options against consistent criteria linked to the problem, objectives and constraints.

Common mistake — presenting the preferred option as the only option: This hides trade-offs and can make the case look like retrospective justification. Show which alternatives were feasible, how they performed and why the recommendation emerged.

Step 4: describe expected value

Separate what the project will deliver from what should change when people use those outputs. Describe financial value, non-financial value and risk reduction where each is relevant. For a material expected benefit, identify the proposed owner, measure, baseline, timing and confidence when known.

Ownership and measures can make later review clearer; they do not guarantee that a benefit will be realised. If the evidence is immature, use a range or state what needs validation instead of inventing a precise target.

Common mistake — confusing outputs with outcomes: Deliverables alone do not explain the value expected from the investment. Describe the business change the outputs should support and how the organisation may assess it.

Common mistake — using unsupported benefits: Claims such as ‘improve productivity’ or ‘reduce risk’ are difficult to assess without the expected change, affected group, evidence, measure and uncertainty.

Step 5: make relevant costs visible

Show the costs that could materially affect the choice between options. Depending on the proposal, these may include implementation, transition, internal effort, licences, support, maintenance, training, contingency and operating impacts. The Australian Government Department of Finance cost-estimation guidance emphasises whole-of-life considerations for Commonwealth investment proposals. Other organisations should apply their own finance policies and review requirements.

Distinguish estimates from approved funding and committed expenditure. Use ranges, assumptions and confidence levels where early figures are uncertain.

Common mistake — showing only the immediate purchase cost: A low entry price can be misleading when implementation effort or ongoing operating costs differ substantially between options. Show the relevant cost categories and identify any gaps that still need validation.

Step 6: test uncertainty and risk

Explain the material delivery, operational, stakeholder and benefit-realisation risks. Record the assumptions and constraints that could change the recommendation. Where financial analysis is material, an appropriate finance reviewer can help test how changes in key inputs affect the result.

This does not mean every proposal needs a complex model. Use the methods, formulas, rates and review standards required by your organisation, with suitably qualified input. Explain the effect of uncertainty instead of presenting one unexplained number as certain.

Common mistake — using false precision: A precise estimate built on weak assumptions can obscure rather than reduce uncertainty. Show a credible range, the important drivers and what would change the decision.

Step 7: compare options consistently

Summarise how each feasible option performs against the same decision criteria. Criteria might address strategic fit, expected value, cost, time, feasibility, risk, user impact or implementation capacity. Select only criteria relevant to the decision. Explain any weighting or judgement that materially shapes the outcome.

Include non-financial and risk-reduction effects where they matter. Do not force every effect into a monetary value when the evidence or your organisation's method does not support it.

Step 8: make a recommendation

Recommend the option that best addresses the need within the stated evidence, constraints and risk appetite. Explain the trade-offs, why other feasible options were not preferred and what evidence would cause the recommendation to change.

Common mistake — minimising change impacts: A technically sound option may still depend on changes to processes, capability or ways of working. Make affected groups, adoption needs and operational disruption visible in the assessment.

Step 9: record the decision and next review

Write the executive summary after completing the analysis. This helps it reflect the evidence rather than an early preference. Restate the exact decision, conditions, limits and delegated authority. Record the decision-maker, outcome, date and approved version using your organisation's accepted mechanism.

Common mistake — writing the executive summary first: An early summary can preserve an initial preference after the evidence changes. Write or refresh it after the analysis and recommendation are complete.

Approval of a business case does not automatically authorise procurement, expenditure or every later delivery activity. Follow the specific approval and delegation recorded for the proposal.

Identify triggers for review, such as a material change to the problem, expected benefits, cost, scope, assumptions, delivery approach or risk. A review may confirm, amend, defer or withdraw the earlier decision under the organisation's governance arrangements.

Common mistake — letting the case go stale: Material changes can invalidate the original rationale. Use your organisation's governance pathway to confirm, amend, defer or withdraw the decision.

Business case example

Illustrative only: The fictional scenario, options, roles, amounts, timings, measures and confidence assessments below are examples. They are not customer evidence, forecasts or recommended benchmarks. Adapt the method to your organisation's evidence and requirements.

Expenditure approval before purchase commitments

A fictional organisation has found that some purchase commitments are made before the required approval is recorded. This limits budget visibility and leads teams to handle similar requests differently. The available evidence confirms inconsistent workflow use, but the scale and financial effect still need validation.

Decision requested: Approve up to A$130,000 for detailed design, configuration and a controlled pilot of Option 2. The current illustrative estimate is A$90,000 to A$130,000. Pilot launch remains subject to the finance function confirming the baseline, operating-cost estimate and approval rules. This decision does not authorise organisation-wide rollout or changes to financial delegations.

Expected benefits for the preferred option

Assumption: The current platform can support the required workflow without a major upgrade.

Constraint: The pilot must use existing financial delegations and approved identity services.

Stakeholder and change impact: Requesters, approvers and finance support staff will need clear role guidance, process testing and support during the pilot.

Recommendation: Proceed with Option 2 because it addresses the immediate control and visibility problem with less cost and disruption than a platform replacement. Option 1 remains cheaper but relies mainly on guidance. Option 3 offers broader capability that the current evidence does not justify.

Approval condition: The finance function must confirm the baseline, process owner, approval rules and operating-cost estimate before pilot launch.

Validate during detailed planning: Confirm whether current role data and workflow controls can support the proposed approval path.

Why this example is reviewable

The recommendation follows a comparison rather than appearing before it. The baseline option shows the consequence of minimal investment. The larger platform option tests whether a broader response is proportionate. The cost ranges, confidence statements and validation item make uncertainty visible instead of presenting the figures as settled.

The two benefits describe expected changes, owners and methods of measurement without promising a result. The approval condition converts an evidence gap into a decision control. The decision request also reserves rollout and delegation changes for the appropriate later pathway.

Use the PMOEasy business case template

You can develop a business case using the method in this guide. If you want an editable starting point, the PMOEasy Business Case template provides a DOCX working document with XLSX support.

The template gives you practical prompts, examples, decision controls and reviewer guidance for developing and challenging a consistent investment case. It can help your team move past the blank page while leaving the evidence, analysis and judgement with the people accountable for the decision.

It does not replace your organisation's financial, governance, commercial, legal or assurance requirements. It also does not guarantee funding, approval, cost accuracy, benefit realisation or project outcomes.

For teams preparing the wider initiation set, the Project Starter Bundle combines the Business Case with a Project Charter, Stakeholder Register and kick-off meeting record. Each artefact supports a different part of the initiation conversation. Adapt the set to your organisation instead of treating it as universally complete.

What happens after the decision?

Record the outcome, conditions and approved version. If the proposal is approved, confirm the authority granted and assign owners for conditions and evidence gaps. Develop the mandate, plans, benefit controls and stakeholder arrangements required for the authorised next stage.

If the decision is deferred, identify the evidence or changes needed for reconsideration. If it is rejected, record the reason and any circumstances that would justify a future review. The Project Initiation Checklist can help teams organise the next initiation activities after an approval.

Explore the business case template

Turn the method into an editable working document for your next investment decision.

Explore the Business Case template

Need a broader initiation pack?

View the Project Starter Bundle

Use the template as a structured starting point, not as financial, accounting, investment, legal, procurement or governance advice. Apply your organisation's requirements and obtain appropriate specialist review for the decision.