The metric that flatters and misleads
Ask a transformation programme how it is doing and the answer is usually a number of heads, deployed or removed. The figure is easy to count, it appears in every board pack, and it is the wrong one. A workforce redesign that has genuinely succeeded will often show little or no movement in headcount, because released capacity is absorbed into more work, better service and less overtime rather than into reductions. A programme that has failed completely may show a large movement, because the reduction happened while the work continued to be done badly somewhere else.
The CHRO and the finance function therefore need a different set of measures, and they need them early, because the first of these numbers will be uncomfortable and the temptation at that point is to choose a measure that is not. Deploying more automation does not produce a measure; the instrument has to be defined before anything is changed.
Released capacity, counted honestly
The most useful primary measure is the hours returned to the organisation by the redesigned activities, counted against a baseline taken before the change. Two disciplines keep it usable. The first is that the baseline is measured rather than estimated, from a real period of the team's work. The second is that released time is tracked for what it is actually used for, because capacity that is released and then absorbed by new demand is a business benefit of a different kind from capacity that is released and then lost.
It is worth being precise about the distinction in the reporting. Hours returned to the organisation and then spent on work that was previously queued, deferred or done badly is real value and should be reported as such. Hours returned and then absorbed by supervision, by review of machine output, or by the correction of errors the machine introduced are a cost of the change, and reporting them separately is the difference between an honest programme and an optimistic one.
Six measures that describe the work
Headcount belongs in a wider set. These six between them describe whether the work actually got better, and each can be baselined before any change.
- Cycle time. The interval from a request being raised to the outcome being delivered, measured on the same population before and after.
- Quality. First-time-correct rate, rework hours per unit of work, and the number of cases that escape to the customer or the regulator.
- Service level. Whether the promised response time is still met, and whether the backlog behaves differently at peak.
- Exception load. The share of work needing a human decision, and how that share has moved. A rising share is an early warning, not a success.
- Risk exposure. The number of decisions taken without a documented basis, and the time taken to trace a decision back to its evidence.
- Employee experience. Workload distribution, overtime, escalation volume, and how many affected people say they understand what they now do.
Work reconfiguration, which is the real outcome
The measure that is most specific to a workforce redesign is the distribution of work across the activity inventory, and it is easy to compute once the inventory exists. For each activity, record who performs it, how often, and how long it takes. A successful redesign produces a visible change: a cluster of activities that were previously the majority of a person's week now occupy a fraction of it, and new activities appear alongside them, because the freed time gets used. An activity inventory that has not changed in eighteen months of pilot activity is telling you something.
This measure also protects the organisation from the most damaging shortcut. A reduction in the number of people doing a task with no change in the activity inventory means the work has not been redistributed, only removed, and it will surface as quality deterioration or as an unowned queue within a few months.
An illustrative reading of one function
Take a hypothetical service team handling two hundred cases a week. Assume, purely for illustration, that each case currently takes seventy minutes of a person's time, of which forty minutes is spent reading the same documents and assembling the same fields, and that the machine-assisted version takes thirty minutes per case of which twenty is review. On those assumptions the handling effort per week falls by a considerable margin while the review load becomes a deliberate part of the role.
The illustrative figures are not a result. They are the shape of an argument, and the argument depends entirely on assumptions the organisation must test for itself. The transferable point is that the handling time is the wrong number to report: the interesting number is what the freed time was used for, and whether the exception rate rose. A method for building the underlying case is set out in calculating the value of enterprise AI.
A measurement plan that survives scrutiny
- Take the baseline before the first workflow changes, from records rather than interviews, and record the period and population.
- Define the measures with the accountable owner of the work, not with the programme team, and keep the set small enough to review in an hour.
- Record the cost side honestly: review time, exception handling, correction, and the productivity dip while people learn the new way of working.
- Report activity reconfiguration alongside the other measures, using the inventory, so that a headline number cannot hide an unchanged job.
- Publish the results to the affected teams, including the measures that did not improve.
- Set a review date at which the programme is continued, reshaped or stopped against the baseline.
The discipline of the baseline and the review date is the same one described in the CHRO's new mandate, and the deployment controls that make the figures auditable are covered in enterprise AI deployment.