benefits_realization v1.0.0

name: "benefits_realization" description: "Track whether a finished project actually delivered the value it was approved on: name a benefit owner and lock a baseline before delivery, keep a benefits register with measures, targets and review dates, run post-implementation reviews at three, six and twelve months, and report honestly when a benefit will not land so the money and effort can move. Use when a business case is being written or approved, when a project is closing and its benefits need a home, when a benefits register or realisation plan is needed, or when claimed savings and improvements need checking against what really happened."

Benefits Realization

Purpose

A project can deliver every output on time and still deliver no value. The system goes live, the team disbands, and nobody ever checks whether the saving, the faster process, or the better outcome in the business case actually showed up. This skill is the discipline that closes that gap: every approved benefit gets a named owner in the business, a baseline measured before the change, a target with a date and a ramp, a place in a living register, and a series of reviews after delivery that compare what happened with what was promised.

A benefit, in the sense used here, is a measurable improvement that results from an outcome of the change, is seen as positive by one or more stakeholders, and contributes to an organisational objective. Outputs are not benefits. A new system is an output. The capability to process invoices without rekeying them is an outcome. The staff hours and error costs that then fall are the benefit. Keep that chain explicit for every benefit: output, capability, outcome, benefit, objective. If a claimed benefit cannot be traced along the chain, it is not ready to be approved.

Workflow

1. Validate each benefit before it enters the business case. Run five tests and record the answers in the benefit profile:

• Measurable: there is a measure, a data source, and a way to collect it. If it cannot be measured, it cannot later be claimed as realised. Rewrite it until it can, or record it as an unmeasured hope outside the approved case.
• Outcome-based: it describes an improvement that follows from an outcome, not the change itself. "New portal launched" fails. "Share of applications completed without staff help rises" passes.
• Owned perspective: a named stakeholder group sees it as positive. Check who sees the same outcome as a loss and record that as a disbenefit in step 7.
• Traced: the output to objective chain above is written out, with the business changes the benefit depends on, such as training, a process rewrite, or a team restructure.
• Aligned: it names the objective it contributes to and whether the contribution is direct or indirect. A benefit that fails the measurable or traced test does not go into the approved totals.

1. Name the benefit owner before delivery starts. One person per benefit, in the business unit that will live with the outcome, not in the project team. The project delivers outputs and capabilities. The owner delivers the benefit: they agree to be accountable for it, they control or can push for the enabling business changes, and they keep reporting after the project closes. The sponsor owns the whole case. The register keeper owns the register itself: complete fields, current dates, and flags raised on time. Get the owner's agreement in writing, in the profile. An owner assigned without being asked is a name on a form, not an owner. If nobody in the business will own a benefit, cut it from the case and reduce the justification accordingly.

1. Lock the baseline before the change lands. Use the baseline worksheet in assets/baseline-worksheet.md. For each measure record: the exact definition and formula, the data source and who extracts it, the baseline period, the baseline value, known seasonal patterns, and anything else changing at the same time that could move the number. Rules that keep baselines honest:

• Measure before the change, not after. A baseline reconstructed later from memory or partial records gets flagged as weak in the register, and any claim built on it is reported with that flag.
• Use a period long enough to cover normal variation. One quiet week is not a baseline for a monthly process.
• Freeze the definition. If the measure changes later, restate the baseline on the new definition or run both in parallel for one cycle. Never compare a new-definition actual against an old-definition baseline without saying so.
• Record the counterfactual in one line: what would probably have happened to this measure without the project. That line is what turns a before and after difference into a defensible claim. If baseline measurement shows the business case assumed the wrong starting point, correct the case now, before approval or delivery. Finding that at month twelve helps no one.

1. Classify the benefit so the claim matches the evidence. Record one type per benefit in the register:

• Cash-releasing financial: money that will actually leave a budget, such as a contract ended, a post removed, or spend that stops. It counts only when the budget is reduced or the spend verifiably stops. Time saved by salaried staff is not cash unless a budget line moves.
• Non-cash-releasing financial: a financial value with no budget removal, such as staff time freed for other work, cost avoided, or extra throughput handled with the same team. Report the hours or volume first and the money value second, labelled as non-cash-releasing, so nobody spends it twice in a plan.
• Quantifiable non-financial: a number that is not money, such as waiting time, error rate, completion rate, or backlog size.
• Qualitative: a real improvement that resists a direct number, such as confidence or experience quality. Give it a proxy measure anyway, such as a survey score with a fixed question and sample, and report the proxy as a proxy. Also record whether the benefit is an intermediate benefit (it enables a later one) or an end benefit (the final improvement). Intermediate and end benefits in the same chain are the most common double count. Count the value once, at the end benefit.

1. Build the benefits register and keep it as the single record. Use assets/benefits-register-template.csv. One row per benefit, with: ID (B-001, B-002, never reused), project, benefit statement written as measurable improvement plus amount plus period, objective, type, owner, sponsor, measure and formula, data source, baseline value and baseline date, target value, the ramp (expected percentage of the full benefit at each review point), full realisation date, review dates, dependencies and enabling changes, disbenefit link, status, latest actual, variance, and the decision field from step 9. The register mirrors the approved business case. Any change to a target, a date, or a forecast goes through the same approval as a case change and keeps the old value in the notes. Silent edits to targets are how failing benefits get reported as successes.

1. Set the trajectory, not just the end target. Most benefits ramp: people need time to learn new ways of working, volumes build, contracts end on their own dates. For each benefit, set the expected percentage of full realisation at the three, six and twelve month reviews, and the date full realisation is expected. A benefit expected at 100 percent on day one after go-live is usually a forecast error, not a plan. Set a tolerance band as well, for example within 10 percent of the trajectory counts as on track. The band is agreed at approval, so a review judges against a rule set in advance instead of arguing about the number on the day. Detail on trajectories and measurement is in references/measurement-and-attribution.md.

1. Record disbenefits and the cost of getting the benefit. Every change that helps one group tends to cost another: longer checks for one team, learning time, a service that gets slower while a different one speeds up. Add each disbenefit to the register as a negative row with its own owner and measure, and give it the same review dates. Net reporting is the default: a benefit is reported alongside its linked disbenefits, never alone when the two are known. Also record the ongoing cost of realising the benefit, such as licence costs, extra checking, or the owner's reporting time, so the net figure in the case stays honest after delivery.

1. Track during delivery, then hand over formally at closure. During delivery the register keeper checks monthly that owners, baselines, dependencies and forecast dates are still true, and flags any benefit whose enabling change is slipping, because a benefit usually fails in the business change, not in the build. At project closure, hand over in a short session, not by email: the owner confirms each benefit, its baseline, its next review date, and where the data comes from, and the sponsor confirms who receives the review reports now that the project board is gone. The register moves to its post-project home at that session and the first review date is booked. A project is not fully closed while its benefits have no home, no owner, or no next review date.

1. Run the post-implementation reviews at three, six and twelve months. Use assets/post-implementation-review-template.md and the worked cycle in references/worked-review-cycle.md. Each review has a different main job:

• Three months: is the change actually in use. Check adoption, the enabling changes, early actuals against the ramp, and disbenefits showing up. Most findings here are usage problems the owner can still fix cheaply.
• Six months: is the improvement real and attributable. Compare actuals with the trajectory, test the counterfactual, check for double counting with other projects claiming the same gain, and re-forecast the full benefit with reasons.
• Twelve months: did the approved value land. Give each benefit a verdict (step 10), close or extend tracking, review forecast quality against the original case, and feed the lessons into the next business case the organisation writes. Reviews use the same measure definitions as the baseline. The owner brings the data, the register keeper checks it against the source, and someone other than the owner reads the verdict before it goes to the sponsor. Extend tracking past twelve months only for benefits whose own ramp says they land later, with a named final review date. Tracking that never ends is reporting nobody reads.

1. Report variance honestly and act on the verdict. Each review gives every due benefit one verdict:

• Realised: actual meets the target within the tolerance band, on the agreed measure, with the counterfactual check passed.
• Partly realised: real improvement, below the band. Record the amount actually realised and the revised forecast.
• Delayed: still expected in full, later than planned, with a reason and a new date the owner commits to.
• Will not realise: the improvement will not happen, or will be so small it is not worth tracking. Say so at the first review where the evidence supports it, not the last one.
• Superseded: the objective moved or a later change replaced this one. Record what replaced it so the value is not lost or counted twice. For will not realise and superseded benefits, the review must end in a decision: release the budget or staff time that was held against the benefit, stop any spend that existed only to chase it, and restate the project value without it. That decision, its owner and its date go in the register decision field. Reporting a dead benefit for a year while its budget sits untouched is the exact failure this skill exists to prevent. Run bin/benefits_check.py over the register before each review: it flags missing owners and baselines, overdue reviews, actuals with no source, and will not realise verdicts with no decision recorded.

1. Close the loop on forecast quality. At the twelve month review, compare the original forecasts with the verdicts across all benefits: which types were over-forecast, which measures were weak, which baselines were missing. Write the pattern in two or three lines and attach it to the register. The next business case from the same area starts from that pattern, with tighter forecasts where the record says forecasts run high. Without this step, every new case repeats the same optimism and every review rediscovers it.

Output Contract

Setting up benefits tracking for a project delivers: one benefit profile per approved benefit (validation tests, owner agreement, baseline, measure, trajectory, dependencies, disbenefits), the benefits register in the template format with every field complete or explicitly marked not yet known with a date to supply it, and the three review dates booked with named attendees.

A review delivers: the updated register, one verdict per due benefit with the actual, the trajectory figure it was judged against, and the variance, a decision for every will not realise or superseded benefit, and a short report to the sponsor covering net realised value to date, forecast value still expected, and the top risks to the remaining benefits.

A closure of tracking delivers: final verdicts for all benefits, the total realised against the total approved, the forecast quality note from step 11, and the list of budgets or resources released by the decisions taken.

No benefit is reported as realised without a measure, a baseline, a named owner, and an actual taken from the named data source.

Operating Rules

• One register, one ID scheme, one shared home. Project copies and private spreadsheets are drafts, never the record.
• The owner is in the business, the sponsor owns the case, the keeper owns the register. Never let the delivery team mark its own benefits as realised without the owner and an independent read.
• Cash-releasing means the budget moved. If finance cannot point to the reduced budget line or the stopped spend, report the benefit as non-cash-releasing, whatever the business case called it.
• Count each improvement once. Check chains for intermediate and end benefits claiming the same value, and check across projects for two projects claiming the same saving, hour, or volume gain.
• Net means net. Adjust claims for what would have happened anyway, for gains offset by losses nearby, and for disbenefits. Gross movement is a starting point for the conversation, not the claim.
• Treat early forecasts as optimistic until the record proves otherwise. Where an organisation has its own history of forecast error, apply that correction openly in the case instead of presenting the raw forecast as the expected result.
• Never move a target, a baseline, or a measure definition without recording the old value, the reason, and who approved it.
• A missing actual is a finding, not a gap to smooth over. If the owner has not supplied data for two reporting cycles, escalate to the sponsor: the benefit is at risk by default until data resumes.
• Keep benefit statements short enough to scan in a review. Evidence, workings and history go in the profile and notes linked from the register row.
• Scale the effort to the money at stake. A small project needs the register, an owner, a baseline and the three reviews, done lightly. It does not need a programme office. Dropping the owner, baseline or reviews entirely is not scaling down, it is giving up the check.