Fishbone Diagram on the Wall, but the Main Cause is Still Decided by a Show of Hands? —— Five Practical Steps to Let the Root Cause Reveal Itself
1. The Bigger the Fish, the Longer the Meeting
A certain automotive parts factory received customer complaints about "bracket welding deformation" for three consecutive weeks. The quality department convened a meeting with production, process, equipment, and inspection teams. On the whiteboard, six large bones of a big fish were densely written: People — "many new employees," "poor night shift condition"; Machine — "old welding guns," "worn fixtures"; Material — "batch variations in steel plates"; Method — "unreasonable welding parameters"; Environment — "high workshop temperature"; Measurement — "insufficient accuracy of inspection tools." After two hours, the wall was filled, and the meeting chair said, "Let's have a show of hands." The most popular "many new employees, insufficient training" won, and the measures were set as "strengthen training, emphasize more in pre-shift meetings." However, a month later, the complaints continued, and the deformation rate remained unchanged.
The fishbone diagram wasn't wrong; the mistake was in using it as a "brainstorming record sheet." Every line on the diagram came from "I think," but none were verified; the conclusion was decided by the loudest voice, not by evidence — this is the most common and regrettable way for a fishbone diagram to fail.
2. Filling the Diagram Doesn't Mean Finding the Root Cause: Three Typical Problems
Problem One: The Fish Head is Too Broad. Writing just "welding deformation" on the fish head and starting to draw is like mixing problems from three production lines, five machines, and two shifts into one pot. The causes written on the bones are actually reasons for several different issues, and no one can convince the others.
Problem Two: Only Diverging, Not Verifying. Each cause stops at "possible," and no one verifies them on-site before the meeting ends. The more causes written, the easier it is for the real culprit to be buried among dozens of guesses, leading to a conclusion by vote.
Problem Three: Stopping at the Wrong Level. Stopping at "people": poor awareness, lack of responsibility, insufficient skills. The countermeasures can only be "strengthen training," and once the training is completed, the problem reappears in a different form.
Remember this: the fishbone diagram is a "hypothesis generator," not a "conclusion voting sheet." Each bone is just a hypothesis to be verified. Without verification, the conclusion is often the loudest voice, not the true root cause.
3. Five Practical Steps for Using the Fishbone Diagram
Step One: Pin Down the Fish Head First. The fish head should not be a broad term like "welding deformation." It should be a specific, measurable problem statement: which production line, which product, which time period, and what is the defect rate. Use data to slice the broad fish head into smaller, more specific ones — the top one or two items on a Pareto chart, or the block with the greatest difference after stratification. The narrower the fish head, the more likely the causes on the bones will point to the same true culprit. Change "high bracket welding deformation rate" to "2-line bracket welding deformation rate 2.1%, with 90% occurring during the night shift," and the scope of the investigation is immediately halved.
Step Two: Stratify Before Diverging. Before putting pen to paper, stratify the defect data by shift, equipment, material batch, and operator. After stratification, you might find that "the night shift deformation rate is four times that of the day shift." The fishbone diagram should focus on "why is the night shift rate so high" rather than mixing data from both shifts. This step determines whether the fishbone diagram is a sniper rifle or a shotgun.
Step Three: Expand According to 5M1E, but Write "Possibilities," Not "Conclusions." Go through each of the six bones (people, machine, material, method, environment, measurement) one by one, and write each end cause as a "verifiable hypothesis" rather than a label. "Poor skills of night shift personnel" is a label and cannot be verified; "new night shift employees did not undergo a skills assessment before working independently" is a hypothesis and can be checked by reviewing training records. Any cause written as "poor awareness, bad attitude, lack of responsibility" should be rewritten: what specific actions were not taken, which steps were not followed, or which standards were not adhered to. If it cannot be rewritten, it should be crossed out.
Step Four: Verify Each End Cause. Each hypothesis has only three possible outcomes: confirmed by data, disproved by on-site observation, or insufficient evidence to decide. Arrange verification methods from lowest to highest cost: check records (inspection forms, training archives, parameter histories), observe on-site (spend a night shift watching actual operations), and conduct experiments (reproduce the issue to see if the phenomenon recurs). Cross out any unverified hypotheses; don't be hesitant. Most fishbone diagrams fail because the meeting ends as soon as the diagram is complete — no one ever verifies the hypotheses on-site.
Step Five: Drill Down to the Controllable Level and Converge on the Main Causes. For each verified end cause, ask, "Is there a deeper cause above it?" Use the 5Why method to drill down one or two levels until you reach the process, standards, equipment, or poka-yoke that can be changed. Finally, rank the main causes by their impact and the strength of evidence, with one to three being sufficient — the main causes are for defining countermeasures, not for display. Record the verification evidence when locking down the main causes; if someone questions the countermeasures in a review meeting, you can present the evidence.
4. A Concise Example
A certain electronics factory had a 1.9% SMT virtual soldering defect rate. The fish head was pinned down to "2-line virtual soldering, 82% concentrated in the night shift." The bones were drawn around "why is the night shift virtual soldering rate high," and the 5M1E method was used to screen out six end causes, which were then verified: checking the training archives revealed no new night shift employees working independently; on-site observation found that the first piece after material change was self-inspected by the operator during the night shift, while the day shift had an IPQC review; checking the equipment history showed that the temperature curve in zone 3 of the 2-line reflow soldering machine was 8°C lower during the night shift; a reproduction test confirmed that the virtual soldering rate significantly increased when the temperature in this zone was lower. Drilling down one more level: why is no one monitoring the temperature curve during the night shift? — the night shift lacks process personnel to confirm parameters, and operators adjust based on experience. The main causes were locked down to two: lack of IPQC review for the first piece during the night shift, and no monitoring of the reflow soldering temperature curve during the night shift. The countermeasures were specific: the first piece during the night shift should be reviewed by IPQC, and the temperature curve should be included in the two-hour inspection. Two months later, the virtual soldering rate dropped to 0.3%, and customer complaints were eliminated.
5. Three Common Misconceptions
Misconception One: Starting to Draw Without Slicing the Fish Head. A broad problem statement will inevitably lead to a multitude of causes. Spend ten minutes slicing the fish head into a narrow, measurable, data-driven problem, and you'll save two hours later.
Misconception Two: Treating "Possibilities" as "Facts." The bones should contain hypotheses, not evidence. Converging without verification is like letting the loudest voice decide the root cause, and the measures will naturally be ineffective.
Misconception Three: Trying to Fix Every Cause. Without converging on the main causes, the countermeasures will be evenly distributed and ineffective. The output of the fishbone diagram should not be a fully filled chart but one to three verified main causes, each with its evidence.
6. One Sentence Summary
The strength of the fishbone diagram lies not in completeness but in accuracy — treating each cause as a hypothesis to be verified and pinning the root cause at a controllable level. Only then does the diagram truly become a target for countermeasures.
Filling the wall is just the beginning; verification and convergence are the true skills of the fishbone diagram.
Knowledge code: 5.2.4
Version: v20260908
Author: QTank QTank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.