Walk into almost any public sector programme in 2026 and the delivery teams will be running fortnightly sprints, working from a discovery phase, conducting user research, and iterating on prototypes. The methodology is agile. The vocabulary is agile. The team structures are agile.
Now look at the business case approving the work.
It identifies a small number of long-term benefits. It values them in pounds and percentages. It commits the programme to realising them over a three to five year horizon. It assumes the operational world the programme is being built into will be substantively the same in year four as it is at the gate review. It is a waterfall artefact, in shape and in logic, sitting at the entrance of a programme which will then ignore its own logic for everything except the moment of investment approval.
This is the structural problem nobody names. Benefits management as currently practised is a lagging indicator framework grafted onto a delivery method which has otherwise abandoned the same logic. The two halves of the programme do not share a methodology, and the gap between them is where most outcome failures live.
Lagging indicators tell you what already happened
A benefit profile, in the orthodox sense, is a forecast of a long-term outcome with an attribution percentage and a target date. You cannot measure realisation until well after delivery. The review stage of the five-stage model is the point at which the programme finds out whether the bet paid off — often eighteen to twenty-four months after go-live, sometimes longer.
By then the programme has closed. The team has dispersed. The senior responsible owner has moved on. The opportunity to course-correct has gone, because course-correction was never part of the model. The model assumed the benefits identification work done at the start was sound enough to be measured against at the end.
Lagging indicators are not wrong. They are necessary. The problem is using them as the only signal of programme health. Modern delivery teams iterate on weekly or fortnightly cadences against working software and observed user behaviour. The benefits framework wrapped around them iterates once, at the end. The asymmetry produces a programme which is responsive to delivery feedback and deaf to outcome feedback for the entire duration of the work.
OKRs give the long-term goal an agile pulse
Objectives and key results are the obvious bridge, and the reason they have spread through technology organisations is the reason they belong inside public sector benefits frameworks. They allow a long-term outcome to be expressed as an Objective, then decomposed into Key Results which are leading indicators measurable on a quarterly cadence.
The Objective preserves the milestone goal. A programme aiming to reduce repair response times in social housing tenancies, for example, holds the reduction as its long-term benefit. The Key Results, set quarterly, sit closer to operational reality: a measurable reduction in median time-to-triage, an increase in the proportion of cases routed to the correct trade on first allocation, a decline in repeat-visit rates for the same fault. These are not the benefit. They are the leading signals the benefit is being built.
OKRs do not replace benefits management. They make it functional. The benefit profile remains the long-term commitment to Treasury or to the board. The OKR layer sits underneath it, providing quarterly evidence the programme is on a trajectory to realise the benefit, and the early warning when it is not. When a Key Result misses for two quarters running, the programme has the information to intervene while intervention is still cheap. The lagging-only model gives the same information eighteen months later, when intervention costs the next funding cycle.
The granularity also fixes a political problem. Benefit profiles are difficult to revise once approved because revision looks like failure. OKRs are designed to be revised quarterly. They carry no political weight on their own. They allow the programme to learn without admitting the original case was flawed — which, given the case was written without operational evidence, it almost always will have been.
User-centred design is what makes the KPIs honest
The OKR layer only works if the Key Results are grounded in real operational behaviour. This is where user-centred design earns its place in the benefits architecture, and it is the part of the system most public sector programmes still treat as a delivery activity rather than a benefits activity.
UCD provides three things benefits management currently lacks. The first is observed baseline data. Contextual inquiry and diary studies measure how work happens in practice before the programme is announced, before awareness contaminates the baseline, before teams start tidying up their workarounds. The second is leading-indicator candidacy. User research surfaces the behaviours which will change first if the intervention is working, and these are precisely the Key Results the OKR layer needs. The third is dis-benefit visibility. Observation finds the workarounds, the informal processes, the metric distortions which workshops about risk never surface.
Done in this sequence, UCD is not an early-stage discovery activity bolted onto delivery. It is the empirical foundation of the benefits architecture. The personas inform the Objectives. The observed behaviours inform the Key Results. The contextual data informs the baselines. The dis-benefit register comes from the field rather than the room.
This is the argument I have been making, in various forms, since I wrote the Information and Analytics Benefits Management Approach at NHS Digital, and it has not become less true with time. A decade later, most public sector programmes still write business cases without observed baselines, still measure against lagging indicators, and still wonder why the benefits do not materialise on the schedule the case predicted.
What changes if you accept this
Three things, none of which require new governance — only a reordering of existing activities.
A short pre-business-case discovery, producing observed baselines and provisional personas before the benefits section is finalised. A quarterly OKR layer wrapped around the existing benefit profiles, providing leading-indicator evidence between gate reviews. A standing UCD function continuing through delivery, refreshing the data the OKRs measure against, surfacing dis-benefits as they emerge.
The benefit profiles stay. Treasury still gets its long-term commitment. The board still gets its line of sight to outcome. What changes is the programme, in between approval and review, is no longer flying blind. The waterfall artefact at the entrance is reinforced by an agile evidence loop running underneath it, and the two halves of the programme finally share a methodology.
Until then, benefits management will keep doing what it currently does: ratifying decisions made before the evidence existed, then measuring outcomes against assumptions nobody had the chance to test. This is not benefits management. It is benefits theatre.