#234 Finding The Root Cause In ISO Management

Continual Improvement is at the heart of ISO Management, a large part of which is dedicated to ensuring issues don’t reoccur. This is more than just putting a plaster on it and calling it a day, it’s about finding the root cause.

This not only eliminates wasted time, effort and money with firefighting repeated mistakes, but also drives meaningful improvement. Over the years, many techniques have been developed to help with finding cause.

In this episode, Ian Battersby explores the need to find the root cause of issues in ISO Management and explains some key techniques for root cause analysis that you can put into practice to help stop recurring issues.  

You’ll learn

·      What is meant by ‘finding cause’?

·      Why do you need to find the cause?

·      Where is finding cause specified in ISO Standards?

·      Finding cause in practice

·      What are the 5 Why’s?

·      What is the fish bone / Ishikawa?

·      What is FMEA?

·      What is fault tree analysis?

·      How do these techniques work in practice?

 

Resources

·      Isologyhub

 

In this episode, we talk about:

[02:05] Episode Summary – Ian dives into finding cause within ISO Management, explaining various techniques to help you prevent recurring issues.

[03:15] What is meant by ‘Finding cause’? When an output from a process is not what was expected, then it is classed as a non-conformity which will need to be addressed through corrective action.

Before you can put that action into place, you need to identify the root cause for the issue. It’s about putting right what went wrong.

[04:00] Why do you need to find cause? Ian gives an example of a reactive response to resolving an issue, it didn’t get to the root of why the mistake happened in the first place.  

Finding cause is necessary to stop issues from repeating, rather than simply firefighting issues as they occur.

ISO terminology has updated to reflect this over the years. There used to be a term called ‘Preventive action’, but this has since been changed to ‘Corrective action’ following on from the 2015 Annex SL update to many ISO Standards. This reflects the new risk-based approach to ISO management.

The terms are largely the same in nature, but preventive action was widely misunderstood and so this was renamed and clarified following 2015.

[05:55] Where is finding cause specified in ISO Standards? As with many aspects of ISO, the need for finding cause can be found in a few places within a Standard, including: -

Clause 6.1.1 Planning: It specifies the need to determine risks and opportunities that need to be addressed. This is because they will affect the desired outcome of your Management System. It’s also a good place to start thinking about how to reduce those risks.

Evaluating your strengths and weaknesses also gives you the chance to contemplate whether your existing processes are good at delivering what you want.

Clause 10 Improvement: The Standard states something to the effect of ‘the organisation shall determine and select opportunities for improvement and implement any necessary actions to address those opportunities’

These opportunities will focus on improving products and services, which includes correcting, preventing or reducing undesired results.

Also included under clause 10 is a subclause that directly addresses non-conformities and corrective action. These specify not only the need to resolve issues as they arise, but to evaluate the need for action to eliminate the root cause.

Additional requirements include the need to review these actions and determine if they are actually effective. Ian goes into Clause 10 in more detail in a previous podcast specifically looking at opportunities for improvement.

[14:20] Finding cause in practice – Why a methodology is necessary: Ian provides an example where an employee may lack confidence completing a certain activity. Their lack of competence could lead to a process being delivered incorrectly.

That adverse quality outcome would then likely end up with the customer who would raise a complaint, in this instance that could be a damaged product. The damaged product is what needs correcting, from your perspective you would be looking at what caused that to prevent recurrence. Without knowing the initial cause, you would need to determine whether it’s a production issue or a human error.

These types of scenarios can branch out further than the initial quality issue. For example, if that damaged product causes harm, then it turns into a health & safety risk. If products need to be scrapped, then there’s an environmental factor.

Complaints related to product quality may also not be recorded in a standard non-conformity system, and could easily be missed for a full investigation to find root cause.

This is why it’s important to have a consistent approach, in both logging issues and evaluating them to determine cause.

[18:10] What are the 5 Why’s? This is one of the more popular methods that people use to determine cause. It’s simply a case of asking why a scenario happened, usually 5 times, though you can ask more or less depending on how long it takes to reach the core issue.

It doesn’t require much training and all it requires is an open and honest response to the questions. This method can get answers quickly and is often utilised as an early problem solving technique.

[19:30] What is the fish bone / Ishikawa? This is a more visual method to find cause. Depicting a fish skeleton that categorises possible causes and groups these accordingly.

These causes are then discussed for a few minutes, typically with teams of people in order to gain different perspectives to help pull apart complex problems into their contributing factors.

This method is particularly useful in cases where there isn’t a single underlying cause.

[20:30] What is FMEA? FMEA or Failure Modes and Effects Analysis is a more structured technique and acts like a risk assessment in reverse.

It looks at what can go wrong, what the effect of failure is and then how critical that failure is to the outcome of what you're trying to do. It uses risk priorities to decide what’s more important.

[21:15] What is Fault Tree Analysis? This method utilises a top-down logical approach. It’s a diagrammatic representation of what’s going wrong.

It asks, does this happen? Yes or no or both, and branches down paths that explore the issue. It allows for quantitative measures with a number output that can help determine how likely recurrence will be.  

It’s a method that is often used in engineering and manufacturing processes.

[22:55] Scatter Diagrams:  Scatter diagrams are a good tool to find correlation. They help visualise the relationship between two variables. If you have data rich environments, these can really help you plot out those relationships and make those links that otherwise may have been missed.

[23:40] The 5 Why’s in more detail:  The 5 Why’s is a great starting technique as it requires little training. Ian provides an example of using the 5 Why’s, with the scenario of a worker who has injured themselves while cutting some wood.

Using the 5 Why’s, he asks these questions:

·      Why did the workers hand slip while cutting the wood? – They were holding the material in one had without the use of any clamping device to keep it steady.

·      Why was the material being held by hand instead of using a clamp? Because there was no clamping device available.

·      Why was there no clamping device available on the table? The design of that workstation didn’t take into consideration the need for a permanent clamping fixture.

·      Why wasn’t that taken into consideration for the workstation? The risk assessment for that workstation was overlooked.

From this exercise, you can see how you can get to the root of an issue by simply asking ‘Why’ a number of times. Again, it can be more or less than 5 times, the name is simply a guideline.

[25:40] The Fishbone / Ishikawa method in more detail: Another favoured simple technique for finding cause is the fishbone method. It utilises 6 categories to get to the root of an issue, those being:-

·      Machine: Addressing the equipment or technology that you use to deliver products and services.

·      Method: The way in which you deliver products and services.

·      Material: The raw inputs into your processes.

·      Measurement: The data and metrics that you use to monitor the successful delivery of your products and services.

·      Mother Nature: The environment and conditions in which you’re operating. 

·      Man – Although this has now been updated to ‘People’, addresses the human element of product and service delivery.

This is a great method for instances where there may be multiple root issues, so you can categorise and analyse each of them with multiple perspectives involved as this is considered a more collaborative method for root cause.

[28:15] Record your findings: We dive more into this in a previous episode, but essentially, it’s a requirement of every ISO Standard to address these non-conformities as they occur. Going through the process of root cause and rectifying the issue will need documentation to prove that you are actively addressing these issues, as well as doing as much as you can to prevent recurrence.  

There is no defined way to do this in the Standard, so it can be documented via forms, intranets, other digital systems etc.

Documenting all the evidence of resolving issues may seem arduous at times, but it will ultimately lead to genuine continual improvement, and will lead to reduced overall error.

 

If you’d like any assistance with ISO Implementation or support, get in touch with us, we’d be happy to help.

We’d love to hear your views and comments about the ISO Show, here’s how:

●     Share the ISO Show on Twitter or Linkedin

●     Leave an honest review on iTunes or Soundcloud. Your ratings and reviews really help and we read each one.

Subscribe to keep up-to-date with our latest episodes:

Stitcher | Spotify | YouTube |iTunes | Soundcloud | Mailing List