By Ritvars Mētra, Founder of ReadinessCompassMost change impact registers are a list of things that will be different.
That is a document. It gets produced during design, presented once, filed, and referenced again only when something goes wrong and somebody asks whether this was foreseen. It usually was — in a row that said “finance processes will change” and nothing more.
The difference between a register that gets used and one that gets filed is almost entirely in the fields. Which columns exist determines what conversations the register can support, and most templates are missing the three or four that do the actual work.
So: what to track, and why each field earns its place.
First, what counts as an impact
Before the columns, the scope. Registers are usually incomplete in a predictable direction.
Prosci’s framework for defining change impact lists ten aspects of a person’s working life that a change can alter: processes, systems, tools, job roles, critical behaviours, mindsets and beliefs, reporting structure, performance reviews, compensation, and location.
Look at that list against a typical ERP or CRM impact register and the pattern is immediate. Almost every register captures the first three or four — processes, systems, tools, sometimes roles. Very few capture critical behaviours, mindsets, reporting lines, performance measures or compensation.
Those last six are where adoption actually fails. A team can be trained on a new system perfectly well and still not adopt it because their manager’s reporting pack has not changed, or because the behaviour the new process requires is the one their performance review penalises. Those impacts are real, they are foreseeable, and they are missing from the register because nobody thought of them as system impacts.
A practical technique from the same source: run a yesterday–tomorrow exercise for each affected role. Ten aspects, two columns, one role at a time. What does this person do today, and what will they do instead? It is slow, it produces uncomfortable specificity, and it is the fastest route to a register that is not mostly about software.
The fields
A register that supports decisions needs five groups of fields. Fewer than this and it becomes a description; many more and it stops being maintained, which is worse.
| Field | Why it exists | If you leave it out |
|---|---|---|
| Impact ID | Stable reference for escalation, RAID links and audit | Impacts get discussed by description and quietly duplicated |
| Affected role or group | The unit adoption actually happens in | “The business” is affected; nobody in particular is |
| Reach (headcount, sites) | Separates a change touching 8 people from one touching 800 | Prioritisation defaults to whoever is loudest |
| Aspect (process, system, behaviour, structure…) | Forces coverage beyond software | Register becomes a systems inventory |
| From → to | The specificity that makes everything else possible | “Process will change” — unactionable |
| Severity | How much of the role actually changes | All impacts look equal |
| Capability gap | Whether people can already do the new thing | Training is applied where it is not the constraint |
| Adoption risk (composite) | The ranking the register exists to produce | No basis for sequencing mitigation |
| Mitigation action | The response, next to the problem | Two documents, and the link between them breaks |
| Owner (a named person) | Accountability that survives the meeting | Nothing moves |
| Due date | Makes slippage visible | Everything is “in progress” indefinitely |
| Evidence of done | Distinguishes completed activity from resolved risk | Actions close without changing anything |
| Residual risk | What remains after mitigation | Closed is assumed to mean safe |
| Dependencies | Impacts are not independent | Partial fixes that cannot work |
Four of those deserve more than a table row.
From → to
This is the single highest-value field and the one most often reduced to a sentence fragment.
“Invoice approval will change” supports no decision. “Today the site manager approves invoices up to £10k by email; tomorrow approval routes through the system with a two-step workflow and the site manager’s limit drops to £5k” supports several — it tells you who to train, what will feel worse, where the approval-friction workaround will appear, and which decision right somebody has to agree to give up.
If a row cannot be written in that form, the design is not finished. That is a finding in itself, and discovering it in a register three months before go-live is considerably cheaper than discovering it in production.
Scoring: three dimensions, not one
Most templates offer a single high/medium/low. That collapses three genuinely different questions into one judgement, and the result is unusable for sequencing.
- Reach — how many people, in how many places.
- Severity — how much of the role changes. Adding a field is not redesigning a job.
- Capability gap — how far the new way is from what people can already do.
Keeping them separate is what makes the register diagnostic rather than descriptive. High reach with a low capability gap is a communications problem. Low reach with a high capability gap is a coaching problem for a small group — cheap to fix and frequently ignored because the headcount looks trivial. High on both is where the programme should be spending.
One caution when combining them into a composite score: decide in advance which dimensions cannot be averaged away. A severe capability gap in a small team is still a severe capability gap, and a composite that buries it under low reach will let it through. Score, but always show the components alongside.
Owner: a person, always
“HR”, “the PMO” and “Finance” are not owners.
The mechanism is well established. Darley and Latané’s classic experiments on diffusion of responsibility found that the more people who could plausibly act, the less likely any individual was to do so, and the slower they were when they did. That research studied bystanders in emergencies rather than change registers, but the mechanism is general: shared responsibility reduces individual responsibility.
A register with functional owners produces a meeting where everyone agrees the impact is important and nobody has done anything. One name per row, confirmed with that person rather than assigned in their absence.
Dependencies
The field almost every template omits, and the one that catches incomplete analysis.
Harold Leavitt’s diamond model made the point in 1965: an organisation is a system of interdependent parts — people, tasks, structure and technology — and a change to any one produces compensating change in the others. Changing technology without adapting tasks, structure and people is a standard reason initiatives underdeliver.
Applied to a register, this gives a useful completeness check: a technology impact with no corresponding role, behaviour or structure impact is usually an incomplete assessment rather than a simple change. If the system is changing and nothing about how people work, report or are measured is changing, either the change is trivial or somebody has not finished looking.
Linking related rows also prevents the partial fix — the training that cannot work because the reporting line it assumes has not been agreed yet.
Mitigation belongs in the same table
A register in one document and a mitigation plan in another is the most common structural mistake, and it breaks the link between problem and response almost immediately — the argument made in full in why the change register and mitigation plan should be one document.
Two fields make the mitigation half work, and both are usually missing.
Evidence of done is not “training delivered.” It is the observable state the action was supposed to produce — a threshold reached, a workaround closed, a decision minuted. Without it, actions close on the basis of activity and the impact remains exactly as it was.
Residual risk records what remains after mitigation. Some impacts cannot be fully mitigated before go-live, and saying so explicitly is more useful than a green status. Residual risk is what hypercare should be sized against, and it is what should transfer to the business at handover.
Five ways registers fail
- Written once, never revisited. Impact registers are drafted during design and abandoned at build. They should be alive through hypercare, because that is when new impacts are discovered by the people living them.
- Only systems and processes. The behaviour, structure and measurement aspects are missing, so the register cannot explain adoption failures when they come.
- Upstream providers omitted. People who supply data but do not use the system are routinely left out, which is why data quality collapses after go-live in teams nobody assessed.
- Too many rows. A 400-line register is a database, not an instrument. Consolidate to the impacts that change what somebody must do, and keep the detail underneath.
- No transition at closure. Open impacts and residual risks need named business owners when the project demobilises. PMI’s work on sustaining benefits beyond the project makes the general point: post-project work needs the same ownership discipline as delivery. An impact owned by someone leaving in six weeks is unowned.
What the register is actually for
Not documentation. A well-built impact register answers four questions on demand, which is why it is worth the maintenance:
- Which groups are most affected, and by how much?
- What are we doing about each one, and who is doing it?
- What is still unmitigated as we approach the gate?
- Which roles were never assessed at all?
That fourth question is the one that saves programmes, and it is only answerable if the register records coverage as well as content — which roles exist, not merely which ones somebody got round to writing up.
Aggregated across initiatives, the same data also shows which teams are absorbing the most change at once, which is the raw material for a saturation view nobody usually has.
If you want a working version rather than a blank spreadsheet, the Change Impact & Mitigation Register implements these fields with scoring, owners and due dates, and includes a downloadable Excel template. For how impact assessment differs from complexity assessment, see similar names, very different questions; anything that cannot be resolved inside the register belongs in the transformation RAID log.
For the surrounding process — when to run the assessment, how wide to go and how to know it is finished — see how to run a change impact assessment before go-live.