The programme budget is £14 million. The change management line is £180,000, and in month three it is cut to £110,000 because the integration workstream needs more testing capacity.
The cut is not unreasonable from where the decision was made. Testing capacity has a defined output and a visible consequence if it is missing. The change budget was justified on principle, and principle loses to arithmetic every time.
Why the usual case fails
Most change management business cases argue that people are important, that adoption determines benefit realisation, and that programmes fail for people reasons. All true, all unfalsifiable, and none of it competes with a line item that has a deliverable attached.
The frequently cited industry statistics do not help either. Most are unsourced, contested, or from vendors selling the service, and a finance director who has seen one of them before will discount everything that follows. The argument has to be built from your own programme.
Build it from the risk register
The case that works is not about change management. It is about four or five specific, named failures that the organisation already believes are possible, with a number against each.
| The failure | What it costs | What prevents it |
|---|---|---|
| Order entry runs at 60% speed for six weeks | Overtime, late shipments, and the service credits in the top three contracts | Rehearsal at volume plus released super users |
| Month-end close slips twice | Audit exposure, finance overtime, delayed reporting to the board | Practice on real data, and a named escalation route |
| Two experienced people leave in the first quarter | Recruitment plus twelve months to competence, per person | Capacity protection and workload planning |
| Spreadsheet workarounds become permanent | The reporting benefit in the business case never arrives | Closing the alternative route, and post-go-live measurement |
Two rules make this credible. Use the organisation’s own numbers — its overtime rates, its service credits, its recruitment cost. And be conservative: a case that survives a sceptical finance director halving every figure is far stronger than one that does not.
The fourth row is usually the largest and the most persuasive, because it attacks the business case itself. If the reporting benefit depends on people using the system rather than a spreadsheet, then the workaround is not a nuisance, it is the mechanism by which the stated benefit fails to arrive.
Under-resourcing is a chartering error, not a saving
There is a useful piece of academic framing here that predates the current debate entirely.
In The Enterprise System Experience, M. Lynne Markus and Cornelis Tanis describe the chartering phase — the decisions that fund and shape a programme — and give, as an example of an unsound charter, the decision not to allocate sufficient resources for change management and training. It sits alongside choosing an inexperienced project manager and buying software that does not fit the business model.
Their broader argument is more useful still. Problems not detected and corrected in one phase are inherited by the next as unresolved experience risk, and the cost of fixing a problem rises with the delay in recognising it. A capability gap that could be closed with two weeks of practice in September becomes, in December, a productivity deficit requiring contractors, overtime and a recovery plan.
That is the shape of the argument for a finance audience: not that change management is valuable in the abstract, but that this specific spend now is cheaper than the specific remediation later, and the multiple is large.
Ringfence it, or it will be reallocated
Winning the budget is not the same as keeping it. Change lines are reallocated mid-programme more often than any other, because they have no hard dependency and no visible immediate consequence.
The National Audit Office reached a similar conclusion about a related problem, recommending that bodies produce plans for the legacy estate so that maintenance, support and decommissioning are systematically addressed and the required funding is ringfenced. The same logic applies to any budget line whose absence is not felt until much later.
The same report also recommends seeing technology as part of a service that involves people, processes and systems, in order to better consider the economic case for investment. That sentence is worth quoting directly in a business case, because it makes the point in language a finance function recognises: the economic case is incomplete if it prices only the technology.
Attach the money to decisions
The most durable protection is to tie the spend to things the programme has already committed to. Not “change management: £180,000”, but:
- Business rehearsal, which produces the evidence for the go/no-go decision the steering committee has to take.
- Released super users, without whom the support model has no tier zero.
- Post-go-live capability measurement, which is how benefit realisation gets evidenced.
Each is now a dependency of something the programme cannot abandon. That is a considerably harder line to cut than a workstream named after a discipline — and it is closer to the truth about what the money actually buys.
More on evidence and governance in the Change Readiness Hub, or read what change management actually costs on an ERP programme.
