Root Cause Analysis for Quality Engineers

Why Root Cause Analysis Matters

Root cause analysis (RCA) is the difference between fixing a symptom and eliminating a problem. Without proper RCA, corrective actions address surface-level causes and the problem recurs — often generating repeat SCARs and eroding customer confidence.

The most common rejection reason for 8D reports is an insufficient or unverified root cause. Reviewers look for:

• A root cause that explains why the defect occurred, not just what happened
• Evidence that the proposed root cause actually produces the observed failure
• Analysis that reaches the systemic level, not stopping at the immediate cause

5-Why Analysis

The 5-Why method is the most commonly used RCA technique in SCAR responses. It involves asking “why?” iteratively until the systemic root cause is uncovered. Despite its simplicity, it is frequently done poorly.

How to Do It Right

1. Start with the problem statement (D2). Be specific.
2. For each “why,” provide evidence or data that supports the answer. If you cannot, the answer is speculation, not analysis.
3. Continue until you reach a cause that is systemic (process, procedure, or management system level) — not a human behavior.
4. If the chain leads to “operator error,” keep asking: why was the error possible? What system failed to prevent it?
5. You may need fewer or more than 5 levels. The name is a guideline, not a rule.

Example: Dimensional Nonconformance

Common Mistakes

• Stopping too early. “Tool wore out” is an immediate cause, not a root cause.
• No evidence. Each “why” answer must be supported by data, not assumption.
• Jumping to conclusions. The 5-Why should follow the evidence, not confirm a pre-existing theory.
• Circular reasoning. “Why did the defect occur? Because the process failed. Why did the process fail? Because it produced defects.”
• Stopping at human behavior. “Operator didn't check” is not a root cause — it's a symptom of a process gap.

Fishbone (Ishikawa) Diagram

The Fishbone diagram organizes potential causes into categories, making it easier to ensure nothing is overlooked. It is especially useful when the root cause is not immediately obvious and the team needs to brainstorm systematically.

The 6M Categories

How to Use It

1. Write the problem statement at the “head” of the fish.
2. Draw the 6M category branches.
3. Brainstorm potential causes under each category. Include all possibilities, even unlikely ones.
4. For each potential cause, ask: is there evidence for or against this? Eliminate causes with no supporting data.
5. Narrow to the most likely cause(s) and verify with data or testing.
6. Feed the verified root cause into your 5-Why or directly into corrective actions.

Fault Tree Analysis (FTA)

Fault Tree Analysis is a top-down, deductive method used primarily in aerospace, automotive safety, and medical device contexts. It maps the logical relationships between failure events using AND/OR gates.

When to Use FTA

• Complex failures with multiple interacting causes
• Safety-critical or high-severity defects
• When the customer or standard (AS9100, ISO 13485) requires it
• When you need to quantify the probability of failure

Example Structure

Top Event: Bore out of tolerance
├── [OR] Tool-related
│   ├── Tool wear beyond limit
│   └── Wrong tool loaded
├── [OR] Setup-related
│   ├── [AND] Incorrect offset + No first-piece check
│   └── Wrong program revision
└── [OR] Material-related
    ├── Material hardness out of spec
    └── Material lot mix-up

Is / Is-Not Analysis

Is/Is-Not analysis is a comparison technique that isolates the unique factors of the problem. By comparing where the problem does occur vs. where it does not, you can narrow the field of investigation dramatically.

The distinctions column reveals where to focus. In this example, the problem is specific to Cell 3, started around March 10, and is intermittent. The investigator should ask: what changed on or around March 10 specific to Cell 3? This might lead to a tool change, material lot change, or maintenance event.

Which Method Should You Use?

In practice, most SCAR responses use 5-Why as the primary method, sometimes preceded by a Fishbone brainstorm to identify potential causes. Use Is/Is-Not when the problem is intermittent or location-specific. Use Fault Tree for safety-critical or complex multi-cause failures.

You can combine methods: use Fishbone to brainstorm, Is/Is-Not to narrow, and 5-Why to drill into the most likely cause. The key is that the final root cause is verified with evidence.

Verifying the Root Cause

A proposed root cause is a hypothesis until verified. Verification means demonstrating that the identified cause actually produces the observed defect, and that removing it eliminates the defect.