Benefits Realisation Tracking

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/)
• 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). Don't add new fields to the frontmatter — name and description are the only ones allowed (see ../../../meta/frontmatter_schema.md).

Continue from here

• A ready-made skill chain for this situation: see ../../../playbooks/
• This pack's shared guardrails: ../../CLAUDE.md

References

• ../../references/ — the pack's shared background material
• ../../CLAUDE.md — the pack's shared guardrails