---
id: KB-IC-009
url: https://app.codecontract.io/help/reports-and-quality/analysing-why-something-happened
idioma: en
categoria: informes-y-calidad
subcategoria: calidad
audiencia: usuario
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IC-002, KB-IC-007]
citadoPor: [KB-IU-008, KB-IC-014, KB-IC-019]
---

# Analysing why something happened

_The difference between fixing a case and fixing the cause._

**Responde a:** root cause analysis · why does the same failure repeat · effective corrective action · investigating an incident

A failure is fixed in minutes: the document is redone, the supplier is phoned, the send is repeated. What is hard is stopping it recurring, and for that you need to know why it happened — which is almost never what it looks like at first sight.

## Going down a level, three times

The technique is simple: ask "and why?" three times about the previous answer. Almost always the third produces something changeable, while the first produces only a person.

| Level | Typical answer | What can be done with it |
| --- | --- | --- |
| First | "Someone forgot" | Nothing. That is a name, not a cause |
| Second | "There was no way to know it was due" | Now you can work with it |
| Third | "That document had no expiry marked" | This is fixable, and for everyone |

> [!IMPORTANT]
> If the conclusion of an analysis is a person's name, the analysis is not finished. People make mistakes; what you are looking for is what allowed that mistake to produce consequences with nothing stopping it earlier.

## How to check the fix worked

1. **Define what should stop happening** — In one concrete, measurable sentence, not "improve control".
2. **Set a date to look** — Three months is usually enough to know whether it recurs.
3. **Close only then** — Closing on the day the fix is applied is closing without knowing whether it worked.

> [!WARNING]
> Beware the corrective action that consists of asking someone to be more careful. That is not a corrective action: it is the same situation with a more pressured person, and it fails identically on the first bad day.

> [!NOTE]
> Analyses that work usually end in a small, dull change: marking an expiry, changing a request title, assigning an owner. Those ending in a new ten-page procedure rarely change anything.

**Does it have to be done for every incident?**

No. For those with consequences and those that repeat.

**Who should do it?**

Someone not directly involved, if possible.

**What if the cause is outside our company?**

Document it the same: the action is then about the relationship with that third party.

## Ejemplos

**A company concludes that an insurance policy lapsed "because the purchasing lead missed it".**

- Goes down two more levels: that document type had no expiry marked

→ Fixes the configuration and the problem can no longer recur with anyone, not just her.

**Something happens and the analysis is done from memory two weeks later.**

- Checks the recorded sequence with its dates
- Identifies which specific step failed
- Records the cause and the action with a review date

→ The analysis starts from facts and the action can be verified months later.

**A culprit is sought instead of a cause.**

- Looks at which process step allowed it

→ The action corrects the process rather than a person.

**The cause is identified and nothing changes.**

- Records the action with an owner and a date

→ The analysis produces a change.

**The same problem returns six months later.**

- Checks whether it had happened before

→ The cause is tackled rather than the symptom.

**The analysis ends up in a document nobody opens.**

- Records it in the incident's file

→ It is found when it is needed again.