Most programmes I have inherited could tell me what they had built and not what had improved. Those are different questions, and only one of them keeps a programme funded.
I run transformation, so measuring benefits is my actual job. Here is what we track, and what I have learned about doing it honestly.
Establish the baseline or lose the argument
The single most common failure is not measuring before you start.
Once the new system is live, nobody can say what the old one cost. You end up defending the programme with anecdotes and a satisfaction survey, which persuades nobody in a budget meeting.
We now spend three weeks measuring the current state before any design work. How long does the process take? How many people touch it? What is the error rate? How much rework happens?
It is unglamorous, it is nobody's favourite phase, and it is the only reason we can prove anything later.
Pick fewer measures than you want
Our first benefits framework had thirty one metrics. Nobody read it.
We now track five per programme. One efficiency measure, one quality measure, one customer measure, one financial measure, and one adoption measure.
Five fit on a page and get discussed. Thirty one become a spreadsheet somebody maintains and nobody opens.
What actually lands first
Across the programmes I have run, the early benefits are consistent and modest.
Time on a specific task falls. Rework falls, usually more than expected. Handoffs between teams reduce. Response times to customers improve because information is in one place.
What does not arrive early is headcount saving, revenue growth, or anything strategic. Those come later if they come at all, and promising them in year one is how a programme loses credibility in year two.
Separate the enabling work from the outcomes
This changed how our board reads progress.
We report two streams. Foundational work, which produces no visible benefit, and outcome work, which does.
Before we split them, the board saw quarters with nothing to show and drew the obvious conclusion. Now they see that the quarter delivered the interfaces and data corrections that the next three quarters depend on.
That distinction matters because the foundational stream is large. Our current programme spends roughly two thirds of its effort on back-end development services, and none of it is demonstrable. Reporting back-end development services as delivery rather than as a gap took real work with the board. Without a way to report it, that work looks like a gap in delivery.
Report against the baseline, not the plan
Programmes drift into reporting progress against their own plan rather than against the business.
Ninety per cent complete on a workstream tells a board nothing. It measures the programme against itself.
We report only against the baseline. The process took eleven days and now takes four. Rework was fourteen per cent and is now six.
Digital business transformation reported as plan completion can look healthy for two years while nothing measurable has changed for anyone.
Measure what got worse
Every honest benefits report includes something that regressed.
A process that got slower because a control was added. A team whose workload rose because work moved to them from somewhere else. A measure that dipped during transition and has not fully recovered.
We report those alongside the gains. Two reasons. It is true, and a report containing only good news gets treated as marketing rather than evidence.
The first time we included a regression, the conversation with the board was better than any positive report we had given.
The ninety day check
Every delivered change gets reviewed ninety days after go live, against the baseline.
We ask three things. Did the measure move? Is the change still being used as designed? What would we do differently?
About a third of our changes have not delivered what was expected. Finding that at ninety days means we can fix or reverse it. Finding it at the end of a three year programme means it has been quietly not working for years.
Adoption is a benefit measure
A capability nobody uses has delivered nothing, regardless of how well it was built.
We track usage explicitly and treat a low number as a delivery problem rather than a training problem.
The most common cause has been that the new way is slower than the workaround for some specific case. That is fixable, and only if somebody is looking.
Where the AI questions land
Every programme now has an AI component and they need the same discipline as anything else.
Our rule is that a use case needs a baseline and a ninety day check like any other change. What task does it replace, how long does that take today, and did the number move?
Teams working on our CRM ask about salesforce AI tools regularly. Those products are now branded Agentforce, renamed from Einstein Copilot in early 2025. The naming matters less than the measurement. We have approved two use cases and stopped one, and the one we stopped had enthusiastic users and no measurable effect on the task it was supposed to improve.
What I put in the quarterly pack
● The five measures, against baseline, with direction of travel.
● What is usable this quarter that was not last quarter, and by whom.
● Foundational work delivered, reported separately.
● Anything that got worse.
● What we said no to.
Five items, two pages. The last one is a recent addition and it has been surprisingly well received, because it shows the programme has a scope rather than an appetite.
Common questions
Who signs off a benefit as realised?
Finance, against the baseline. Digital business transformation benefits claimed by the programme that delivered them are not evidence.
When should benefits start appearing?
Something measurable by the end of the second quarter. Not large, and real. Programmes with nothing at nine months are usually in trouble.
Does this apply to the invisible work too?
Yes, with proxy measures. Digital business transformation reported only on visible change will always look like it stalled during the foundational phases.
Who should own benefits tracking?
Not the programme. Ours sits with finance, which removes the obvious conflict and makes the numbers credible.
What if a benefit does not materialise?
Say so, early. The cost of admitting it at ninety days is small. At three years it is the whole credibility of the function.
How do we handle benefits that are hard to quantify?
Measure a proxy and be explicit that it is one. Digital business transformation produces real benefits that resist quantification, and a stated proxy is more honest than an invented figure.
The version I trust
A programme that can show a baseline, five measures, a ninety day review on everything delivered, and at least one thing that went backwards.
That report is harder to produce and considerably more convincing than a deck of achievements. It is also the reason our current programme is in year three with its funding intact, which is the practical test of whether digital business transformation is being measured properly.
