By Ritvars Mētra, Founder of ReadinessCompassThe register is finished. Sixty impacts, scored, prioritised, each with an owner. Then you read the mitigation column and forty rows say some version of the same thing: training and communications.
The assessment worked. The mitigation never started.
This is the most common way impact work fails to convert, and it is not laziness. It happens because there is a missing step between assessing an impact and choosing what to do about it, and almost no template asks for it.
You cannot choose a mitigation from the impact alone
Take one row: “AP clerks must now code invoices to a cost centre at entry rather than in a monthly correction run.”
What should you do about it? You cannot say yet, because the answer depends entirely on why it will be hard:
- If clerks do not know how to determine the right cost centre — that is a capability problem, and practice with real invoices will fix it.
- If the information needed to code correctly does not arrive with the invoice — that is an opportunity problem in the environment, and no amount of training will touch it.
- If clerks can code correctly but are measured on invoices processed per hour — that is a motivation problem created by the performance measure, and it needs the measure changed.
Same impact, same severity, three completely different mitigations. Two of them are not training, and in two of the three cases delivering training would produce a register row that closes as complete while the impact remains exactly as it was.
The missing field is cause. Add one column between impact and mitigation asking why this will be difficult, and the mitigation column stops writing itself as “training and comms.”
Three conditions, and which one is missing
Behavioural science has a usefully simple diagnostic for this. Michie, van Stralen and West’s behaviour change wheel, in Implementation Science, places a behaviour system at its centre — the COM-B model — holding that any behaviour requires three conditions: capability, opportunity and motivation. Around that hub sit nine intervention functions, each aimed at addressing deficits in one or more of those conditions.
The logic transfers directly to change impacts. For any new way of working, ask which of the three is actually missing:
- Capability — can they do it? Skills, knowledge, judgement, physical and mental resources.
- Opportunity — does the environment allow it? System access, information availability, time, process design, decision rights, what colleagues do.
- Motivation — do they want to, and does anything reward it? Beliefs about the change, habits, incentives, what the manager asks for, what the performance review measures.
Practitioners who use ADKAR are already doing a version of this: identify the barrier point, then intervene at that point rather than everywhere. COM-B is a coarser cut with the same discipline — and its value here is that it makes the two non-training answers impossible to skip past, because opportunity and motivation deficits are where most adoption failures actually sit.
Why training is the default, and why it so often fails
Training is the default mitigation because it is the one a change team can commission on its own. Redesigning a process, changing a performance measure or reallocating decision rights all require someone else to agree. Training does not, so it gets applied to problems it cannot solve.
Even where capability genuinely is the constraint, training alone is a weak instrument. Baldwin and Ford’s foundational review of transfer of training in Personnel Psychology established that transfer depends on three interacting sets of factors — trainee characteristics, training design, and the work environment, including supervisory and peer support and the actual opportunity to perform what was learned. Their framing is that content must not only be learned and retained but generalised to the job and maintained over time.
Which means a training mitigation that does not also address whether the manager reinforces the behaviour and whether people get to practise it in real conditions has addressed one of three determinants. That is the mechanism behind the familiar pattern where training completion is high and adoption is not.
Matching the mitigation to the cause
| If the cause is | The mitigation is | Evidence it worked |
|---|---|---|
| Capability — cannot do it yet | Practice on real cases, coaching, job aids at the point of work | Unaided completion rate above threshold |
| Capability — can do it, too slowly | Repetition under realistic load; simplify the interaction | Task time within operational tolerance |
| Opportunity — information missing | Fix the upstream process or data; do not train around it | Required field populated at source |
| Opportunity — no time | Sequencing, capacity relief, remove a competing demand | Change load reduced for that group |
| Opportunity — process or rights block it | Redesign; reallocate the decision right | Path completes without escalation |
| Motivation — does not believe it | Sponsor and manager rationale, evidence, involvement in design | Belief measures move in that group |
| Motivation — measured on the opposite | Change the measure or target | Conflicting metric retired |
| Motivation — old way still accepted | Close the old channel; manager stops asking for the old artefact | Workaround volume declining |
Two things stand out from that table. Only the first two rows are training-shaped. And the “evidence it worked” column is observable in every case — which is what stops a mitigation closing on activity.
Where the cause genuinely is not obvious, do not guess. A 5 Why analysis on the two or three highest-priority impacts usually resolves it inside an hour, and a fishbone is faster than argument when several causes are plausibly in play at once.
Size the mitigation to the risk
The second failure is proportionality. A register where every impact receives a briefing and an e-learning module has not prioritised anything — it has distributed the same small intervention evenly across problems of wildly different size.
Tie the dose to the quadrant the impact landed in when you prioritised by severity and adoption risk:
- Intervene — designed intervention with rehearsal, manager involvement and measured verification. Days of effort, not hours.
- Support — targeted and small: a conversation, a job aid, some practice for a specific group. Cheap, and the most commonly skipped.
- Verify — no intervention yet. Test whether the confidence is real, then decide.
- Inform — communicate once, clearly, and stop.
Writing the dose next to the action makes over-servicing visible, and over-servicing the easy rows is how change teams run out of capacity before reaching the hard ones.
Write the action so somebody can start it
“Strengthen manager reinforcement for AP clerks” is a direction, not an action. Nobody can begin it on Tuesday and nobody can tell whether it happened.
A usable mitigation names the trigger, the actor and the first move: “In the Monday AP huddle, the team leader reviews the previous week’s coding exceptions and names one recurring cause to fix.” Same intent, but it has a time, a place and somebody who does it — the specificity that separates a plan from an intention, covered in more depth in building a 30/60/90-day action plan.
Two fields keep it honest afterwards. Evidence of done is the observable state the action was meant to produce, never the activity itself — “coding error rate under 3%”, not “huddle format updated.” Residual risk records what remains once the action is complete, because plenty of impacts cannot be fully mitigated before go-live and saying so is more useful than a green status. Residual risk is what hypercare should be sized against.
Who does the mitigating
One structural point that determines whether any of this converts.
Look back at the mitigation table. Fixing upstream data, changing a performance measure, reallocating a decision right, closing an old channel — the change team owns none of those. They belong to process owners, line managers and sponsors.
Which means a register whose owners are all change-team members has quietly filtered itself down to the mitigations the change team can perform alone, and those are mostly training and communications. The composition of the owner column is a diagnostic in its own right: if no line manager or process owner appears in it, the register is not describing your organisation’s adoption problem — it is describing your change team’s workload.
Mitigations that sit with the business also need to survive project closure, which is why they belong in a live register rather than a separate plan — the argument set out in full in why the change register and mitigation plan should be one document.
The conversion, in one line
An impact assessment becomes a mitigation plan when every row can answer four questions: why will this be hard, which condition is missing, what specifically will somebody do, and how will we know it worked?
Rows that cannot answer the second question end up with training regardless of cause. Rows that cannot answer the fourth close on activity and leave the impact untouched.
Neither failure is visible in a status report, which is why both are so common — and why the register can look complete right up to the point where the thing it was supposed to prevent happens anyway.
For the fields underneath this, see what a change impact register should track; for finding the impacts in the first place, how to identify what really changes for users. The Change Impact & Mitigation Register keeps impacts, causes, actions and owners in one place.
For the end-to-end process this step sits at the end of, see how to run a change impact assessment before go-live.