---
title: "The business case and benefits realisation"
description: "Why the business case matters A project is a means to an end. The business case explains why the organisation should invest: the problem or opportunity…"
url: https://optimizeall.com/learn/project-management-leadership-with-ai/business-case-and-benefits
updated: 2026-10-05
---

Project Management Leadership with AI · Project governance, lifecycles and the business case · lesson 4 of 21 · 14 min

# The business case and benefits realisation

## Why the business case matters

A project is a means to an end. The **business case** explains why the organisation should invest: the problem or opportunity, options considered, costs, benefits, risks and the recommended option. It is the reference point for every major decision. If it stops being valid, the project should change or stop.

## A widely used structure: the five-case model

The UK government's **Five Case Model** (HM Treasury Green Book guidance) is used in public-sector business cases in the UK and has influenced practice elsewhere. Its logic is useful for any organisation:

| Case | Question |
|---|---|
| Strategic | Is there a compelling case for change that fits strategy? |
| Economic | Which option offers the best value, considering all costs, benefits and risks? |
| Commercial | Can a viable deal be struck with suppliers or partners? |
| Financial | Is it affordable and fundable? |
| Management | Can it be delivered successfully, with governance, plans and resources? |

## Options analysis

Always include at least: **do nothing / business as usual** (the baseline), **do minimum**, and one or more **do something** options. Comparing against doing nothing shows the true incremental value.

```
Option appraisal (illustrative, 5-year view, in thousands)
                         Do nothing   Do minimum   Option A (full)   Option B (phased)
One-off costs                 0           400           1,800             1,200
Running costs (PV)        2,500         2,300           1,400             1,700
Quantified benefits (PV)      0           350           2,900             2,300
Net present value             —          +150           +2,200            +1,900
Key risks                Growing        Limited      Integration        Slower benefits
                         backlog        impact       complexity
```

Here, option A has the highest NPV but higher delivery risk; option B has lower NPV but earlier learning and less risk. The recommendation should discuss this trade-off explicitly, possibly with risk-adjusted figures.

## Defining benefits properly

Benefits must be **measurable**, **owned** and **attributable**. Use a benefits profile for each:

```
Benefit: Reduce customer onboarding time
Measure: Median time from application to account opening
Baseline: 5 working days (measured Jan–Mar)
Target: 1 working day by Q4 next year
Owner: Head of Retail Operations (business owner, not PM)
Enabling outputs: Digital ID verification; automated credit checks
Dependencies: Regulator approval of e-KYC process
Measurement: Monthly from the onboarding system dashboard
Dis-benefits: Temporary productivity dip during training
```

Distinguish **outputs** (what the project delivers, e.g., new system), **outcomes** (changes in behaviour or operations, e.g., staff use the system) and **benefits** (measurable improvements, e.g., faster onboarding). Projects deliver outputs; business owners realise benefits.

## Benefits realisation management

1. **Identify** benefits and dis-benefits in the business case.
2. **Plan**: define measures, baselines, owners, timing and dependencies (benefits map).
3. **Deliver** outputs and enable change (training, process redesign).
4. **Track**: measure after go-live against baselines.
5. **Sustain**: embed changes in business-as-usual; review after 6–12 months.

## Worked example

*Illustrative.* A fictional healthcare group in the UAE implemented an e-prescription system. The business case promised reduced medication errors and faster pharmacy turnaround. After go-live, turnaround improved, but error reduction was hard to prove because no baseline had been measured. The lesson learned: establish baselines before the project changes anything. In their next project, benefits owners measured baselines during the planning stage.

## Keeping the business case alive

Update the business case at each gate and whenever costs, benefits, timing or risks change materially. A useful habit: a one-page "business case health check" at each board meeting: still aligned with strategy? Still the best option? Benefits still achievable? Costs still justified?

## Common mistakes

- Benefits written as vague statements ("improve efficiency").
- No baseline measurement.
- The PM named as owner of business benefits.
- Optimism bias in benefits and costs; use reference class data where possible.
- Business case written to get approval, then forgotten.

## Quick self-check

Pick one benefit in your current business case. Could an independent reviewer measure it next year and agree whether it was achieved? If not, rewrite it using the benefits profile template.

## Presenting the business case

Decision-makers rarely read long documents in full. Open with a one-page summary: the problem, the recommended option, total cost and funding need, the main benefits with measures, the key risks, and the decision requested. Keep detailed analysis in appendices. Be honest about uncertainty; ranges and sensitivity analysis build credibility.

## Hands-on: options appraisal and a benefits tracker in Excel

```text
Options sheet: rows = Do minimum, Option A, Option B; columns = Year 0..5 net cash (benefits − costs)
NPV (vs rate)          =C2+NPV(Rate, D2:H2)           (year-0 value outside NPV)
Incremental NPV        =NPV_option - NPV_do_minimum
Payback (years)        helper row of cumulative cash; first year ≥ 0

Benefits tracker: A Benefit | B Measure | C Baseline | D Target | E Owner | F Due (months after go-live) | G.. monthly actuals
Latest actual          =LOOKUP(2,1/(G2:R2<>""),G2:R2)
Months elapsed         =COUNT(G2:R2)
Expected by now        =C2+(D2-C2)*MIN(1,Months_elapsed/F2)
Status                 =IF(ABS(Latest-D2)<=ABS(Expected-D2),"On track","Behind")
Sparkline              Insert > Sparklines > Line on G2:R2
```

## Template: benefits profile

```text
Benefit: ____   Type: financial / non-financial / dis-benefit
Measure (with calculation method): ____   Data source: ____
Baseline value and period measured: ____   Target and date: ____
Owner (business): ____   Dependencies and enabling changes: ____
Review points: ____   Attribution notes (what else could cause the change): ____
```

## Prompt template: pressure-testing a business case (approved AI tool)

```text
Act as a sceptical investment reviewer. For the business case below, list: (1) benefits without a measured baseline,
(2) benefits owned by the project rather than the business, (3) assumptions that would most change the NPV if wrong,
(4) missing options (including do-minimum), (5) possible double counting. Quote the sentence you are challenging.
Do not rewrite the case; produce questions only.
```

## How to measure success

- Every benefit has a measured baseline before delivery starts.
- Business case updated and re-approved at each gate.
- Benefits reviewed at agreed points after closure, with realised values recorded.

## Video lecture: The business case and benefits realisation

Lecture coming soon · 10 chapters · about 9 minutes. Read the full transcript below.

1. Why are we doing this?
2. Why it matters
3. The concept: the five-case model
4. Options analysis and benefits
5. Worked example one: a benefits profile
6. Worked example two: e-prescription in the UAE
7. Watch me do it: an options appraisal and benefits tracker
8. Presenting the business case
9. Keeping it alive, and common mistakes
10. Recap and try this now

## Lecture transcript

### Why are we doing this?

Here's a question that stops a surprising number of projects in their tracks: once this is delivered, how exactly will we know it was worth it? A healthcare group in the UAE, fictional but realistic, delivered an e-prescription system that promised fewer medication errors. After go-live, they couldn't prove it, because nobody had measured the error rate before the project started. The system worked. The benefit was invisible. In this lecture you'll learn how to structure a business case using the widely used five-case model, how to run a fair options analysis, how to define benefits so they're measurable and owned, and how to manage benefits realisation after the project ends. By the end, you'll be able to write a benefits profile that someone could actually check a year later.

### Why it matters

Why does this matter? Because projects are investments. They consume money and people that could be used elsewhere, and the business case is the argument for why this investment is worth it. It isn't a document you write to get approval and then file away. Continued business justification is one of PRINCE2's principles, and the PMBOK Guide's eighth edition puts value at the centre of its principles. So the business case is revisited at every stage gate: are the costs, risks and benefits still acceptable? And benefits that aren't defined and measured can't be managed. If you can't measure it, you can't tell whether it happened, and you can't learn from it.

### The concept: the five-case model

A widely used structure is the five-case model, which originated in the UK government's business case guidance and is used far beyond the public sector. The strategic case: why change is needed and how it fits strategy. The economic case: what options exist, and which offers the best value. The commercial case: can we procure what we need, on sensible terms? The financial case: is it affordable, and how will it be funded? And the management case: can we actually deliver it, with what governance, plans and risk management? Think of it like five questions a sensible investor would ask before backing anything. Why? Which option? Can we buy it? Can we afford it? Can we pull it off? If any pillar is weak, the whole case wobbles.

### Options analysis and benefits

Next, options analysis. Always include a do-nothing or do-minimum option as a baseline, because the question isn't 'is this project good?' but 'is it better than the alternatives, including doing less?'. Compare options on cost, benefits, risk and timing, ideally with the whole-life numbers. Then define benefits properly. A benefit is a measurable improvement that matters to the organisation, and it's owned by someone in the business, not by the project manager, because it usually appears after the project ends. For each benefit, write a profile: the measure, the baseline value, the target, who owns it, when it's expected, and what it depends on. And be honest about dis-benefits too, such as a temporary productivity dip during transition.

### Worked example one: a benefits profile

Let's write a simple benefits profile. The project automates invoice processing. The benefit: faster invoice processing. The measure: median days from receipt to approval. Median, not average, so a few extreme cases don't distort it. The baseline: twelve days, measured over the three months before the project changes anything. The target: four days. The owner: the finance operations manager, not the project manager. The timing: by month six after go-live. Dependencies: suppliers moving to electronic invoices, and approvers using the mobile workflow. And one dis-benefit: approvers will need training time in the first month. Now, a year later, anyone can check whether this benefit happened, and if it didn't, the dependencies tell you where to look.

### Worked example two: e-prescription in the UAE

Now back to the fictional healthcare group in the UAE. Their e-prescription business case promised two benefits: fewer medication errors and faster pharmacy turnaround. After go-live, turnaround clearly improved, because it was easy to measure from system timestamps. But error reduction was impossible to prove, because no baseline had been measured before the system went live, and error reporting practices changed with the new system. The organisation drew a clear lesson: establish baselines before the project changes anything. In their next project, benefits owners measured baselines during planning, agreed exactly how each measure would be calculated, and kept the method stable through go-live. It cost a few weeks of effort early on. It made the whole investment accountable.

### Watch me do it: an options appraisal and benefits tracker

Let me show you the two sheets I keep. The first is the options appraisal. One row per option, including do minimum, with costs and quantified benefits by year, and an NPV at the organisation's discount rate, so options are compared on a like-for-like basis. I also add a column for risk and a column for non-financial benefits, because not everything important has a price. The second sheet is the benefits tracker, which lives on after the project closes. One row per benefit: measure, baseline, target, owner, due date, and then monthly actuals. A sparkline shows the trend, and a status cell compares the latest actual with a straight-line path to the target. Here, the invoice benefit is on track, but a customer satisfaction benefit is flat and turns amber, so the owner gets asked what's blocking it.

### Presenting the business case

A quick word on presenting the business case, because a strong case presented badly still fails. Lead with the decision you need: approve option B, at this cost, to deliver these benefits by this date. Then one page: the problem, the options compared including do minimum, the recommendation and why, the key benefits with their owners, and the main risks. Show ranges rather than single-point promises, and say honestly what would change your recommendation, for example if supplier costs rise above a threshold. Decision-makers trust a case that admits uncertainty far more than one that looks too good to be true. And keep the full five-case document available for anyone who wants the detail, because the one-pager is the invitation, not the whole argument.

### Keeping it alive, and common mistakes

Keep the business case alive. Update it at every gate with current costs, risks and benefit forecasts, and be willing to recommend stopping or reshaping a project whose justification has gone. That takes courage, and it's one of the most valuable things a project leader can do. After closure, benefits realisation continues under the benefits owners, with reviews at agreed points. The common mistakes: no baseline; making the project manager the owner of benefits that only the business can deliver; optimism bias in benefit estimates, so use reference classes where you can; no do-nothing or do-minimum option; and counting the same benefit twice across different projects in a portfolio.

### Recap and try this now

Let's recap. A business case is the argument for an investment, and the five-case model gives it structure: strategic, economic, commercial, financial and management. Options analysis must include doing nothing or doing the minimum. Benefits are measurable improvements owned by the business, with a baseline taken before anything changes, a target, an owner, a timescale and known dependencies. And the business case is revisited at every gate, with the courage to stop if it no longer holds. Your try-this-now: write a benefits profile for one benefit of a project you know, including the measure, baseline, target, owner, timing and dependencies. Then ask yourself honestly: has the baseline actually been measured yet?

## Key takeaways

- The business case justifies investment and is the reference for major decisions throughout the project.
- The five-case structure (strategic, economic, commercial, financial, management) is a useful checklist.
- Always compare options against doing nothing and do minimum.
- Benefits need measures, baselines, business owners and a realisation plan beyond go-live.

## Try it

Write a benefits profile for one benefit of a project you know, including measure, baseline, target, owner and dependencies.

- [Previous: Choosing a delivery lifecycle: predictive, agile or hybrid](https://optimizeall.com/learn/project-management-leadership-with-ai/choosing-a-lifecycle)
- [Next: Scope, requirements and the WBS](https://optimizeall.com/learn/project-management-leadership-with-ai/scope-and-requirements)
- [All lessons of Project Management Leadership with AI](https://optimizeall.com/learn/project-management-leadership-with-ai)