Logins Up, Benefit Missing

The benefits case is not currently measurable, and the headline KPI measures the wrong thing.

• Baseline. 40% marked cashable, yet the baseline came from a 2021 estimate revised twice and never validated. Without a signed baseline nothing can be attributed. Re-baseline with Finance-owned data: headcount by role, processing volumes, unit cost, and the specific cost pools that will actually fall. If a benefit cannot map to a budget line, it is non-cashable and should be labelled so.
• Metric. Logins rising from 1,200 to 4,800 shows people can reach the system; 11% active use of the three value-driving features shows the benefit mechanism is not operating. Replace logins with feature-level adoption, cycle time and rework rate - measures on the causal path to savings. Keep logins as a leading indicator at most.
• Attribution. Savings must be net of what would have happened anyway: attrition, volume changes, other initiatives. Agree the method with Finance before measuring, not after.
• Double counting. Check the 26 benefits for overlapping cost pools; 40% cashable typically shrinks once overlaps are removed.
• Output. A one-page realisation plan per benefit: owner, baseline, metric, target, measurement date, evidence source, Finance sign-off. Anything that cannot fill the page comes off the register.

The RAG is inconsistent with the indices, and the milestone argument does not rescue it.

• What SPI means. 0.94 means earned value is about 6% behind the value of work scheduled at this point, in cost terms. It is not a milestone count. All 14 milestones can be met while the work behind them consumed more effort than planned, because milestones are binary and say nothing about effort, quality or rework.
• What CPI means. 0.87 means roughly 13 pence in every pound buys nothing. Extrapolate: if budget at completion is 20 million, estimate at completion is 20 / 0.87, about 23 million - a 3 million forecast overrun the amber-green is hiding.
• The correct report: CPI and CPI-based estimate at completion; schedule performance measured properly; milestones reported separately; variance explanations with root cause.
• Check for distortions before concluding: is earned value based on 0/100 rules that flatter progress, has the baseline been re-set, are rates current? A CPI of 0.87 alongside met milestones usually means the baseline came from an optimistic estimate, not that performance is fine.
• Recommend re-forecasting at the next cycle and removing 'green' until indices and narrative agree. A status that survives only because of the metric chosen is precisely what governance exists to catch.

Rephasing can be legitimate, but only on evidence, and never silently.

• The test. Has the timing assumption actually changed? 'The system stabilised in March' is a claim that the benefit clock started later. If true, there should be evidence - the adoption curve, rollout dates, hypercare exit. With that evidence, restate the forecast, disclose the move and the reason, and get Finance to approve the new profile. That is rephasing.
• The other version - moving 2.1 million so this year looks better while the original figure stays in the board pack - is not rephasing. The board would be told the programme is on benefit while Finance is told it is not. That is a misstatement risk, and it is exactly the kind of thing that surfaces at year-end with no good explanation available.
• My response to the sponsor: I will prepare a restated benefits profile with the evidence, a bridge from old to new, and an explicit statement in the pack that the current-year figure has changed and why. I will not present both numbers in the same cycle.
• If the evidence does not support a move, say so in writing and let the sponsor decide with that on the record.
• Flag the 11% feature adoption separately. If the benefit mechanism is not operating, shifting the calendar by a few months will not fix it. The plan needs an adoption intervention, not a rephasing.