By Ritvars Mētra, Founder of ReadinessCompassAdoption problems rarely have one cause. A team using the new system half as much as expected is usually experiencing four things at once, each individually survivable and collectively decisive.
That is the situation a fishbone diagram is built for, and it is where sequential questioning falls short — a 5 Whys chain produces one line of causation and can create false confidence that you have found the cause rather than a cause.
The standard categories do not fit
Kaoru Ishikawa developed the cause-and-effect diagram for quality problems in manufacturing, and the categories that came with it — machine, method, material, manpower, measurement, environment — reflect that origin.
Applied unaltered to an adoption problem they produce an awkward result. “Manpower” becomes a bin for everything about people, which is the entire subject, and the categories that would actually discriminate are missing. The structure is right; the labels need replacing.
Six branches that discriminate
| Branch | The question | Typical causes |
|---|---|---|
| System | Does the tool support the task? | Missing function, too many steps, performance, no mobile access |
| Process | Is the designed process workable? | Exceptions unhandled, approval friction, sequence that does not match reality |
| Data | Can people trust what they see? | Migration gaps, duplicates, stale records, no ownership |
| Capability | Can people actually do it? | Training on the happy path only, no practice, skills decayed since the course |
| Capacity | Do they have the time? | Concurrent change, seasonal peak, unbackfilled absence |
| Management | Is it reinforced, measured and rewarded? | Old format still accepted, targets unchanged, manager not using it |
These six are worth using because each has a different owner and a different remedy. That is the practical test of a category set: if two branches would be fixed by the same person doing the same thing, they should be one branch.
Note that only one of the six is about individual capability. Most adoption diagrams, drawn without a structure, put almost everything there.
Running the session
- State the effect precisely and behaviourally. “Only 40 per cent of orders are raised in the new system” works. “Poor adoption in sales” does not, because every branch will then be filled with opinions about sales.
- Fill every branch, including the ones that look empty. The discipline of forcing a cause into Capacity or Management is what surfaces the thing nobody wanted to raise.
- Include people who do the work. A diagram drawn by the programme team will be strong on System and Capability and blank on Management, for reasons that have nothing to do with the evidence.
- Mark what is evidenced and what is asserted. Most causes on a first-pass diagram are hypotheses. Distinguishing them is what turns the picture into a plan.
The step people skip
A completed fishbone is not an answer. It is a list of candidates, and its main failure mode is being photographed, circulated and treated as a diagnosis.
The work is what follows: pick the three or four causes that are both plausible and cheap to test, then test them. Most adoption hypotheses can be checked in under a day. Is the credit flag wrong? Open three records. Do people have time? Ask two managers what their teams stopped doing. Can people do the task? Watch four of them attempt it unaided.
After a day of that, the diagram usually collapses from eighteen candidate causes to two real ones — and those two are frequently in Process and Management rather than in Capability, which is where the remedy budget had already been allocated.
If you want to run one, the fishbone root cause analysis guide covers the structure, and the Adoption Risk Hub has related material on diagnosing adoption problems from evidence rather than assumption.