How to Prioritise Change Impacts by Severity and Adoption Risk

You have a scored impact register. Sixty rows, each with a rating. Somebody asks which ones the programme is going to actually do something about.

This is where most impact work stalls, because a scored register does not prioritise itself. Sorting descending by a composite number feels like prioritisation and usually produces a list nobody can act on — too long, dominated by whichever dimension the scoring happened to weight heaviest, and mixing together problems that need completely different responses.

Prioritisation needs two things the register does not give you on its own: the right axes, and an honest view of how much you can actually mitigate.

Severity and adoption risk are different questions

The most useful move is to stop treating impact as one number.

Severity is how much changes. How much of the role is different, how many people, how business-critical the process. It is a property of the change itself and it is largely fixed by design decisions.

Adoption risk is how likely it is that the change fails to stick. Capability gap, manager support, willingness, competing demands, history with previous changes. It is a property of the people receiving the change, and unlike severity it is something change work can genuinely move.

These come apart constantly. A major process redesign landing on an experienced, well-led team that helped design it is high severity and low adoption risk. A modest new approval step landing on a team that has absorbed four changes this year and does not trust the programme is low severity and high adoption risk — and it is the second one that will produce a workaround by week three.

Collapse both into one “impact rating” and those two rows score identically, which is why the ratings so rarely match where trouble actually appears.

The prioritisation grid

Plotted against each other, the two axes produce four groups that need genuinely different responses — not four levels of the same response.

Two quadrants are usually mishandled.

Priority 2 gets skipped because the change looks minor. But a small change landing on a team with a capability gap or no manager support is exactly the sort of thing that produces a permanent workaround — and it is usually cheap to fix, because the intervention is a conversation and some practice rather than a redesign.

Priority 3 gets trusted. A big change with a confident, capable team is genuinely lower risk, but the confidence assessment is often based on what people said rather than what they did. Verify it with observed evidence before standing the effort down — the gap between self-reported confidence and demonstrated capability is precisely what UAT observation exists to expose.

Why the grid is a starting point, not an answer

Worth being honest about this, because grids like the one above are used with more confidence than they deserve.

Tony Cox’s analysis of what is wrong with risk matrices, in Risk Analysis, found that typical matrices can unambiguously compare only a small fraction of randomly selected pairs of hazards, that they suffer from range compression — assigning identical ratings to quantitatively very different risks — and that where frequency and severity are negatively correlated they can produce worse-than-random rankings.

The practical implications for an impact register are three:

• Use the grid to sort into groups, not to rank within them. It is reliable for “this belongs in Priority 1” and unreliable for “this is the third most important item in Priority 1.” Ordering inside a quadrant should come from judgement and the sequencing tests below, not from a decimal place.
• Watch the crowded corner. If most rows land in one quadrant, your bands are wrong, not your programme unusually risky. Re-cut the boundaries until the grid discriminates.
• Keep the components visible. Aggregation lets a strong component compensate for a weak one, which the OECD and European Commission Joint Research Centre handbook on composite indicators treats as a design decision to declare rather than an accident to discover. Never show a composite without its parts. Severity 5 with adoption risk 2 and severity 2 with adoption risk 5 can produce the same product and need opposite responses.

Define the bands numerically

“High,” “medium” and “low” feel precise and are not.

Research on verbal probability expressions consistently finds large variation between people in the numbers they attach to the same words, with disagreement widest in the middle of the range and narrowest at the extremes. Two assessors using the same word are frequently not describing the same thing, and the effect is worst for exactly the mid-range judgements an impact register is full of.

The fix is cheap: attach an observable definition to each band, and prefer counts over adjectives.

Band	Severity — defined as	Adoption risk — defined as
High	Core daily task changes, or the role’s outputs change	Capability gap and weak manager reinforcement, or a prior failed change
Medium	Same task, materially different method or system	Capability gap or weak reinforcement, not both
Low	Same task and method, cosmetic or occasional difference	Capable, supported, and involved in the design

Definitions like these will not survive first contact unchanged, and that is the point — the argument about where a row belongs is a useful argument, and it only happens if the bands are written down.

What actually sets the sequence

The grid tells you what matters. It does not tell you what to do first, and those are different questions.

Four tests set the order within a priority group:

• Window of influence. Some impacts can only be mitigated before a design freeze or a build cut-off. After that the option is gone and the mitigation becomes a workaround. These go first regardless of score.
• Lead time. A mitigation needing eight weeks and one needing two days have different start dates even at identical priority.
• Dependency. Some mitigations cannot work until another is done — there is no point rehearsing a process that has not been finalised.
• Cost of delay. What does waiting a month actually cost? Frequently nothing, and admitting that frees capacity for the rows where it costs a great deal.

Window of influence is the one most often missed. An impact that is Priority 2 but whose only mitigation window closes next Friday outranks a Priority 1 that can be addressed any time in the next quarter.

Prioritisation means deciding what to drop

This is the part that gets avoided, and without it the exercise is decorative.

A register with sixty impacts and a change team of two has a capacity constraint, and pretending otherwise produces sixty half-mitigations instead of twelve real ones. The output of prioritisation is not a ranked list — it is a line drawn across the ranked list, with everything below it explicitly accepted rather than quietly ignored.

Three things make that survivable:

• State the capacity. How many mitigations can actually be run before the gate, given the people you have. Usually far fewer than the register assumes.
• Record accepted risks as accepted, with a named person accepting them. “We are not mitigating this and here is who decided” is a governance position. Silence is not.
• Let the sponsor draw the line. Prioritisation is a governance act, not an analytical one. The analysis produces the ordering; deciding where the resourcing stops is a decision about risk appetite, and it belongs with whoever owns the outcome.

Accepted impacts do not disappear. They should carry into hypercare planning as known exposure, and into handover as residual risk with a business owner — which is how they avoid becoming the mechanism by which benefits leak after go-live.

The short version

Score severity and adoption risk separately, because change work can move one of them and not the other. Use the grid to sort into four groups with different responses, not to rank to two decimal places. Define the bands with observable criteria so two assessors mean the same thing. Sequence within groups by window of influence and lead time rather than by score. Then draw a line, name what falls below it, and have somebody senior accept it.

The test of a prioritisation exercise is not whether the ranking looks rigorous. It is whether the change team is now working on fewer things.

For the fields this depends on, see what a change impact register should track and why, and the Change Impact & Mitigation Register for a working implementation with scoring built in. Impacts you consciously accept belong in the transformation RAID log, and the mitigations you do commit to belong in a 30/60/90-day plan with owners and dates.

For where prioritisation sits in the wider sequence, see how to run a change impact assessment before go-live.