GCC Build OSv0
/api

Lock benefits realisation modelpmo.dec.benefits_realisation_lock

P1 GCC

Summary

Lock how programme benefits will be measured post go-live: metrics, baselines, owner, cadence. After lock, the benefits team has its commission.

Rationale prompt skeleton

Rationale should reference the benefits-realisation-model question and the success criteria. Confirm baseline capture is scheduled before cutover.

Default options (2)

lead_indicator_plus_lag_indicator Lead + lag indicators with quarterly review

Lead indicators (e.g., capability adoption, ticket volume) tracked monthly; lag indicators (e.g., cost reduction, cycle time) tracked quarterly with attribution against the baseline.

Pros
  • + Early signal on whether benefits are landing
  • + Quarterly cadence aligned to finance reporting
  • + Defendable methodology for attribution
Cons
  • − Requires baseline data to be captured at programme start
  • − Attribution is always disputable
lag_only_annual Lag indicators only, annual review

Annual benefits audit comparing programme outcomes to baseline.

Pros
  • + Low overhead
  • + Clearer signal-to-noise at the year mark
Cons
  • − No early warning; first signal is one year in
  • − Risk of methodology being designed retrospectively to fit the result

Default approval chain

  1. Admin
  2. ExecutiveViewer

Linked evidence questions (2)

id prompt workstream
pmo.q.benefits_realisation_model How will programme benefits be measured post go-live? Capture the model: what gets measured, by whom, on what cadence, attributed against what baseline. pmo.programme_charter
pmo.q.kpi_definitions What KPIs does the programme report? For each, capture name, formula, data source, owner, target value, target date, and current value. pmo.reporting_cadence