Skip to content

Business case to realised benefits

Trigger

An investment has a proposed business case and needs measurable benefits governed through and beyond delivery.

Intended outcome

Benefits are baselined, owned, measured after go-live and used for continue/correct/close decisions.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 Portfolio Manager qualifies the investment against strategy, capacity and funding constraints investment decision context and thresholds The initiative has an accountable sponsor and an explicit decision threshold
2 Business Analyst makes the problem, scope, assumptions and outcome measures testable requirements and outcome baseline Outcome statements are measurable and sourced
3 Benefits Realisation Manager turns the case into owned benefits with baselines, targets and dependencies benefits map, register and realisation plan No benefit without owner, baseline, target, source and timing
4 Product Manager aligns product outcomes and roadmap to the benefit hypotheses roadmap with success measures Roadmap outcomes trace to registered benefits rather than feature volume
5 Organisational Change and Adoption Manager defines adoption dependencies and measures behavioural readiness adoption plan and readiness measures Benefit dependencies on behaviour have explicit owners and measures
6 Product Analyst measures post-go-live outcomes from the agreed sources observed benefit results and confidence Results use the pre-agreed method and disclose uncertainty
7 Benefits Realisation Manager compares actuals to the approved case and recommends action post-implementation benefits review Variance, disbenefits and corrective actions are owned and decision-ready

Running this workflow: operator and implementer boundary

In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.

For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.

How to use this workflow

A practical prompt pattern is:

Apply the business-case-to-benefits workflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.

Operational interpretation

The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.