By Ritvars Mētra, Founder of ReadinessCompassMost change impact assessments are run too late, by too few people, at the wrong depth — and produce a document rather than a decision.
The individual techniques are well covered. What is usually missing is the process around them: when to start, how wide to go, who needs to be in the room, how long it actually takes, and how you know it is finished.
This is that process, end to end.
Time it against the design freeze, not go-live
The single most consequential decision is when the assessment completes, and almost everyone anchors it to the wrong date.
An impact assessment finished before the design freezes can change the design. One finished after it can only produce mitigations for a design that is now fixed. Same analysis, same findings, radically different value — in the first case a badly fitting process gets redesigned, in the second it gets a training course and a workaround.
The economics of this are well established in systems and software engineering. Barry Boehm’s data, reviewed in NASA’s analysis of error cost escalation through the project life cycle, shows the cost of correcting a problem rising steeply the later in the lifecycle it is found — roughly an order of magnitude per phase in the original figures.
Worth being precise, because this idea circulates in a distorted form: the widely reproduced “1:10:100” chart is unsourced, later analyses put the multiplier anywhere from about 5x on small projects to 100x after delivery, and it varies by problem type. The shape of the curve is robust; the exact ratio is not. That is enough for the point at hand, which is directional: a fit problem found during design is cheap, and the same problem found during hypercare is not.
So set the assessment’s completion date relative to the design freeze. If that means starting uncomfortably early with an incomplete picture of the future state, start anyway — a partial assessment that can still influence design beats a complete one that cannot.
Scope: coverage beats depth
The second decision is how much to assess, and the instinct — go deep on the most affected areas — is the wrong way round.
The role you never assessed is a bigger risk than the role you assessed shallowly. A shallow assessment gives you a rough severity and a name to follow up. No assessment gives you a group discovering at go-live that nobody considered them, which is both an adoption problem and a trust problem.
So: full coverage of affected roles first, then depth where severity warrants it. Two practical rules follow.
Build the role inventory before assessing anything. List every role touched, including the ones nobody counts as system users — upstream data providers, occasional approvers, month-end-only participants, night shift, deputies, third parties. That list is the denominator for everything afterwards, and coverage against it is the real completion measure.
Assess to the level you will act at. If mitigation will be designed per role, assess per role. Analysing to individual-task granularity when every action will be taken at role level produces detail nobody uses and burns the time that coverage needed.
Scope also means saying what is out. Declare the roles you are not assessing and why, so partial coverage is a stated decision rather than a silent gap.
Who has to be in the room
An impact assessment run by the change team alone will systematically under-detect, because the change team knows neither the future design in detail nor the current work in practice.
Three perspectives are needed, and the output degrades predictably when any is missing:
- Someone who knows the future design — a solution architect or process designer. Without them the assessment describes changes that are not actually happening.
- Someone doing the work today — not their manager. Without them you get the documented process rather than the real one.
- Someone who can own a mitigation — a process owner or line manager. Without them the assessment produces findings nobody has agreed to act on.
That third one is why impact assessments so often stall at the document stage. If nobody in the room can commit to doing anything, the output is a description.
The five steps
Each has its own method; the sequence is what makes them add up.
1. Inventory the roles. As above — coverage first, including the non-obvious groups. Half a day with an org chart and someone who knows the operation.
2. Find what actually changes. Not from process documentation. Observe people doing the work, walk through real recent cases, and hunt the exceptions, because documented process is work-as-imagined and the exceptions are where the role lives. The methods for this — and the reason interviews alone under-detect — are in how to identify what really changes for users. Run each role against the full set of impact aspects, not just systems and processes: Prosci’s framework for defining change impact lists ten, including behaviours, reporting lines, performance measures and compensation, and the last six are where adoption usually fails.
3. Record it in a form you can act on. One row per impact, written as a specific from-to statement, with severity, capability gap and reach captured separately rather than collapsed into a single rating. The fields and why each one earns its place are in what a change impact register should track.
4. Prioritise. Severity and adoption risk are different axes, and a scored list is not a prioritised one — sequencing depends on window of influence and lead time as much as on score. Covered in how to prioritise change impacts.
5. Design mitigation against the cause. The step that determines whether any of it converts. An impact’s mitigation depends on why it will be hard — capability, opportunity or motivation — and defaulting to training and communications for all three is the standard failure. See from impact assessment to mitigation plan.
Keep impacts and mitigations in one artefact rather than two. A separate mitigation plan breaks the link between problem and response almost immediately — the argument in why the register and mitigation plan should be one document.
What it actually costs
Impact assessments get compressed because nobody has given planners a number. A workable estimate:
| Activity | Effort |
|---|---|
| Role inventory and scoping | Half a day, once |
| Per role: observation or case walkthrough | 60–90 minutes |
| Per role: writing up rows and scoring | 30–45 minutes |
| Validation session per function | 90 minutes |
| Prioritisation workshop | Half a day, once |
For twenty-five affected roles that is roughly ten to twelve person-days of assessment, plus validation and prioritisation — realistically three to four elapsed weeks with two people working part-time on it.
That number is worth stating early, because the alternative is an assessment squeezed into a fortnight, which forces the depth-over-coverage trade in the wrong direction and produces exactly the gaps that surface later.
How you know it is finished
Not by row count. A four-hundred-line register is a database, and volume is frequently a sign that the assessment was run at the wrong granularity.
Define completion criteria in advance, the way a stage gate does — agreed before the work starts, so “done” is not negotiated under schedule pressure. Four criteria work well:
- Coverage: every role on the inventory is either assessed or explicitly declared out of scope with a reason.
- Specificity: every high-severity impact is written as a from-to statement a non-expert could act on.
- Ownership: every high-priority impact has a named person, not a function, who has accepted it.
- Validation: the affected groups have seen their own rows and had the chance to say what is missing.
That last one is the cheapest quality check available and the most commonly skipped. Show a team their impacts and ask what has been missed; twenty minutes will tell you whether the assessment describes their job or a version of it.
It is not a one-off
The assessment is usually treated as a design-phase deliverable, signed off and archived. But new impacts keep surfacing, and the two richest sources come later.
UAT is the first time real users do real work in the real system, and it reliably exposes impacts the assessment missed — particularly around exceptions. That is one reason UAT is a people-readiness instrument and not only a testing one.
Hypercare is the second, when people meet the cases nobody rehearsed. Impacts discovered then still need recording, owning and closing, and a register that stopped at go-live has nowhere to put them.
Five ways the process fails
- Run after the design freeze, so every finding becomes a mitigation rather than a fix.
- Run by the change team alone, producing a description of the process rather than of the work.
- Depth prioritised over coverage, so the unassessed roles surface at go-live.
- Built from documentation rather than observation, missing the exceptions where adoption actually breaks.
- Closed at go-live, with no home for the impacts that hypercare reveals.
The short version
Start early enough that the findings can still change the design. Cover every affected role before going deep on any. Put a designer, a practitioner and a mitigation owner in the room. Observe rather than document. Record, prioritise and mitigate in one live artefact. Define what finished means before you start, and keep it open through hypercare.
The test of an impact assessment is not whether it was completed. It is whether anything was designed differently because of it.
Impacts that cannot be mitigated before go-live have to be carried, and carried risk needs to be visible to delivery governance. Writing people risk into the RAID log properly — with a threshold, a date and an operational consequence — is what stops it sitting permanently amber.
For how impact assessment differs from complexity assessment, see similar names, very different questions. To run the register itself, the Change Impact & Mitigation Register holds impacts, scoring, owners and mitigations in one place with a downloadable template.