# Benefits Realization Plan: [Project name]

> Plan for how and when the benefits that justify the project will be
> realised, measured and reported: benefits map, benefit profiles,
> tracking schedule, dependencies, dis-benefits and review. Based on
> common project and programme management practice. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Start from the business case. Each benefit here must trace to a benefit claimed
  there, with the same baseline and target.
- Benefit owners sit in the business, not in the project team: the project delivers
  outputs, the business realises benefits.
- Measure the baseline before change starts. A benefit with no baseline cannot be
  proven later.
- Many benefits arrive after project closure; agree who reports them and to whom.
-->

| Field | Value |
|---|---|
| Document ID | [BRP-PROJECT-001] |
| Project | [Project name] |
| Business case | [BC-001 version x.y] |
| Version | [0.1] |
| Owner | [@sponsor] |
| Prepared by | [@project-manager] |
| Last updated | YYYY-MM-DD |

## 1. Purpose and scope

<!-- Guidance: Say which benefits are covered and the time horizon for tracking. -->

This plan covers the benefits of [Project name] claimed in business case [BC-001] and sets out how they will be measured from the baseline date [YYYY-MM-DD] until [24] months after go-live, when responsibility for tracking passes fully to the business.

## 2. Benefits map

<!-- Guidance: Link project outputs to business changes, benefits and strategic objectives. Gaps in the chain show where a benefit is assumed rather than enabled. -->

The benefits map traces each project output through the business change it enables to the benefit and strategic objective.

```mermaid
flowchart LR
  O1["Output: digital application form"] --> C1["Change: customers apply online"]
  O2["Output: automated ID verification"] --> C2["Change: no manual document checks"]
  O3["Output: trained branch staff"] --> C3["Change: staff advise instead of process"]
  C1 --> B1["B1 Shorter onboarding time"]
  C2 --> B1
  C2 --> B2["B2 Lower cost per onboarding"]
  C1 --> B3["B3 Fewer abandoned applications"]
  C3 --> B4["B4 More product sales per new customer"]
  B1 --> S1["Strategic: digital first service"]
  B3 --> S2["Strategic: grow retail customer base"]
  B2 --> S3["Strategic: cost-to-income target"]
  B4 --> S2
```

## 3. Benefits register

<!-- Guidance: One line per benefit. Classify as financial (cashable or non-cashable) or non-financial. -->

The register summarises all benefits; profiles follow in section 4.

| ID | Benefit | Type | Measure | Baseline | Target | Expected by | Owner |
|---|---|---|---|---|---|---|---|
| B1 | *Example:* Shorter onboarding time | Non-financial | Median days application to active account | 11 days | 3 days | Go-live + 3 months | Head of operations |
| B2 | *Example:* Lower cost per onboarding | Financial, cashable | Fully loaded cost per completed onboarding | 64 EUR | 28 EUR | Go-live + 6 months | Finance director |
| B3 | *Example:* Fewer abandoned applications | Non-financial | Abandoned / started applications | 18% | Below 8% | Go-live + 6 months | Head of digital |
| B4 | *Example:* More products per new customer | Financial, non-cashable | Products held at 90 days | 1.4 | 1.8 | Go-live + 12 months | Head of retail |
| [B-n] | [Benefit] | [Type] | [Measure] | [Baseline] | [Target] | [Date] | [Owner] |

## 4. Benefit profiles

<!-- Guidance: One profile per benefit. Be precise about the measure and data source so two people would get the same number. -->

Each benefit is described in a profile so that it can be measured consistently.

### 4.1 Profile B2: Lower cost per onboarding

| Attribute | Value |
|---|---|
| Description | *Example:* Reduce the cost of onboarding a retail customer by removing manual document checks and paper handling |
| Measure | Total onboarding operating cost per month divided by completed onboardings that month |
| Data source | Finance cost centre 4410 and onboarding system completion report |
| Baseline | 64 EUR (average of 12 months to YYYY-MM-DD) |
| Target | 28 EUR by go-live + 6 months |
| Interim targets | 50 EUR at +2 months, 35 EUR at +4 months |
| Value | Approximately 432,000 EUR per year at 12,000 onboardings |
| Enablers | Outputs O2 and O3; staff reallocation agreed by HR |
| Owner | Finance director |
| Measured by | Finance business partner, monthly |

The annual value is calculated as:

$$V = (C_{\text{baseline}} - C_{\text{target}}) \times N = (64 - 28) \times 12{,}000 = 432{,}000 \text{ EUR}$$

### 4.2 Profile [B-n]: [Benefit name]

| Attribute | Value |
|---|---|
| Description | [What improves and for whom] |
| Measure | [Precise definition] |
| Data source | [System or report] |
| Baseline | [Value and date] |
| Target | [Value and date] |
| Owner | [@name] |

## 5. Tracking schedule

<!-- Guidance: Plan measurement points before and after go-live. Include who reports to whom. -->

Benefits are measured and reported on the schedule below.

| Benefit | Baseline measured | First measurement | Frequency | Reported to | Final review |
|---|---|---|---|---|---|
| B1 | YYYY-MM-DD | Go-live + 1 month | Monthly | Steering committee, then operations board | Go-live + 12 months |
| B2 | YYYY-MM-DD | Go-live + 2 months | Monthly | Finance committee | Go-live + 12 months |
| B3 | YYYY-MM-DD | Go-live + 1 month | Monthly | Digital board | Go-live + 12 months |
| B4 | YYYY-MM-DD | Go-live + 3 months | Quarterly | Retail board | Go-live + 24 months |

## 6. Dependencies and enablers

<!-- Guidance: List what must be true, inside or outside the project, for each benefit to be realised. -->

Benefits depend on the following enablers.

| Benefit | Dependency | Type | Owner | Status |
|---|---|---|---|---|
| B2 | *Example:* 6 FTE of back-office capacity reallocated to customer advice | Business change | HR director | Agreed in principle |
| B3 | *Example:* Marketing campaign directs customers to the online channel | Other initiative | Head of marketing | Planned |
| B4 | *Example:* Branch sales incentive scheme updated | Policy | Head of retail | Not started |
| [B-n] | [Dependency] | [Type] | [@owner] | [Status] |

## 7. Dis-benefits

<!-- Guidance: Record negative outcomes that someone will experience as a result of the change. Hiding them damages trust. -->

The following dis-benefits are expected and managed.

| ID | Dis-benefit | Who is affected | Measure | Mitigation | Owner |
|---|---|---|---|---|---|
| DB1 | *Example:* Higher licence cost for identity verification | Finance | Annual subscription cost (48,000 EUR) | Included in B2 net value | Finance director |
| DB2 | *Example:* Fewer face-to-face contacts with new customers | Branch staff | Share of onboardings with branch contact | Follow-up call offer within 30 days | Head of retail |
| [DB-n] | [Dis-benefit] | [Affected] | [Measure] | [Mitigation] | [@owner] |

## 8. Risks to benefits

<!-- Guidance: Risks that threaten realisation after go-live. Keep them in the RAID log while the project runs. -->

Key risks to realisation:

| Risk | Benefits affected | Response | Owner |
|---|---|---|---|
| *Example:* Staff savings not released because volumes grow | B2 | Measure cost per onboarding, not headcount; agree reallocation plan | Finance director |
| *Example:* Customers keep using paper forms out of habit | B1, B3 | Paper form retired after 3 months; assisted digital in branches | Head of digital |
| [Risk] | [IDs] | [Response] | [@owner] |

## 9. Reporting and review

<!-- Guidance: Define how variance from targets is reviewed and who decides corrective action. -->

Benefit status is reported in the steering committee report until project closure, then in the [operations board] pack. A formal benefits review takes place at go-live + 6 and + 12 months. Where a benefit is more than [20%] below its interim target, the benefit owner presents a recovery plan.

| Benefit | Target | Latest actual | Date | Status | Comment |
|---|---|---|---|---|---|
| B1 | 3 days | [n] | YYYY-MM-DD | [On track / At risk / Off track] | [Comment] |
| B2 | 28 EUR | [n] | YYYY-MM-DD | [Status] | [Comment] |

## 10. Handover of benefits ownership

<!-- Guidance: Record who keeps measuring after the project closes. -->

At project closure the benefit owners confirm in writing that they accept responsibility for continued measurement and reporting. Open benefit actions are transferred with the closure report.

## Standard and licence note

Based on common project and programme management practice for benefits
management, benefits mapping and benefit profiles. This template is
original text written for this collection. Template licence: MIT.