The fishbone diagram is the most commonly used cause-and-effect analysis tool in Six Sigma. Cause-and-effect analysis is one of the key tasks in any Six Sigma DMAIC project because half of the game is won when the correct root causes of the problem (the Y) are found. However, poor use of the fishbone diagram is a root cause in itself. It is the root cause of poor Six Sigma analysis.
What Is a Fishbone Diagram?
For the few readers who do not already know, the fishbone diagram was developed by Kaoru Ishikawa, who pioneered quality management processes in the Kawasaki shipyards in Japan. The fishbone diagram is used to explore all the potential or real causes (Xs) that result in a single effect (Y). Every fishbone diagram has (or should have) the following basic structure:
Main Problem with Fishbone Diagram
The fishbone diagram is used to graphically represent logical relationships, but it is not really a logic tool. Even if conceived by a team of experts, a fishbone diagram is nothing but a collection of a group of people’s perceptions of the relationship between one element and another.
There is no discipline within fishbone analysis to validate the (logical) connections between one element and another. However, a powerful tool from the theory of constraints (TOC) system for continuous improvement can strengthen the fishbone diagram. The “categories of legitimate reservation” (CLR) are rules designed to verify the validity of cause-and-effect relationships. (See the table below.) These rules can be applied to any cause-and-effect statements, such as those in fishbone diagrams.
| Categories of Legitimate Reservation | |
| Category | Test |
| 1. Clarity | a. Is the connection between cause and effect convincing at face value? b. Is there any additional verbal explanation required for the cause and effect as written? c. Is this a long arrow (intermediate steps missing)? |
| 2. Entity Existence |
d. Is there a complete sentence (subject and verb)? e. Does the sentence make sense? f. Is it a true statement? Does it exist in reality? |
| 3. Causality Existence |
g. Does the cause, in fact, result in the effect (i.e., does an if-then connection really exist?) h. Does it make sense when read aloud – using if-then? |
| 4. Cause Insufficiency |
i. Can the cause result in the effect on its own, or must it exist in concert with one or more other causes (and gate)? |
| 5. Additional Cause |
j. Is this the only cause? Are there other independent causes that may result in the same effect (or gate)? k. If the cause in question is eliminated, are there other circumstances in which the effect would still be present? |
| 6. Cause-and- Effect Reversal |
l. Is the arrow really drawn in the proper direction? Is it possible that what is offered as the cause might really be the effect? |
| 7. Predicted Effect Existence |
m. Is the cause itself intangible? If so, are there one or more additional predicted effects that must exist for the cause-and-effect relationship to be valid? |
| 8. Tautology | n. Is it circular logic? o. Is the effect offered as a rationale for the cause? |
Applying Categories of Legitimate Reservation
In beginner DMAIC (Define, Measure, Analyze, Improve, Control) projects, there is a tendency to find the following kind of connections:
- Too many process steps – long cycle time
- Using SAP (systems, applications and products in data processing) – excessive stock out
- Wrong measurement – measurement equipment failure
Are these really valid cause-and-effect statements? Applying CLR should help answer that question.
a. If a process has many steps, then its cycle time is long (more than X hours).
This fails the “causality existence test.” It is not true that just because a process has many steps, it will necessarily take a long time. Each step can take a very short time to complete and collectively may not exceed the required cycle time. Conversely, it is not true that a process with few process steps will take a short time to complete.
b. If SAP is being used, then excessive stock out occurs.
This fails the “clarity test.” The cause-and-effect connection is not convincing at face value. Many organizations using SAP ERP (enterprise resource planning) do not experience excessive stock out.
c. If a wrong measurement is taken, then measurement equipment will fail.
Crucially, this fails the “cause-and-effect reversal test.” Actually, measurement equipment failure causes wrong measurements.
Conclusion: ‘Steal with Pride’
Six Sigma practitioners often say, “Steal with pride” when talking about using ideas from any source to improve the methodology. Six Sigma practitioners would do well to steal with pride from an excellent improvement framework like the theory of constraints (TOC). In particular, the fishbone analysis can become better if it is governed by the TOC’s categories of legitimate reservation.
