Root Cause Analysis

Some Basketly customers were charged twice for the same order. A developer quickly disables the Pay button after the first press, and the tickets stop. Problem solved? Only the symptom. Next month the same kind of bug appears in "Book slot", because nothing about how the team works has changed.

The rule

Fix the symptom today; fix the cause so it never returns.

Root cause analysis (RCA) traces a defect back past what you saw (the symptom) to why it could happen at all (the root cause). The goal is a fix that prevents the whole class of defect, not just this instance.

Two simple tools:

• The five whys: ask "why?" about the problem, then about each answer, roughly five times, until you reach something in the process or system you can change. Five is a guide, not a rule.
• The fishbone (cause-and-effect) diagram: write the problem at the head, then brainstorm causes along bones such as people, process, tools, environment, requirements. It helps when many causes could be involved.

RCA must be blameless. "Ravi forgot" is never a root cause; people forget, so the real question is why the process let one person's slip reach customers. Blame makes people hide mistakes, and hidden mistakes cannot be analysed.

A good RCA ends with actions: one that fixes this defect, and one that changes the process.

The shortcut

Keep asking why until the answer is something you can change in the process, not a person. Stop too early and you get a patch; blame a person and you get silence.

The trap is stopping at "the button was not disabled". That fix helps one screen; the process fix protects every screen built after it.

Drills

Answer fast — trust the rule.

Remember

• Fix the symptom today; fix the cause so it never returns.
• Ask why until the answer is a process you can change, not a person.
• End every RCA with a code action and a process action.