Benefits Realisation Tracking

---
name: benefits-realisation-tracking
description: "Tracks promised benefits after go-live using a Benefits Dependency Network that traces each benefit back to the business and enabling changes required to deliver it, with a named owner, baseline, and target per benefit. Use once a project has moved past approval and the question shifts from \"was it approved\" to \"is the promised value actually landing\"."
---

# Benefits Realisation Tracking

## Purpose

Tracks and reports on the realisation of promised benefits after implementation.

## Anchored in research

- Perplexity research — benefits realisation reporting practice
- Ward & Daniel (2006), *Benefits Management: Delivering Value from IS/IT
  Investments* (Cranfield School of Management) — the Benefits Dependency
  Network: mapping each promised benefit back through the business changes
  and enabling changes required to actually deliver it, and assigning a
  named benefit owner accountable for realisation.

## Method

1. **Pull every promised benefit from the business case, verbatim.** Don't
   paraphrase — a vague benefit ("improved efficiency") can't be tracked; if
   the business case is vague, flag it and push the benefit toward a
   measurable definition before tracking starts.
2. **Build a Benefits Dependency Network for each benefit** (Ward & Daniel):
   trace the chain backwards from the benefit to the business changes it
   requires (new ways of working) and the enabling changes that make those
   possible (systems, training, structure). A benefit with no identified
   business change behind it is unlikely to materialize on its own.
3. **Assign a named benefit owner** — someone in the business, not the
   project team, accountable for the benefit actually landing, since
   realisation typically happens well after the project itself has closed.
4. **Define the metric, baseline, and target for each benefit** — what's
   measured, what it was before, what it's expected to reach, and by when.
   Mark any baseline that wasn't actually measured before the change as an
   assumption.
5. **Set a tracking cadence that extends past go-live** — benefits
   realisation is measured after implementation, typically at several
   checkpoints (e.g., 3/6/12 months post go-live), not only at project
   closure.
6. **Report gaps as gaps, not as narrative.** Where a benefit is under
   target, state the shortfall and its driver — don't paper over it with
   "on track" language.

## What this skill does NOT do

- Doesn't make the final decision for you — it produces a structured draft to
  support a human decision.
- Doesn't confirm figures, market data, or competitor data from memory — it
  uses the inputs you provide, or marks an assumption clearly
  (`[assumption — verify]`).
- Doesn't collect tracking data automatically — it structures the metrics and
  the reporting framework.

## Refinement notes

Areas to keep deepening with real practice:

- your own rules of thumb and heuristics for this technique
- concrete templates (into [`../../references/`](../../references/))
- reference cases / your own examples
- what this skill deliberately does *not* do (guardrails, common mistakes) —
  add to the list above

This is an internal working note, not a claim about the skill's current
usability. Track depth privately via the `maturity` field in
`skills_index.json` (see
[`../../../meta/maturity_levels.md`](../../../meta/maturity_levels.md)).
**Don't add new fields to the frontmatter** — `name` and `description` are
the only ones allowed (see
[`../../../meta/frontmatter_schema.md`](../../../meta/frontmatter_schema.md)).

## Continue from here

- A ready-made skill chain for this situation: see [`../../../playbooks/`](../../../playbooks/)
- This pack's shared guardrails: [`../../CLAUDE.md`](../../CLAUDE.md)

## References

- [`../../references/`](../../references/) — the pack's shared background material
- [`../../CLAUDE.md`](../../CLAUDE.md) — the pack's shared guardrails