By Ritvars Mētra, Founder of ReadinessCompass“What percentage of the programme budget should change management be?”
It is the question every sponsor asks, and the honest answer is that the percentage heuristics in circulation are not evidence. Figures between 5 and 15 per cent get quoted freely, almost always without a traceable source, usually by organisations selling the service. A number with no derivation behind it will not survive a finance review, and it should not.
The useful answer comes from working out what the cost is actually made of, because the drivers are not programme size at all.
Four things drive the cost
- Number of distinct impacted roles, not number of users. Training and materials scale with roles; delivery scales with headcount. A thousand people doing four jobs is far cheaper than three hundred doing forty.
- Geographic and language spread. Each additional language is translation, local delivery and local support. Each additional site is travel and a separate go-live.
- Whether use is mandatory or discretionary. A system replacement where the old one is switched off is a capability problem. A CRM or collaboration tool people can ignore is a sustained behavioural problem, and costs more over a longer period.
- How much capability must be built rather than informed. Awareness is cheap. Practice to fluency is not, and it is the part that determines whether anything works.
Two programmes of identical budget can differ by a factor of four on these variables. That is why a percentage is the wrong instrument.
The lines that are usually in the budget
| Line | What it covers | Commonly under-scoped |
|---|---|---|
| Change team | Lead, analysts, comms, training design | Usually sized for the build and not for hypercare |
| Training development | Materials, job aids, curriculum | Exceptions and job aids for rare-but-critical tasks |
| Training delivery | Trainers, rooms, systems, scheduling | Repeat sessions for shift patterns and absentees |
| Translation and localisation | Materials, delivery, support | Ongoing updates after the first release |
| Practice environment | Licences, refresh, realistic data | Realistic data specifically — almost always omitted |
| Post-go-live capability | Week 2 and week 4 sessions, measurement | The first thing cut, and the only thing addressing retention |
The largest cost is not in the change budget
This is the part that makes percentage benchmarks meaningless, and it is systematically invisible.
The dominant cost of change on any system programme is business people’s time: attending training, practising, rehearsing, testing, acting as super users, and working at reduced productivity for several weeks after go-live. None of it appears in the change line. It is absorbed by operational budgets, or more often not budgeted at all — which is precisely why it does not happen.
Consider the arithmetic on a mid-sized rollout, purely as illustration. Six hundred users at an average of two days of training, practice and rehearsal each is 1,200 person-days. Twenty super users released 20 per cent for four months is roughly 320 more. A productivity dip of 25 per cent across three weeks for those six hundred people is several thousand person-days again.
Against that, a change team of four for nine months is about 720 person-days. The team is the small number. The organisation’s own time is the large one, and the decision that actually matters is whether it gets protected or quietly assumed.
This is also why the National Audit Office recommends seeing technology as part of a service that involves people, processes and systems, in order to better consider the economic case for investment. An economic case that prices only the technology and the delivery team has not priced the change.
What raises and lowers it
Raises: many distinct roles; shift patterns requiring repeat delivery; multiple languages; a discretionary tool; frontline populations without desks or email; a big-bang cutover with no phased learning; and an unrealistic practice environment, which converts training cost into support cost at a worse exchange rate.
Lowers: genuinely similar roles; a phased rollout where later waves learn from earlier ones; existing super users from a previous programme; managers who already run their reviews in the system; and process changes that reduce steps rather than adding them.
The last one is worth stating plainly, because programmes rarely do: if the new process is genuinely faster for the person doing it, the change cost falls sharply. A great deal of change budget is spent overcoming designs that made someone’s job worse to make reporting better.
The answer to give
When asked for a percentage, the defensible response is to decline it and offer a derivation: this many distinct roles, this many people, this much practice per role, this much delivery, this much post-go-live support, this much released business time — totalling this, against these named risks if it is not spent.
It takes a day to produce and it survives scrutiny, which no benchmark percentage will. It also has a useful side effect: the exercise usually reveals that the business time was never budgeted by anyone, which is a more important finding than the number itself.
More on investment and evidence in the Change Readiness Hub, or read how to build the business case that protects it.