What is ‘Root Cause Analysis’ In ISO 9001 Standards?
Suppose you come across a dandelion weed while in your garden. (If you have as little time in the garden as I do, at times you may find too many!) You pull off the head of the dandelion and all the leaves. There – you can’t see it any more.
The question is: does this fix the problem?
To illustrate, let me share some findings from an audit in a type of courier company. They collect & deliver items for their customers, and have contracts with large customers. If any customer complaints arise, the operations manager must respond in writing.
For audit, I chose a sample of complaints from the last 3 months and looked at what they’d done with them. Most complaints were for late/missed pick-ups or deliveries.
Some sample responses from the manager to the client:
A. This route has too many sites on it, we are looking at changing it.’
B. ‘The entry disappeared from the system. It was re-entered, and the pick-up went ahead the next day.’
C. ‘The driver was new and didn’t know. He has been spoken to.’ (A week later, the same driver missed another pick-up for the same customer.) ‘He no longer works for us.’
D. ‘I can only assume this happened while I was on leave, and the supervisor didn’t know he had to respond to your calls urgently.’
And my favourite E: ‘The driver was late because there were delays during the day.’
These responses are typical of just looking at symptoms: pulling off the dandelion leaves. That approach leaves the root of the problem still intact. Like the dandelion, you can pretty much bank on the fact that it’s going to come up again. And again. And again. Until you do something to find the real cause (or causes). That’s effective root cause analysis, because you get to the root: the real underlying cause.
For example: Why does a route have ‘too many sites’ on it? What does ‘looking at changing it’ mean? Has it been done? If it was changed, did the changes work? If not, when will it be done? How did that route get ‘too many sites’ on it? And what would stop that happening again, or on another route?
Consider the ‘new’ driver: Why didn’t he know what to do? Had he received the information he needed such as induction and training? If not, why not? Why is ’speaking to’ a driver adequate to prevent recurrence? (it’s not) Has the company reviewed how it selects its drivers? Because the recurrence a week is a strong sign of inadequate cause analysis and ineffective corrective action.
Why Find the Root Cause?
Most organisations are busy and somewhat chaotic. Immediacy often rules. So there’s often a tendency to go for the quick fix – treat the symptom rather than the real, underlying cause. The driver is ’spoken to’, the order ‘re-entered into the system’. But this almost guarantees the same or very similar situation will recur, and have to be dealt with again. And again.
When problems come up in your organisation – which they will – you can choose how to respond. You can look for someone to blame and stop at the symptom (’the driver was new… the supervisor didn’t know… it disappeared from the system’). Quite apart from the damage it causes to personnel relations, this approach isn’t effective.
An organisation with an intelligent approach to quality knows the value of a systematic approach to problems, including root cause analysis. The best question is: What can we learn from this situation? And then: How can we apply that learning to improve?
When Should You Use Root Cause Analysis?
If you have or aspire to ISO 9001, you must have a systematic approach to problems: nonconformance, corrective and preventive action. Without it, you’ll find it hard to pick problems for root cause analysis, because they’re often distributed over time (so you don’t realize they recur), or happen to different people (so you don’t realise they recur in your organisation).
Good candidates for root cause analysis are the situations that recur most often, and use the most resources to rectify or those that cause the most damage when they do.
Remove the Root Cause or Not?
After you’ve identified the root cause/s, you have to decide if it’s worth removing the root cause or whether you continue to treat the symptoms. This isn’t always an easy decision.
It’s often relatively easy to estimate the cost of removing the root cause, but less easy to assess the cost of not doing so. Suppose, for example, a truck breakdown turns out to have been caused by ineffective maintenance by a supplier. And suppose that supplier costs $10,000 less per year than the other. Superficially, the cost vs savings looks good.
But suppose that also means a truck off the road for at least an extra 5 days a year – and your largest customer got so angry about one too many crucial but failed pick-ups that they don’t renew your contract. And tell everyone what an unreliable company you are.
