Root Cause Analysis Techniques

Why look beyond the obvious cause

When something goes wrong, there is usually an obvious explanation: a part broke, a person made an error, a setting was wrong. Fixing only that explanation often leads to the same problem returning in another form. Root cause analysis is the practice of asking what lies beneath the obvious cause, so that the fix addresses the conditions that allowed the problem rather than just its latest appearance.

The phrase “root cause” can mislead, because it suggests a single answer waiting to be found. Real problems usually have several contributing factors. The methods below are best seen as ways of organising a search and a discussion, not as machines that output the truth.

Start by describing the problem

Any technique works better when the problem statement is specific. Compare “the pump failed” with “the pump stopped delivering flow during the second shift, after about two hours of operation, on two of the last five days”. The second version contains facts that narrow the search: when, how often, under what conditions.

Gather evidence before theorising. Useful items include timelines, logs, measurements, photographs of failed parts, the state of settings, and accounts from the people involved. Keep evidence separate from interpretation, and note what is unknown.

Technique 1: asking why repeatedly

This method, often called the five whys, starts with the problem and asks why it happened, then asks why about each answer, continuing until the answers point at something the team can change. Five is a rough guide, not a rule: sometimes three questions are enough and sometimes more are needed.

An illustrative chain for a hypothetical production issue:

1. Why did the batch fail inspection? The labels were misaligned.
2. Why were they misaligned? The label roll shifted during the run.
3. Why did it shift? The roll was loaded without the guide fully locked.
4. Why was the guide not locked? The step is not on the loading checklist.
5. Why is it not on the checklist? The checklist was written for an earlier machine and not updated.

The chain ends with something actionable: update the checklist. Had the analysis stopped at the first or second answer, the likely response would have been to blame the operator or re-run the batch.

Strengths

• It needs no special tools and works in a short meeting.
• It encourages looking past the immediate trigger.

Pitfalls

• Chains are linear, so they can miss problems with several parallel causes.
• Answers depend on the knowledge of the people in the room. A different group might reach a different chain.
• It is easy to stop at a person (“operator error”) instead of the conditions that made the error likely. The habit of asking why people acted as they did is central to blameless reviews.
• It can be steered to a predetermined answer if facilitators are not careful.

Technique 2: cause-and-effect diagrams

A cause-and-effect diagram, often called a fishbone or Ishikawa diagram, puts the problem at the head of a horizontal spine and draws branches for categories of possible causes. Group names vary between industries. A common set for manufacturing is people, methods, machines, materials, measurements and environment, and teams are free to choose categories that suit their problem.

For each branch, the team brainstorms possible causes and attaches them as smaller branches, then asks why again for the most plausible ones.

Strengths

• It shows many possible causes at once, which counters the tendency to fix on one explanation.
• It is a good group exercise, since each person can contribute from their own experience.
• The picture becomes a shared record of what has been considered.

Pitfalls

• It lists possibilities, not evidence. A branch on the diagram is a hypothesis until tested.
• Diagrams can become large and unfocused.
• The categories can encourage filling every branch whether or not it is relevant.

Technique 3: timelines and change analysis

For problems that appeared suddenly, a timeline of events and a list of recent changes can be more productive than either method above. Ask what was different between the time when things worked and the time when they did not: a new batch of material, a software update, a different operator, a change in temperature. Differences are candidates, which can then be tested one at a time where practical.

Turning candidates into causes

Brainstormed causes need verification. Useful questions include:

• Does the proposed cause explain all the observations, including when the problem did not occur?
• Can it be tested, for example by reproducing the problem with the cause present and removing it with the cause absent?
• If we fix this, what do we expect to change, and how will we confirm it?

Structured approaches to design-stage risk, such as failure modes analysis, can seed a list of likely causes, and a methodical approach to debugging strategies applies the same logic to software.

Choosing actions

Actions fall broadly into three groups: those that contain the immediate problem, those that correct its cause, and those that prevent similar problems elsewhere. Prefer changes to the system or process over reminders and warnings where practical, since reminders depend on memory. Assign each action an owner and a date, and check later that it worked. Where the problem involves safety, regulated products or legal duties, follow the procedures and standards that apply in your country and industry, which vary.

Habits that keep the analysis honest

• Keep the tone curious rather than accusatory.
• Record what is known, assumed and unknown.
• Accept that sometimes the evidence does not identify a single cause. A well-documented partial answer is better than a confident wrong one.
• Share what was learned, since other teams may have the same weakness.

This article is general background and does not replace the investigation procedures of your organisation or regulator.