Cause Analysis

“Root cause analysis (RCA) is a methodology for finding and correcting the most important reasons for performance problems. It differs from troubleshooting and problem-solving in that these disciplines typically seek solutions to specific difficulties, whereas RCA is directed at underlying issues.

  • As a business process improvement tool, RCA seeks out unnecessary constraints as well as inadequate controls.
  • In safety and risk management, it looks for both unrecognized hazards and broken or missing barriers.
  • It helps target CAPA (corrective action and preventive action) efforts at the points of most leverage.
  • RCA is an essential ingredient in pointing organizational change efforts in the right direction.
  • Finally, it is probably the only way to find the core issues contributing to your toughest problems.

… If you want your problems to go away, your best option is to kill them at the root.” - Bill Wilson

The purpose of root cause analysis is not to fix a specific product failure, but to support QMS improvement, by identifying the gap in the system that allowed single or repeat issues to happen. The bigger the organization, typically the greater the capacity for data collection and data analysis, but regardless of company size, these 5 simple concepts are functional at every level, to support your 8-D, DMAIC, or simple improvement process.

1. Team:

Cross-functional Quality Improvement Teams are vital to organizational health. Without a cross-functional team to analyze cause, there is limited likelihood of an effective solution. Never make one person responsible for doing root cause analysis in a silo. Either they burn out, or the team responsible doesn’t own the solution because those involved in the issue need to walk through the evaluation. Asking the person who manages the team that made the mistake to identify contributing causes, is almost guaranteed to be ineffective since they are too close to the situation. However, input from only external eyes will miss elements that those directly involved may be aware of – so mix it up.

2. Fishbone:

Using the Ishikawa Fishbone tool shifts focus from the single person or department where the error occurred, and to look at the myriad of activities that contribute to any one activity. (For those who doubt this, try describing in detail the process to have flowers delivered to a friend – when you break it down fully it’s well over 100 activities).

Evaluate if anything within each of the 6 major inputs had any contributing impact on the issue:

  • Manpower (staff, training, competence evaluation, culture, language, responsibility, authority).
  • Method (process inputs/outputs defined, instruction clarity, order of activities, communication).
  • Material (process inputs whether information or physical material, supply chain control).
  • Machine (equipment selection, capability, maintenance, fitness for purpose, capacity, scheduling).
  • Measurement (test, inspection, monitoring validation, and the tools to do it).
  • Environment (Physical – space/temp/humidity/noise/technology. Social – cooperative/teamwork/communication/isolation. Psychological – supportive/collaborative/stressful/hostile).

Once all contributing causes are identified, select those with the highest risk of recurrence or impact, and investigate the root cause each exists.

3. 4W1H:

If you find the team struggling with the fishbone, try this, and keep asking What else?

  • Who (see Manpower above).
  • What (see Material, Machine, and Measurement above).
  • Where (see Environment above).
  • When (consider timing or time pressures, lighting, noise, humidity).
  • How (see Method above) – either way, your goal is to achieve a holistic view of the issue.

4. The 5 Why's

Remember to keep the focus on why the system failed, NOT the person. This tool only works to investigate ONE cause. It is of no use if the team simply lists identify 5 unrelated causes. So keep asking Why is that?

  • Why 1: Define the error. Define the suspected immediate cause.
  • Why 2: Define why the immediate cause happened.
  • Why 3: Define why the contributing cause happened.
  • Why 4: Define why the supporting cause happened.
  • Why 5: Define why the hidden cause happened.

5. The 3 x 5 Whys:

When there are multiple contributing causes, consider picking three of them and doing 3x5-whys, using the 5 whys tool for each input. The steps are the same as above. Either method, remember, you are diving past the obvious to find the system weakness.

THE GOAL of any good root cause analysis is to get past ‘oops’, blame, justification, and finger-pointing, so that the team finds the gap in the system tools, information, resources, or structure, with the result of the gap being closed effectively and permanently.

You will know that you have a good root cause when you can state it in one sentence and it clearly points to the ‘needed change to prevent recurrence’(ISO calls this a corrective action). Conversely, you will know if the root cause analysis was weak, if the corrective action is implemented and the issue recurs!

To make this a useful part of a culture of improvement remember to

  • Have fun! Brainstorm with those involved, to get past the obvious.
  • Recognize those who contribute thought or effort to the process.
  • Share successes – brag on those whose improvements reduce waste.

“If I only had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” --Einstein