Root Cause Analysis for Adoption Problems: 5 Whys in Practice

Six weeks after go-live, order entry is taking roughly twice as long as it did on the legacy system. The steering committee has been told that users need more training.

That is a conclusion, not a diagnosis, and it has the useful property of pointing away from anything the programme would have to fix.

The technique, and what it is for

The 5 Whys came out of the Toyota Production System, where Taiichi Ohno used repeated questioning to push past the first plausible explanation of a fault toward something that could actually be changed. It is deliberately unsophisticated: state the problem, ask why, take the answer, ask why again.

Its value in adoption work is specific. Adoption problems attract explanations that are socially comfortable and operationally useless — resistance, insufficient training, poor communication. Each is a stopping point that closes the enquiry. The discipline of asking why one more time is what gets past them.

A worked example

“Users need more training” would have produced a training session. The actual finding is a data scope gap, and the fix is to migrate the overrides and tell the clerks it has been done — which is a fortnight of latency rather than a permanent 50 per cent productivity loss.

Notice also what the chain reveals about trust. The behaviour persisted after the data was wrong once. That is how a data problem becomes an adoption problem, and no amount of training addresses it.

Where the technique misleads

It is worth being honest about the limits, because 5 Whys is often used with more confidence than it deserves.

• It produces one chain. Real adoption problems usually have several contributing causes operating at once. The technique gives you a single line and can create false confidence that you have found the cause.
• It is only as good as the room. Ask five managers and you get a chain about users; ask five clerks and you get a chain about the system. Neither is complete.
• There is no verification step. Nothing in the method requires evidence for any link. Each “why” is an assertion until someone checks it.
• It stops where the room is comfortable. Chains reliably terminate just before anything a senior person present would have to own.

Two corrections handle most of this. Run it with the people who do the work, not the people who manage it. And after each link, ask what evidence supports it — the credit block example is checkable in five minutes by opening three customer records, and a chain nobody verified is a story.

Where multiple causes are plausible, the single-chain limitation becomes the binding one, and a fishbone diagram is the better instrument because it holds several branches at once.

Running it well on an adoption problem

• State the problem behaviourally. “Order entry takes twice as long”, not “users are struggling”. A vague problem statement produces a vague chain.
• Ban the word resistance. If it appears, ask what the person is actually doing instead, and continue from there.
• Follow behaviour, not attitude. “They do not trust the flag” is useful because it points at something checkable. “They are not engaged” is not.
• Stop when you reach something you can change. Five is a guideline. Sometimes it is three; occasionally seven.
• Write the chain down and circulate it. Someone will correct a link, which is the point.

Used this way it takes about twenty minutes and routinely changes what a programme does next. Used as a workshop ritual with the wrong people in the room, it produces a well-formatted route back to more training.

Where several causes are plausible at once, the single-chain limitation binds. A fishbone diagram with adoption-specific branches holds them side by side and makes the empty categories visible.

If you want to run one, the 5 Why root cause analysis guide walks through the structure, and the Adoption Risk Hub has related material on diagnosing what is actually stopping people.