> Root cause analysis methods compared: 5 whys, Ishikawa diagram, is/is-not, Pareto and fault tree analysis – with examples, when to use each and common mistakes.

Source: [https://docxpert.io/en/guides/root-cause-analysis](https://docxpert.io/en/guides/root-cause-analysis)

# Root Cause Analysis Methods: 5 Whys, Ishikawa & More

## Why root cause analysis decides the outcome

Every corrective action is only as good as the root cause analysis behind it. Find the wrong cause and you implement expensive actions – and the problem comes back anyway. ISO 9001 clause 10.2 explicitly requires determining the causes of nonconformities; ISO 13485, IATF 16949 and the Harmonized Structure of all ISO management system standards contain the same requirement.

The goal is the **root cause**: the cause whose elimination prevents the problem from recurring. It is often organisational rather than technical – such as a missing requirement, unclear responsibility or an inspection step that was never defined.

## Symptom, direct cause, root cause

| Level | Example | Action at this level |
| --- | --- | --- |
| Symptom | Customer receives mislabelled goods | Replace goods (correction) |
| Direct cause | Label printer used the wrong template | Fix the template |
| Root cause | Label templates are changed without approval; first label is not checked | Introduce template approval and first-label inspection |

Only actions at the root cause level prevent recurrence. A good test: would the problem stay away even if a different person, device or shift were involved?

## The 5 whys method

The 5 whys method comes from the Toyota Production System. Starting from the problem, you keep asking "why?" until you reach a cause that can be eliminated. Five is a guideline – sometimes three questions are enough, sometimes seven are needed.

1.  1
    
    Why did the machine stop?
    
    Because the fuse tripped due to overload.
    
2.  2
    
    Why was there an overload?
    
    Because the bearing was not sufficiently lubricated.
    
3.  3
    
    Why was it not lubricated?
    
    Because the lubrication pump delivered no oil.
    
4.  4
    
    Why did it deliver no oil?
    
    Because the intake filter was clogged.
    
5.  5
    
    Why was the filter clogged?
    
    Because the filter was not in the maintenance plan. → Root cause: incomplete maintenance plan.
    

**Strengths:** fast, needs no tools, works well in a team. **Limitations:** with several causes it easily follows a single path; results depend heavily on the participants' knowledge. For complex problems, combine 5 whys with Ishikawa – or run it as a tree with several branches.

## The Ishikawa diagram

The Ishikawa diagram – also called a fishbone diagram because of its shape – collects possible causes in categories. The problem sits at the "head", the influencing factors on the "bones". In manufacturing the **6Ms** have proven themselves:

| Category | Key question | Examples |
| --- | --- | --- |
| Man (people) | What role do qualification, experience, workload play? | New employees, shift changes |
| Machine | Which equipment, tools, software are involved? | Wear, settings, maintenance |
| Material | Which raw materials, parts, consumables? | Supplier change, batch variation |
| Method | Which procedures, requirements, workflows? | Missing or unclear work instruction |
| Mother nature (environment) | Which environmental conditions? | Temperature, humidity, dust |
| Measurement | How is measuring and inspection done? | Gauges, inspection plan, frequency |

In services and administration the categories are often adapted, for example with management, communication or IT systems. Important: the diagram collects possible causes. Which ones apply must then be confirmed with data.

## Example: Ishikawa and 5 whys combined

A plastics manufacturer has been finding more voids in a part for two weeks. In an Ishikawa diagram, the team collects possible causes: new resin batch (material), changed drying time (method), high humidity in the hall (environment), new operator on the night shift (people), worn check ring (machine) and a changed inspection method (measurement).

The data shows the voids occur on all shifts, but only with material from the new silo. That puts material and method in focus. The subsequent 5 whys analysis shows: resin from the new silo had higher residual moisture because the dryer was not readjusted for the longer conveying line – and there was no requirement covering changes to the material supply. A trial with longer drying time confirms the cause.

## Further methods at a glance

| Method | Principle | Suitable for |
| --- | --- | --- |
| Is/is-not analysis | Compare what is affected and what is not | Narrowing down an unclear failure |
| Pareto analysis | Tackle the most frequent defect types first (80/20 rule) | Prioritising many individual defects |
| Fault tree analysis (FTA) | Logical AND/OR combination of causes | Complex systems, safety-critical events |
| Change analysis | What changed before the first occurrence? | Problems that appear suddenly |
| Scatter diagram | Check the relationship between two variables | Confirming suspected causes |
| FMEA | Systematic review of potential failures in advance | Prevention, new developments |

## Which method when?

-   **Simple, clearly bounded problem:** 5 whys in a small team.
-   **Many possible influencing factors:** Ishikawa to collect, then 5 whys for the most likely branches.
-   **Unclear failure pattern:** start with is/is-not analysis to narrow down the problem.
-   **Many different defects:** Pareto to tackle the most important first.
-   **Safety-critical or complex:** fault tree analysis with experts.
-   **Sudden occurrence:** change analysis – what was different?

## Confirming causes

A plausible cause is not yet a confirmed cause. Before you define actions, test the hypothesis:

-   Can the defect be deliberately produced with the suspected cause?
-   Does it disappear when the cause is removed?
-   Does the cause explain all facts from the problem description – including why other parts are not affected?
-   Is there data supporting the relationship, such as measurements before and after a change?

## Facilitating root cause analysis in a team

1.  1
    
    Describe the problem clearly
    
    Everyone works from the same fact-based problem description.
    
2.  2
    
    Invite the right people
    
    People from the process who know the workflows on the ground – not just managers.
    
3.  3
    
    Go to the place
    
    Look at where it happened, examine parts and data, talk to those involved.
    
4.  4
    
    Collect causes, don't judge yet
    
    Capture all ideas first, then prioritise together.
    
5.  5
    
    Avoid blame
    
    The analysis looks for system weaknesses, not culprits. Otherwise information is held back.
    
6.  6
    
    Document the result
    
    Record method, causes, evidence and participants.
    

## Common mistakes

-   **"Human error" as root cause:** there is almost always a system weakness behind it – missing requirement, poor ergonomics, time pressure, missing check.
-   **Stopping too early:** the first plausible answer is accepted although more "why" questions were possible.
-   **No confirmation:** actions are based on assumptions rather than verified causes.
-   **Only looking at occurrence:** why the defect was not detected remains open.
-   **Desk-based analysis:** without looking at process, parts and data, the analysis stays superficial.

## Root cause analysis in docxpert

In docxpert's [CAPA management](https://docxpert.io/en/features/capa-management), root cause analysis is a phase of its own. You choose 5 whys or Ishikawa as the method and document the analysis directly on the record. Only when the root cause analysis is complete does the record move on to the action plan. That keeps it traceable which cause each action is based on.

Root cause analysis is a separate phase in the CAPA workflow. · Screenshot with sample data

## Frequently asked questions

Why exactly five whys?

The number is a guideline, not a rule. It reminds you not to stop at the first answer. Sometimes the root cause is reached after three questions, sometimes more are needed.

What are the 6Ms in the Ishikawa diagram?

Man, machine, material, method, mother nature (environment) and measurement. Depending on the area, the categories are adapted, for example with management or IT.

Can human error be a root cause?

Rarely. Further analysis usually shows why a mistake was possible and went unnoticed – for example due to missing requirements, unclear design or missing checks. These system weaknesses can be eliminated.

How many people should take part in a root cause analysis?

Three to six people with different perspectives on the process are ideal. Larger groups quickly become unwieldy.

How do I confirm a cause?

By showing that the defect can be deliberately produced or eliminated with the cause and that the cause explains all known facts – ideally with data.

What is the difference between 5 whys and Ishikawa?

5 whys follows a chain of causes in depth; Ishikawa collects possible causes in breadth. Combined, they complement each other very well.

Do I need a root cause analysis for every deviation?

For every corrective action, yes – ISO 9001 requires causes to be determined. The effort depends on the significance and risk of the problem.

What role does FMEA play?

FMEA is a preventive method that looks at potential failures before they occur. Lessons from root cause analyses should feed back into the FMEA.

How do I stop a root cause analysis from recording only a plausible guess?

Turn each suspected cause into a testable statement: if it is true, what observations or data should exist? Look for process records, measurements, material samples and accounts from people who know the work. Compare affected cases with cases where the problem did not occur so similarities and differences become visible. A cause is better supported when it explains known facts and a targeted change to the suspected mechanism affects the problem. Separate facts, assumptions and open questions in the record. Also ask why existing controls did not detect the failure; otherwise it can still escape. Avoid labelling an event “operator error” before examining design, information, workload and supervision. Where evidence conflicts, continue the investigation or document uncertainty rather than claiming certainty.

## Read next

[CAPA processFrom report to effectiveness check: the CAPA process in nine steps.Learn more](https://docxpert.io/en/guides/capa-process) [8D reportThe eight disciplines explained – with an example and common mistakes.Learn more](https://docxpert.io/en/guides/8d-report) [CAPA managementCorrective and preventive actions in nine phases – with 5 Whys, Ishikawa, deadlines and effectiveness checks.Learn more](https://docxpert.io/en/features/capa-management) [CAPA checklistCheckpoints from problem statement to effectiveness check.Learn more](https://docxpert.io/en/checklists/capa) [Deviation managementRecord, assess and close deviations with evidence – and escalate them into CAPA.Learn more](https://docxpert.io/en/features/deviation-management)

## Try docxpert free for 14 days

Document control, approvals, training and evidence in one platform – with English and German templates for more than ten standards.

[Start free trial](https://docxpert.io/en/trial)[See pricing](https://docxpert.io/en/pricing)