By Ritvars Mētra, Founder of ReadinessCompassThe impact assessment workshop runs for three hours. Process owners, a future-state slide, a facilitator with a template. Somebody writes: “Finance will use a new posting screen and a revised approval workflow.”
Six months later, finance discovers that a third of month-end involves reconciliations, adjustments and chasing that appear nowhere in the new design, and that the person who used to hold it together did so with a spreadsheet and twenty years of knowing which numbers to distrust.
Nobody lied in that workshop. The process owners described the process accurately. The problem is that the process is not the job.
The documented process is not the work
Safety science has the cleanest language for this. Erik Hollnagel’s distinction between work-as-imagined and work-as-done, set out in his Safety-I to Safety-II white paper, describes work-as-imagined as an idealised view of the formal task environment that disregards how performance must be adjusted to constantly changing conditions. Work-as-done is what actually happens.
The gap between them is not sloppiness or non-compliance. It exists because formal descriptions necessarily leave out the adjustments that make work function when the data is late, the customer is unusual, the system is slow and the deadline is today. Those adjustments are the job in most operational roles.
Which produces the central problem of role impact assessment: an assessment built from process documentation measures the impact on a job nobody actually does. It will be internally consistent, well presented, and wrong in the specific places that determine whether adoption holds.
Why asking does not fix it
The obvious remedy is to interview the people doing the work. Necessary, and not sufficient.
Michael Polanyi’s observation in The Tacit Dimension — that we can know more than we can tell — is the reason. A great deal of operational expertise is tacit: learned through experience, internalised, and difficult to put into words. The more experienced someone is, the more of their decision-making has compressed into pattern recognition they no longer consciously step through.
So ask an experienced person “what do you do?” and you will usually get the standard path, described cleanly, with the judgement stripped out — because the judgement is the part they cannot see themselves doing. You have obtained work-as-imagined from the person actually performing work-as-done.
This is why the method matters more than the template. You are not collecting descriptions. You are trying to surface something the holder cannot readily articulate.
Who to ask
Before method, coverage. Impact assessments are incomplete in consistent directions.
- The person doing it now, not the manager and not the subject-matter expert who left the floor five years ago. Both will describe the process. Only the first can describe the work.
- More than one person per role. Two people in the same job frequently do it differently, and the difference is itself a finding about how much the process is really standardised.
- Upstream data providers. People who feed the process without using the system are the most commonly omitted group and the most reliable source of post-go-live data problems.
- Occasional and periodic roles — month-end only, year-end only, the deputy who covers holidays. Their work is invisible in a normal-week assessment and disproportionately likely to break.
- Night shift, other sites, third parties. Different constraints produce genuinely different work-as-done for the same nominal role.
Record who you did not reach as explicitly as what you found. Uncovered roles are untested adoption risk, and they should appear in the register as such rather than as blanks.
Five methods that surface work-as-done
In rough order of how much they reveal per hour spent.
1. Watch someone do it
Sit beside a person doing a real transaction with real data. Say almost nothing. Note every point where they leave the system, check something elsewhere, hesitate, or make a decision that was not in any process document.
Ninety minutes of this typically produces more usable impact detail than a full-day workshop, because it bypasses the articulation problem entirely. You are observing the tacit part rather than asking for it.
2. Walk through the last real case
Where observation is impractical, anchor to a specific instance: “Open the last one you did. Talk me through what you actually did with that one.”
A specific case recruits memory rather than self-description, and the differences from the generic account come out unprompted — “normally you would just post it, but this supplier always sends the reference in the wrong field, so…”
3. Hunt the exceptions
The standard path is documented; the role lives in the exceptions. Ask directly:
- When does this not work?
- What was the last one that went wrong, and what did you do?
- Roughly what share of cases are not straightforward?
- Who do you go to when you are unsure?
That last question maps informal expertise networks, which usually turn out to run through two or three people the programme has never spoken to — the pattern behind expert overload after go-live.
4. Ask about the workarounds
Existing workarounds are the most direct evidence of work-as-done available, because a workaround exists precisely where the sanctioned path did not fit the work.
Steven Alter’s Theory of Workarounds frames them as goal-driven adaptations created to overcome an obstacle in the system as the user experiences it. Each spreadsheet, side list and personal tracker is therefore a labelled description of a gap — and if the new design does not account for it, the workaround will simply reappear, which is how users end up back in Excel after go-live.
Ask without judgement, and say plainly that nothing will be taken away because they mentioned it. You get one chance at that promise.
5. Yesterday and tomorrow, across all ten aspects
Finally, structure what you found. Prosci’s framework for defining change impact lists ten aspects a change can alter: processes, systems, tools, job roles, critical behaviours, mindsets and beliefs, reporting structure, performance reviews, compensation, and location.
Run each affected role against all ten with two columns — today, and after. Most assessments cover the first three or four and stop, which is why they miss the impacts that actually block adoption: the behaviour that the new process requires but the current performance review penalises, or the reporting line that has to change and has not been agreed.
Questions that work, and questions that do not
| Instead of | Ask | Why |
|---|---|---|
| What is your process? | Walk me through the last one you did. | Recruits memory of a real case instead of a general description |
| How long does this take? | What takes longer than it should, and why? | Surfaces friction rather than an average |
| Do you use the system for this? | What do you have open while you do this? | Reveals the spreadsheets and side tools without asking about compliance |
| Is the process well documented? | What would a new starter get wrong in week one? | Extracts tacit knowledge by making it someone else’s gap |
| Any concerns about the change? | What part of your job do you think they have not seen? | Invites the omission rather than an opinion |
| Will this work for you? | What would have to be true for this to work on a bad day? | Tests against real conditions, not the happy path |
The fourth is the highest-yield question in the set. People who cannot describe their own expertise can almost always describe what a novice would get wrong, and that answer is a direct map of the tacit knowledge the change is about to disrupt.
What you are listening for
Five things predict adoption difficulty better than anything a process map contains.
- Judgement calls. Where the person decides rather than follows. If the new design assumes a rule where there is currently judgement, expect either resistance or bad data.
- Exception frequency. If a third of cases are non-standard, a system that handles the standard case beautifully will not feel like an improvement.
- Informal coordination. The phone call, the corridor check, the message to a colleague before committing. This work is real, unrecorded, and often designed out by accident.
- Tools outside the system. Every one is an unmet requirement in the current state and a predicted workaround in the future state.
- What they are proud of. Ask what makes someone good at this job. If the new way removes that — the judgement, the relationship, the catch-it-before-it-goes-wrong — you have found the real source of resistance, and it is not irrational.
Turning it into register rows
Findings become useful when they convert into specific from-to statements at role level, each carrying its own severity and adoption-risk judgement.
“Finance will use a new posting screen” becomes several rows. Today the AP clerk judges which cost centre an ambiguous invoice belongs to, using supplier history; tomorrow the field is mandatory at entry and the judgement moves upstream to the requisitioner, who has not been told. That row names an affected role, a real change, a capability gap and a dependency — and it can be scored, owned and mitigated.
Those rows feed straight into the fields covered in what a change impact register should track, and the severity and adoption-risk judgements you formed while observing are exactly the inputs needed to prioritise impacts afterwards.
The check worth running
Take your current impact assessment to one person who does the job and ask a single question: “What have we missed?”
If the answer is nothing, you probably asked a manager. If the answer takes twenty minutes, the assessment was built from work-as-imagined, and you now have the beginning of the version that is actually about their job.
It is a cheap check, and it is the difference between an impact assessment that predicts where adoption will struggle and one that describes a process.
To capture what you find, the Change Impact & Mitigation Register holds role-level impacts with scoring, owners and due dates. For testing whether people can actually perform the new work before go-live rather than only assessing what changes, see how UAT reveals adoption risk.
For the process around this — timing against the design freeze, scope, coverage and completion criteria — see how to run a change impact assessment before go-live.