# Root Cause Analysis: [Problem title]

> A one-document record of a business problem worked through to its
> root causes and verified countermeasures, combining three common
> methods: a Pareto split of the data, a fishbone (cause and effect)
> diagram and the 5 Whys, laid out in the order of an A3 problem-solving
> report. It supports, but does not replace, the nonconformity and
> corrective action record required by management system standards such
> as ISO 9001:2026 clause 10.2. Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- Use it for a recurring or costly problem with data behind it. For a
  single safety incident or a patient safety event, use a sector method
  instead (see section 10).
- Work left to right like an A3 sheet: problem, current condition,
  target, analysis, countermeasures, check, follow-up.
- Contain the problem first (section 2), then analyse. Do not wait for
  the analysis to protect customers.
- Look for causes in processes and conditions, not people. "Operator
  error" is a symptom; ask why the error was possible.
- Common pitfall: stopping at the first plausible cause, or picking a
  countermeasure before the cause is verified with data.
-->

## Document control

<!-- Guidance: Name the owner who has authority to change the process. Link any formal nonconformity or CAPA record. -->

| Field | Value |
|---|---|
| Document ID | [RCA-YYYY-NNN] |
| Problem title | [Short title] |
| Linked records | [NC or CAPA ID, incident ID, complaint ID] |
| Version | [0.1] |
| Status | [Open / Analysis / Countermeasures / Verifying / Closed] |
| Owner | [@process-owner] |
| Team | [@name, @name] |
| Sponsor | [@sponsor] |
| Date opened | YYYY-MM-DD |
| Target close date | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | Problem statement and containment |
| 0.2 *(Example)* | YYYY-MM-DD | [@author] | Root cause verified, countermeasures added |

The worked example is **Calderbrook Foods**, a fictional bakery
manufacturer supplying supermarkets, whose on-time-in-full (OTIF)
delivery rate fell in one month.

## 1. Problem statement

<!-- Guidance: State what, where, when, how much and the gap to standard. Use data, not opinions, and do not mention causes or solutions here. -->

| Item | Value |
|---|---|
| What is wrong | [Observable problem] |
| Where | [Site, line, process] |
| When first seen | YYYY-MM-DD |
| Size of the gap | [Actual vs standard] |
| Impact | [Customers, cost, compliance] |

*Example:* In March, 414 of 3,600 customer orders (11.5%) were not on
time in full, against a standard of 97% OTIF. OTIF fell from 97.2% in
February to 88.5% (3,186 of 3,600). Two customers applied late-delivery
penalties.

## 2. Containment

<!-- Guidance: Immediate actions to protect customers while the analysis runs. Containment is not a fix; record when it will be removed. -->

| ID | Action | Owner | Date | Remove when |
|---|---|---|---|---|
| CT-1 | [Action] | [@owner] | YYYY-MM-DD | [Condition] |
| CT-1 *(Example)* | Extra dispatch check of every pallet against the order | [@dispatch-lead] | YYYY-MM-DD | OTIF at 97% for 4 weeks |
| CT-2 *(Example)* | Daily call with the carrier on collection times | [@logistics] | YYYY-MM-DD | Carrier countermeasure verified |

## 3. Current condition and Pareto

<!-- Guidance: Break the problem down by type, location or time until one part stands out. A Pareto table sorts the categories and shows the cumulative share. -->

| Failure category | Orders | Share | Cumulative |
|---|---|---|---|
| [Category] | [Count] | [%] | [%] |
| Dough line changeover overran, product late *(Example)* | 186 | 44.9% | 44.9% |
| Short pick at dispatch *(Example)* | 97 | 23.4% | 68.4% |
| Carrier collected late *(Example)* | 71 | 17.1% | 85.5% |
| Missing or wrong labels *(Example)* | 38 | 9.2% | 94.7% |
| Other *(Example)* | 22 | 5.3% | 100.0% |
| **Total** *(Example)* | **414** | **100.0%** | |

*Example:* The first two categories explain 68.4% of failures. The team
analyses changeover overruns first.

## 4. Target

<!-- Guidance: A measurable target and date for the focus area, and for the overall problem. -->

| Measure | Current | Target | By |
|---|---|---|---|
| [Measure] | [Value] | [Value] | YYYY-MM-DD |
| *Example:* Orders late due to changeover per month | 186 | 20 or fewer | YYYY-MM-DD |
| *Example:* OTIF | 88.5% | 97% or more | YYYY-MM-DD |

## 5. Fishbone (cause and effect)

<!-- Guidance: Brainstorm possible causes under fixed categories. A common set for operations is people, methods, machines, materials, measurement and environment; services often use policies, procedures, people, place and systems. Mark each cause as Verified, Ruled out or Not yet tested. -->

```mermaid
flowchart LR
    M1["People: new shift leads not trained on changeover"] --> E
    M2["Methods: no standard changeover sequence"] --> E
    M3["Machines: mixer bowl clamp sticks"] --> E
    M4["Materials: allergen clean needs extra time"] --> E
    M5["Measurement: changeover time not recorded"] --> E
    M6["Environment: March schedule added 3 new products"] --> E
    E["Effect: dough line changeover overruns"]
```

| ID | Category | Possible cause | Test | Result |
|---|---|---|---|---|
| FC-1 | [Category] | [Cause] | [How it was checked] | [Verified / Ruled out / Not yet tested] |
| FC-1 *(Example)* | Methods | No standard changeover sequence | Observed 6 changeovers, each done in a different order | Verified |
| FC-2 *(Example)* | Environment | March schedule added 3 new products | Changeovers per week rose from 9 to 15 | Verified |
| FC-3 *(Example)* | Machines | Mixer bowl clamp sticks | Maintenance log shows 1 event in March | Ruled out |
| FC-4 *(Example)* | Measurement | Changeover time not recorded | No data before March | Verified (contributing) |

## 6. 5 Whys

<!-- Guidance: Start from the verified cause and ask why until you reach a cause the organisation can change and that, if removed, stops recurrence. It may take fewer or more than five steps. Check each answer with evidence. -->

| Step | Why? | Answer | Evidence |
|---|---|---|---|
| [N] | [Why did the previous answer happen?] | [Answer] | [Evidence] |
| 1 *(Example)* | Why were orders late? | Product finished after the dispatch cut-off | Production log |
| 2 *(Example)* | Why did product finish late? | Changeovers took 70 minutes instead of 40 | Timed observation |
| 3 *(Example)* | Why did changeovers take 70 minutes? | Each crew used its own order of steps, with waiting between them | Observation of 6 changeovers |
| 4 *(Example)* | Why does each crew use its own order? | No standard work for changeover exists | Document search |
| 5 *(Example)* | Why is there no standard work? | Changeovers were rare until March, so no one owned the method | Schedule history, interviews |

**Root cause statement:** [One sentence that names the system condition.]

*Example:* Changeover has no standard method or owner, which became
critical when weekly changeovers rose from 9 to 15.

## 7. Countermeasures

<!-- Guidance: Each countermeasure points to a verified root cause. Prefer changes to the process or design over reminders and retraining alone. -->

| ID | Countermeasure | Addresses | Owner | Due | Status |
|---|---|---|---|---|---|
| CM-1 | [Countermeasure] | [FC-n / root cause] | [@owner] | YYYY-MM-DD | [Planned / Done] |
| CM-1 *(Example)* | Write and train standard work for changeover, with steps done in parallel | FC-1 | [@production-lead] | YYYY-MM-DD | Planned |
| CM-2 *(Example)* | Sequence the weekly schedule to group products with the same allergen profile | FC-2 | [@planning] | YYYY-MM-DD | Planned |
| CM-3 *(Example)* | Record start and end of every changeover on the line board | FC-4 | [@shift-lead] | YYYY-MM-DD | Planned |

## 8. Check results

<!-- Guidance: Compare results after the countermeasures with the target in section 4, over a long enough period to rule out chance. If the target is missed, return to section 5. -->

| Measure | Before | After | Target | Met? |
|---|---|---|---|---|
| [Measure] | [Value] | [Value] | [Value] | [Yes / No] |
| *Example:* Average changeover time (minutes) | 70 | [Value] | 40 | [Pending] |
| *Example:* OTIF | 88.5% | [Value] | 97% | [Pending] |

## 9. Follow-up and standardisation

<!-- Guidance: Make the fix stick: update procedures, training and audits, remove containment, and share lessons with similar sites or lines. Then work on the next Pareto category. -->

| Action | Owner | Due |
|---|---|---|
| [Update procedure, training or audit] | [@owner] | YYYY-MM-DD |
| *Example:* Add changeover standard work to the controlled procedures | [@quality] | YYYY-MM-DD |
| *Example:* Start a second analysis on short picks (23.4% of failures) | [@dispatch-lead] | YYYY-MM-DD |

```mermaid
flowchart LR
    A["Define problem"] --> B["Contain"]
    B --> C["Pareto and target"]
    C --> D["Fishbone and 5 Whys"]
    D --> E["Countermeasures"]
    E --> F{"Target met?"}
    F -- Yes --> G["Standardise and close"]
    F -- No --> D
```

## 10. Management system and sector links

<!-- Guidance: If the problem is a nonconformity under a certified management system, open the formal record as well. Record the clause it serves. -->

- **ISO 9001:2026, clause 10.2 (nonconformity and corrective action):**
  in outline, the organisation reacts to the nonconformity, evaluates
  the need to remove its causes (including root cause analysis),
  implements action, reviews effectiveness and keeps evidence. The same
  clause number appears in other management system standards that share
  the harmonized structure, such as ISO/IEC 27001:2022. Clause details
  of the 2026 edition here come from public summaries, not the licensed
  text; check your copy.
- **Formal record:** use [Nonconformity and corrective action record](../compliance/capa-nonconformity.md).
- **Patient safety events:** use [Healthcare root cause analysis](../healthcare/root-cause-analysis.md).
- **Software and service incidents:** use a blameless [Postmortem](../dev/postmortem.md).

## 11. Related templates

<!-- Guidance: Link the documents that feed or follow this analysis. -->

- [KPI scorecard](./kpi-scorecard.md), where the problem is often first seen as a Red KPI
- [Process document](./process-document.md) to write the new standard work
- [Lessons learned](../project/lessons-learned.md) to share what the team found

## Glossary

- **Containment:** a temporary action that protects the customer while the cause is found.
- **Pareto analysis:** sorting failure categories by size to find the few that cause most of the problem.
- **Fishbone diagram:** a cause and effect chart that groups possible causes by category; also called an Ishikawa diagram.
- **5 Whys:** asking why repeatedly, with evidence, until a changeable system cause is found.
- **A3:** a one-sheet problem-solving report that tells the story from problem to follow-up.
- **OTIF:** on time in full, the share of orders delivered complete by the agreed time.

## Standard and licence note

Based on common quality improvement practice: the cause and effect
diagram popularised by Kaoru Ishikawa, the 5 Whys described by Taiichi
Ohno of Toyota, and the A3 report format pioneered by Toyota (see the
Lean Enterprise Institute lexicon, https://www.lean.org/lexicon-terms/a3-report/
and https://www.lean.org/lexicon-terms/5-whys/). Clause 10.2 of ISO
9001:2026 (sixth edition, published 16 September 2026) and ISO/IEC
27001:2022 is cited by number with an original paraphrase; no text from
the standards is reproduced. Official text: ISO, purchase or licensed
access: https://www.iso.org/standard/88464.html (ISO 9001:2026). Check
the current edition and your certification body's guidance before use.
The section text and fictional Calderbrook example are original.
Template licence: MIT.