Matthew Barsalou, Researcher at Poznan University of Technology

Title: Ishikawa Diagrams: Criticisms, Solutions, & Advice



This talk discusses Ishikawa diagrams. Although a basic quality tool, their use can still be expanded upon. First, criticisms of Ishikawa diagrams will be discussed and refuted. One common accusation is that they are based on guessing; this is an oversimplification as a good Ishikawa diagram should be based on the available evidence and subject matter expert’s knowledge and experience.

Various ways of using Ishikawa diagrams will be explained with various approaches to branch labels and overall form presented. The use of moderator cards for collecting root cause hypotheses will be explained as well as how to turn and Ishikawa diagram into an action item tracking list. A method for prioritizing investigation and improvement actions for both root cause analysis and continuous improvement will also be discussed. The differences between an Ishikawa diagram for continuous improvement and root cause analysis will be explained and illustrated and using Ishikawa diagrams as part of 8D and A3 reports will also be covered.


Detailed Summary:

This paper will discuss Ishikawa diagrams. Criticisms of Ishikawa diagrams will be presented and refuted and solutions to the criticisms will be provided. General advice and guidance for the use of Ishikawa diagrams will also be provided. Although the Ishikawa diagram has been around for decades, innovative new uses are still possible and these will be explained.

Ishikawa diagrams are one of the basic seven quality tools and the concept has existed since 1943. Criticisms of this classic methodology can be found in the literature. For example, one author has stated that there must be visualized evidence of causes and Ishikawa diagrams don’t offer a visualization of the evidence. It is true that the evidence should be visualized, but the Ishikawa diagram contains a list of potential causes. Visualization can be provided externally to the Ishikawa diagram, for example, by displaying a scan of measurement results in a report.

Time can be lost when searching for the correct branch to bin a possible cause and this is a valid concern. For example, is "Employee skipped operation at cutting machine due to poor lighting resulting in material with wrong dimension" to be placed at man, machine, method, material, or milieu? There should be no need for long discussions on binning to branches; the priority should be on getting ideas listed so in such a situation it is best to bin to one branch that reasonably fits and then move on.

The use of Ishikawa diagrams has been frequently compared to guessing and this is an incorrect oversimplification; use of subject matter expert’s knowledge and experience is not the same as guessing and this knowledge should be used together with an understanding of the failure.

Another common criticism is that causes are found by voting on them. Unfortunately, there is some truth to this accusation because some teams do vote and implement a solution. But they are doing it wrong! The hypothesis in the Ishikawa diagram should be compared to the evidence and any voting should be on what to investigate first and not on what to fix without investigation; an actual investigation must be performed to find the actual cause. A closely related objection is that too many causes may be listed to fix every one of them; the potential causes should be investigated so that only the correct one is fixed.

Being subjective is another complaint; however, an Ishikawa diagram should be list of hypotheses potentially explaining a problem. As such, they should be the start and not the end of an investigation. Hypothesis should be prioritized and then investigated.

A valid difficulty in using Ishikawa diagrams is displaying interactions such as when two potentially unrelated failures must occur for the failure under investigation to happen. In such a situation, the result of the two failures should be listed on a branch with separate failures listed on lower-level branches. For example, suppose a part is jammed and the suspected cause is a bore diameter that is too small fit together with a shaft that had a diameter that was too large; the failure “fit too tight” could be listed on one branch with sub-branches for “bore diameter too small” and “shaft diameter too large.” Alternatively, listing “Fit too tight (small bore with large shaft)” would keep the interactions together as one item.

In addition to responding to criticisms of Ishikawa diagrams, this talk will also offer suggestions on how to improve their use. For example, Ishikawa diagrams can grow out of control due to use of five whys as part of brainstorming. Simply asking why five times could result in a branch stating “Material – bolt loose – incorrect torque –procedure not followed – untrained operator –operator from other department – no replacement training plan.” Implementing a training plan to correct the problem may be a needed quality improvement, but it will not fix the problem is the bolt was never loose in the first place. Instead of brainstorming five levels of causes, a team should list the first one and then investigate it. There is no need to continue if the hypothesis is incorrect. If it was correct, new hypotheses explaining that cause should be added and investigated. In this way, five whys is still performed, but each cause is investigated before a new “why?” is asked.

An alternative method for generating hypotheses will be provided based on the use of note cards. Team members can write ideas on the note cards and they can then be used to create an affinity diagram that would be copied to the Ishikawa diagram. This method of silent brainstorming can help to encourage people to contribute when they are unwilling to speak up in front of others.

The failure conditions should be recreated once a root cause has been identified and corrected. The root cause may be incorrect if the problem does not return when the solutions has been removed. A root cause is more trustworthy if the problem can be turned on and off by adding and removing the fix.

Ishikawa diagrams often use branch labels based on the 6Ms. Although the 6Ms can be the appropriate approach, there is no requirement that they always be used. Even Dr. Kaoru Ishikawa used other branch labels in his book Guide to Quality control and various other examples will be presented.

Different approaches to the use of Ishikawa diagrams for root cause analysis and continuous improvement will also be explained. The objective in root cause analysis is to find the underlying cause creating the failure under investigation. In continuous improvement, there may be many improvement opportunities identified instead of one underlying cause.

The three types of Ishikawa diagram will be explained; dispersion analysis, production classification, and cause enumerative. A cause enumerative is suitable for both root cause analysis and continuous improvement; however, a cause enumerative type can be combined with a production classification type for root cause analysis. For example, in most situations, the cause can be attributed to usage, design failure, or a quality failure. The traditional 6Ms are still appropriate for quality improvement, although a flow chart can be turned into an Ishikawa diagram for either situation. These points will be illustrated with examples.

A method for translating an Ishikawa diagram into an action plan will be explained. Tables will be presented for prioritizing what to investigate based on a combination of costs and time to investigate and expected relation to the problem; a matrix will be provided for making prioritization decisions.

Finally, use of Ishikawa diagrams together with 8D reports for root cause analysis and A3 reports for quality improvement will be explained. Ishikawa diagrams are excellent versatile tools, but they should not be used as a standalone tool for complex problems. Using 8D or A3 reports together will Ishikawa diagrams provides a solid approach with a reliable, if used properly, tool. 



Matthew Barsalou is an Extramural Researcher at Poznan University of Technology and a Lean Six Sigma and Problem Solving Expert at QPLUSS and also works in the automotive industry where he provides teams with support and training in quality and statistics related tools and methods in addition to providing guidance during root cause analysis. He has a Master of Liberal Studies from Fort Hays State University, a Master of Science in Business Administration and Engineering (Industrial Engineering) from Wilhelm Büchner Hochschule, and a Bachelor of Science in Industrial Sciences from Western Kentucky University. His past positions include quality/laboratory technician, quality engineer, and quality manager.

Matthew is an Associate Academician in the International Academy for Quality, ASQ Fellow,  2021 Chair of the ASQ Statistics Division, and is certified as a Lean Six Sigma Mater Black Belt and holds ASQ certifications as CSSBB, CMQ/OE, and CQT. He is also the author of the books Root Cause Analysis, Statistics for Six Sigma Black Belts, The ASQ Pocket Guide to Statistics for Six Sigma Black Belts, The Quality Improvement Field Guide, and coauthor of Applied Statistics Manual, with Joel Smith.