Quality Engineering Fundamentals Part 3: Root Cause Analysis

Quality Engineering Fundamentals Part 3: Root Cause Analysis

This is Part 3 of a 5-part series on Quality Engineering Fundamentals. In Part 1, we covered what quality management means. In Part 2 (our 7 QC Tools post), we covered the core toolkit. Now let's go deeper into one of the most important skills a quality engineer can have: finding the real cause of a problem.

Why "What Broke" Isn't the Same as "Why It Broke"

When a defect occurs, it's tempting to fix the obvious symptom and move on. But if you don't find the actual root cause, the same problem tends to come back — sometimes in a different form. Root Cause Analysis (RCA) is the discipline of digging past the symptom to the underlying cause.

Method 1: The 5 Whys

This is the simplest and most widely used RCA technique. You ask "why" repeatedly — typically five times — until you reach the true root cause.

Example:

• Problem: A batch of bottles failed the seal test.
• Why? The sealing machine applied inconsistent pressure.
• Why? The pressure valve was worn out.
• Why? The valve wasn't replaced on schedule.
• Why? There was no preventive maintenance schedule for that valve.
• Why? Maintenance schedules were only created for "critical" parts, and this valve wasn't classified as critical.

Root cause: a gap in the maintenance classification system — not just "a worn valve." Fixing only the valve would have left the real problem (the classification gap) untouched, and a different part would eventually fail the same way.

Method 2: The Fishbone (Ishikawa) Diagram

When a problem could have multiple contributing causes, the Fishbone Diagram helps organize them into categories — commonly: Man, Machine, Method, Material, Measurement, and Environment.

Example: For the same sealing defect, a Fishbone analysis might reveal contributing factors across categories: Machine (worn valve), Method (no maintenance schedule), Man (operators not trained to notice early pressure inconsistencies), and Measurement (no sensor to detect pressure drift in real time). This gives a fuller picture than the 5 Whys alone, especially for complex, multi-factor problems.

When to Use Which Method

• Use 5 Whys when the problem seems to have a single, traceable chain of causes
• Use Fishbone when the problem could stem from multiple, unrelated sources and you need to brainstorm broadly before narrowing down

In practice, many quality engineers use both together: Fishbone to brainstorm all possible causes, then 5 Whys to drill into the most likely one.

Common Mistakes in Root Cause Analysis

• Stopping too early: Settling for "operator error" without asking why the error was possible in the first place
• Confusing correlation with causation: Just because two things happened together doesn't mean one caused the other — verify with data
• Skipping verification: Once you identify a suspected root cause, test it before implementing a fix. If removing the suspected cause doesn't stop the defect, you haven't found the real root cause yet

What's Next in This Series

In Part 4, we'll cover Statistical Process Control (SPC) — how to use control charts and data to monitor a process continuously, so you catch problems before they turn into full-blown defects.

Want to build these root-cause investigation skills hands-on? Check out our Quality Engineering programs at The Engineer Inside!