5Why Analysis in Practice: From Symptoms to Root Causes, Asking the Right Questions to Solve Problems

1. Why Do Quality Issues Reoccur in Many Companies?

Many companies face this dilemma: the same issue is resolved today but resurfaces next month; the same customer complaint is addressed in the first half of the year but reoccurs at the end of the year. The cost of rework remains high, customer trust is eroded, and quality personnel are constantly firefighting. What is the problem? In most cases, it is not that corrective actions are poorly executed, but rather that the root cause has not been accurately identified—surface causes are mistaken for root causes, leading to superficial solutions.

The 5Why analysis method is designed to address this pain point: for a specific issue, ask "why" five times in succession, delving deeper from the symptoms until the underlying cause that can be addressed is identified. It may seem simple—just a series of "whys"—but in practice, whether the questions are asked correctly, deeply, and verified can make a world of difference. This article analyzes three real-world scenarios to demonstrate the complete application process of 5Why in companies and summarizes the three common pitfalls and key points for implementation.

It is important to note a core principle of 5Why: the questioning should not stop at the "human" level. Answers like "operational errors," "lack of responsibility," or "inadequate training" may seem reasonable but do not lead to effective corrective actions—you cannot eliminate errors through training alone. A truly qualified root cause must point to changeable factors at the process, design, or system level.

2. Case One: A Welding Defect Complaint in an Electronics Manufacturing Company—A Complete Five-Layer 5Why Analysis

An electronics manufacturing company specializes in power board contract manufacturing, producing millions of units per month. In a certain quarter, it received complaints from three customers: the power boards had poor solder joints, leading to power-on failures. The return rate reached 0.8%, far exceeding the industry standard of 0.1%. The after-sales department replaced the defective units as usual, but the return rate rose to 0.6% the following month. The quality department decided to move beyond surface-level solutions and use 5Why to thoroughly investigate the issue.

First Question: Why did customers receive boards with poor solder joints?—The AOI optical inspection after reflow soldering missed the defects, allowing the defective boards to proceed to packaging.

Second Question: Why did the AOI miss the defects?—The inspection program's threshold for solder joint area was set too wide, allowing minor defects to pass as acceptable.

Third Question: Why was the threshold set so wide?—Previously, the false alarm rate was too high, frequent machine stops for confirmation affected production output. The process engineer widened the threshold to ensure production volume.

Fourth Question: Why was the false alarm rate so high that it affected production?—Frequent line changes required the AOI parameters to be recalibrated each time, leading to unstable parameters and an increase in false alarms.

Fifth Question: Why were line changes so frequent?—The company's orders were primarily small batches with multiple varieties, but the production plan did not group orders by solder paste characteristics and PCB material. Orders with significant differences in solder paste types and PCB materials were randomly interspersed, and parameter changes relied entirely on the engineers' experience.

After five layers of questioning, the root cause emerged: the problem was not with the operators or the AOI equipment itself, but with the production scheduling logic and process parameter management. The corrective actions became clear:

1. The planning department should group orders by solder paste characteristics and PCB material, concentrating similar orders for production, reducing line changes by 70%.
2. Standardize the AOI threshold settings, establish a parameter library based on solder paste and board material combinations, and directly apply these settings after line changes, eliminating reliance on manual experience.
3. Add a specialized inspection window for poor solder joints in the AOI program as a double safeguard.

Two months after implementing these measures, the return rate dropped to 0.08%, and it remained stable for four consecutive quarters.

The key takeaway from this case is that the first four questions pointed to "people" and "equipment," but only by delving deeper did the true root cause, hidden in the production scheduling process, become apparent. If the questioning had stopped at the third level, the measures would have been limited to "strengthening AOI inspections," and the problem would have reoccurred.

3. Case Two: Frequent Machine Downtime in an Automotive Parts Company—Multi-Branch 5Why and Data Verification

An automotive parts company supplies die-cast components to vehicle manufacturers. One of its critical die-casting machines experienced an average of twelve unplanned downtimes per month, each lasting from twenty minutes to two hours, putting significant pressure on deliveries. The equipment department followed the old routine of "alarm—repair—resume" for six months, but the downtime increased instead of decreasing. The quality department intervened and used 5Why in conjunction with downtime records to re-evaluate the situation.

This time, the questioning did not follow a single line but branched out into two parallel paths based on the fault symptoms.

Branch One: Why did the machine stop?—The hydraulic system triggered a high-temperature alarm, causing the machine to shut down automatically. Why was the oil temperature too high?—The cooling system's heat dissipation efficiency decreased. Why did the efficiency decrease?—The cooling system's air ducts were severely clogged with workshop dust and oil. Why was the clogging not detected?—The daily inspection form only covered items like oil level and pressure, and the cooling system was not included. Why was it not included?—The equipment manual did not list the cooling system as an inspection item, and the equipment department followed the manual without updating the inspection form.

Branch Two: Why did the machine stop?—The mold temperature triggered an abnormal alarm. Why was the mold temperature abnormal?—The cooling water channels in the mold were clogged with scale, reducing cooling efficiency. Why did the water channels scale up?—The cooling water was not softened and was directly used from the tap. Why was it not softened?—To save costs, the water treatment system was canceled during the factory construction, and no one brought it up afterward.

The root causes identified in both branches pointed to the same type of issue: blind spots in the equipment preventive maintenance system. The corrective actions were:

1. Include the cooling system and water channels in the inspection and quarterly maintenance plan, and review and revise the inspection form every six months based on actual fault data.
2. Install a water treatment system and incorporate water quality testing into the monthly inspection.
3. Establish a database of downtime causes, and use a Pareto chart to analyze the downtime structure monthly, ensuring resources are directed to the most frequent fault types.

After one quarter of implementation, the average monthly downtime of the die-casting machine was reduced to less than two times.

The key to this case was "verification." Each layer of questioning in both branches was supported by downtime records, alarm logs, and inspection records, rather than relying on the maintenance technicians' "experience." Without data support, 5Why is just a brainstorming session; with data verification, it becomes a genuine root cause analysis.

4. Case Three: High After-Sales Repair Rate in an Appliance Company—Cross-Departmental 5Why

An appliance company launched a drum washing machine, which had an after-sales repair rate of 1.2%, three times higher than similar products. The main customer complaints were about "abnormal noise during spin-drying." The after-sales department replaced bearings and reinforced shock absorption, but the repair rate only slightly decreased. Since the issue involved multiple departments, the company formed a cross-departmental team to tackle it using 5Why.

First Question: Why is there abnormal noise during spin-drying?—The inner drum has excessive eccentricity, causing it to collide with the outer shell.

Second Question: Why is the eccentricity excessive?—The distribution of clothes in the drum is uneven, leading to dynamic imbalance during high-speed spin-drying.

Third Question: Why does the dynamic imbalance exceed limits?—The control program does not fully execute the clothes distribution program before accelerating to high speed, directly entering the high-speed phase.

Fourth Question: Why was the distribution program not fully executed?—During a software version upgrade, to shorten the washing cycle, the distribution time was reduced from ninety seconds to thirty seconds without adequate verification.

Fifth Question: Why was the software released without adequate verification?—The software change review process only involved the R&D department, without participation from quality or after-sales departments, and after-sales data was not included in the release criteria.

The root cause emerged: it was not the quality of the bearings or the shock absorption design, but the lack of a software change management process. The corrective actions were:

1. Restore the distribution program parameters and recalibrate them based on different clothing loads.
2. Establish a cross-departmental review mechanism for software changes, giving quality and after-sales departments veto power over change proposals.
3. Incorporate the after-sales repair rate as a mandatory threshold for software version releases, ensuring no release if the rate is not met.

Three months after the new software was pushed, the repair rate for this model dropped to 0.3%, and the older batches benefited from OTA updates.

The challenge in cross-departmental 5Why is "identifying issues in other departments." In this case, the first four questions revolved within the R&D department, and only by delving to the fifth level did the systemic defect in the process become apparent. This highlights that root cause analysis must be supported by a cross-departmental participation mechanism to ensure thorough questioning and avoid stopping at departmental boundaries.

5. Three Common Pitfalls in 5Why

Based on the above cases and extensive corporate practices, the misuse of 5Why almost always falls into the following three traps.

Pitfall One: Stopping at "Human Factors." Writing the root cause as "lack of employee responsibility," "inadequate skills," or "insufficient training" is the most frequent error. These answers have two issues:

1. They cannot be verified—responsibility is not quantifiable.
2. They do not lead to effective corrective actions—you cannot eliminate human weaknesses through policies. The correct approach is to continue questioning: why did the employee miss the inspection? Is it due to a lack of poka-yoke, a fast production pace, or unclear standards? Shift the focus from individuals to processes.

Pitfall Two: Following Only One Line of Inquiry. Real-world quality issues are almost always the result of multiple factors. Following only one line of questioning can easily miss the true critical factors. Case Two is a typical example: the same machine and the same fault symptom, but two branches pointed to different root causes. Missing either would not fully resolve the issue. It is recommended to use a fishbone diagram to categorize potential causes by people, machines, materials, methods, environment, and measurement, then apply 5Why to each key branch, and finally confirm the primary and secondary causes with data.

Pitfall Three: Unverified Conclusions. Each layer of 5Why should be a "hypothesis" rather than a "fact," and must be verified with data, on-site observations, or small-scale trials before proceeding to the next layer. In Case One, if the AOI parameter change records were not verified, and in Case Two, if the inspection records were not reviewed, the conclusions would be mere guesses. A practical verification standard is: the root cause must be testable by the logic "if it is eliminated, the problem will not reoccur," and ideally, the effectiveness of the corrective actions can be proven with data.

6. Four Key Points to Make 5Why Truly Effective

1. Adhere to the "Three Realities" Principle. Go to the site, see the actual items, and check the reality. The material for questioning comes from on-site data and physical evidence, not from meeting room recollections. The AOI parameter library in Case One and the inspection form in Case Two were both found on-site.

2. Combine with Other Tools. Use the fishbone diagram to "spread out" the potential causes, 5Why to "dig deep," the Pareto chart to "prioritize," and the control chart to "verify the effectiveness." Each tool has its blind spots, and combining them forms a complete problem-solving chain.

3. Question to "Systemic Root Causes." The judgment standard is: the root cause points to defects at the process, standard, design, or mechanism level, and eliminating it ensures that similar issues do not reoccur. In Case Three, the root cause was ultimately identified in the software change process, a typical systemic root cause.

4. Close the Loop for Recurrence Prevention. The endpoint of 5Why is not just finding the root cause but ensuring the implementation of corrective actions, verification of their effectiveness, standardization, and horizontal deployment. The grouping of production schedules in Case One and the revision of inspection forms in Case Two are examples of solidifying improvement outcomes into new standards. Otherwise, the problem will eventually return.

7. Conclusion

The value of 5Why lies not in the technique but in the attitude: the courage to ask one more "why" to challenge "taken-for-granted" answers. Most quality issues reoccur not because there are no solutions, but because they have never been thoroughly questioned. A successful 5Why analysis should lead to an epiphany of "the root cause is here" and result in systemic corrective actions that prevent the issue from recurring.

For companies, instead of increasing inspection personnel and firefighting resources, it is better to train the team's questioning skills, turning every customer complaint, every machine downtime, and every rework into an opportunity to delve into the root cause. Asking the right questions is half the battle; delving to the root cause is where the problem truly ends.

Each additional "why" brings you closer to the root cause; each missed "why" invites the problem to return.

Knowledge code: 5.2.3

Version: v20260731

Author: Quality Think Tank

Quality Think Tank is dedicated to providing systematic knowledge, methodologies, and practical tools for quality management professionals, helping companies continuously improve their quality capabilities.