By Ritvars Mētra, Founder of ReadinessCompassThe template is 95 per cent standard. That was the design principle, it was agreed at board level, and it is the reason the business case works.
Four countries then take roughly twice as long as planned, and in the post-implementation review they are described as having been resistant to standardisation. In three of the four, what actually happened was that the plan assumed something untrue about how work is organised there.
What actually varies
Global change plans tend to treat local difference as a single category called localisation, sized as a translation budget. The variation that costs schedule is mostly not linguistic.
| What varies | Schedule impact | Usually planned for |
|---|---|---|
| Employee representation and consultation rights | Weeks to months, with a veto in some jurisdictions | Rarely, and almost never on the critical path |
| Statutory process requirements — invoicing, payroll, retention | Design rework if found late | Partly, via finance |
| Period-end and holiday calendars | Whole waves land in the wrong month | Occasionally |
| Local process variants that exist for a real reason | Discovered during testing, at the worst moment | No — treated as non-compliance |
| Capability and infrastructure differences | Training and support volume, unevenly | Assumed uniform |
| What else is landing on those people | Determines whether anything is absorbed at all | Almost never |
The first row is the one that produces genuine hard stops. Across the EU, Directive 2002/14/EC requires information and consultation on decisions likely to lead to substantial changes in work organisation, and several Member States go considerably further — in Germany a system merely suitable for monitoring triggers co-determination, which is close to every system a programme deploys.
The variant problem, stated honestly
Every local team has process differences, and they fall into three groups that look identical from head office:
- Legally or contractually required. Must be accommodated. Cheap if found in design, expensive in testing.
- Genuinely better, for a real reason — a customer expectation, a supplier constraint, a physical layout. Worth keeping, and sometimes worth adopting globally.
- Habit, or a workaround to a problem the new system solves. Should go, and will go if the case is made locally rather than asserted centrally.
The failure is not choosing standardisation. It is being unable to tell the three apart, and therefore treating every local objection as the third kind. Local teams know exactly which of their variants are which, and will say so if asked in a setting where the answer might change something.
Markus and Tanis make the underlying point about enterprise systems generally: adopters typically adjust their ways of working to fit the package because modifying it has negative consequences — but they also note that organisations can configure the same system in ways that destroy the integration benefits they bought it for. Standardisation is a means, not the outcome, and treating it as the outcome is how a programme ends up defending a design nobody can operate.
Sequence waves by absorption, not by size
Wave design is usually driven by geography, entity size or system dependency. The variable that predicts whether a wave lands is different: how much change those specific people are already absorbing.
There is a good published example. When the Bank of England renewed the Real-Time Gross Settlement system, one of four replans was triggered because the European Central Bank moved its own migration date close to the Bank’s — creating, as the National Audit Office records it, too high a level of change for users to manage safely. A central bank moved its date because the receiving population could not absorb two things at once, and an audit body recorded that as sound practice.
Applied to a multi-country plan, that means asking, per country, what else is happening to those teams in that quarter — a local system change, a restructure, a regulatory deadline, peak season. Saturation is a property of the receiving group, and it is not visible from a programme plan organised by entity size.
The same NAO report notes the Bank planned delivery as a series of stages, each capable of operation in its own right. That is the design principle worth importing: every wave should leave the organisation in a workable state, so that a later wave can slip without stranding an earlier one.
Measure by country, and expect the spread
A global readiness number is close to useless on a multi-country programme, because the whole risk lives in the variance. Reporting readiness by function, country and wave is the minimum, with the reporting thresholds set in advance so small country teams are suppressed rather than either exposed or silently dropped.
Two practical cautions. Response scales are not culturally neutral — comparing raw agreement scores across countries measures response style as much as readiness, so compare movement over time within a country rather than levels between them. And a country reporting uniformly high readiness with a low response rate is usually the one to visit first.
What to hold and what to release
Hold the data model, the core process spine, and the definitions that make consolidated reporting possible. Those are what the investment was actually for.
Release the things that cost little to vary and a great deal to fight: local approval thresholds, the sequence of steps within a task, training format and language, support hours, and go-live timing relative to local calendars. Programmes routinely defend these on consistency grounds and pay for them in delay.
More on rollout readiness across countries in the Change Readiness Hub, or read how consultation obligations affect the critical path.