When a problem occurs, many people rush to treat its symptoms. But the problem returns until its root cause is addressed. Root cause analysis is a structured approach for moving from the visible symptom to the cause which, once treated, stops the problem from recurring.
Symptom, direct cause and root cause
It helps to distinguish three levels:
- Symptom: the effect observed, such as a complaint, a delay or a defective product.
- Direct cause: the event that triggered the problem on this particular occasion.
- Root cause: the deeper weakness in the system, procedure or resources that allows the problem to recur.
This distinction matches two kinds of response: correction, which deals with the existing effect, and corrective action, which removes the cause to prevent recurrence. Both are needed, but it is the second that brings lasting improvement.
The 5 Whys
Born in Japanese manufacturing, this method asks "why?" repeatedly until it reaches a cause that can be acted on.
Example:
- Why was the file delivered late? Because the signature was delayed.
- Why was the signature delayed? Because the manager did not receive the file on time.
- Why not? Because the file stayed in another department.
- Why did it stay there? Because no procedure defines the file’s route and deadlines.
- Why is there none? Because the process was never documented.
The root cause is not one person’s negligence but the lack of a documented procedure.
The number five is a guide, not a rule: fewer questions may be enough, or more may be needed. What matters is that each answer is a verifiable fact rather than a guess, and that the analysis branches out when an answer points to more than one cause. The root cause can be tested with a reverse question: if this cause were dealt with, would the problem be prevented from recurring?
The fishbone diagram
Designed by Kaoru Ishikawa, it sorts possible causes into categories, most commonly the six known as the "6M":
- people
- methods
- machines and equipment
- materials
- measurement
- environment
The effect is written at the "head of the fish" and the causes branch out along its bones; the team then picks the most likely ones and checks them with data. In service organizations the categories can be adapted, for example to policies, procedures, people and place, to suit the nature of the work.
The diagram is best built in a group session with the people who work in the process, and causes should be stated as specific facts rather than vague phrases such as "lack of care", which lead to no action.
Complementary tools: fault tree analysis and 8D
- Fault tree analysis: starts from the undesired event at the top of the tree and breaks it down into the events that could cause it, using logic gates: "AND" when several events must occur together, "OR" when any one of them is enough. It suits complex or high-severity problems.
- The 8D method (eight disciplines): a team-based problem-solving framework that moves through forming the team, describing the problem, containing it temporarily, identifying the root cause, choosing corrective actions, implementing and validating them, preventing recurrence, and finally recognizing the team’s effort.
Worked example: delayed test results in a hospital department
A hospital department notices that some laboratory results arrive late, delaying treatment decisions. The team draws a fishbone diagram that brings out many possible causes: transporting samples between the department and the laboratory, shift handovers, no system for setting priorities, labelling errors, and times not being recorded in a consistent way.
Instead of adopting the most widely held opinion, the team records for each sample the time it was taken, the time it reached the laboratory and the time the result was issued. The data show that the delay is concentrated in the transport stage, especially at shift changes. Asking successive "whys" reveals that sample transport follows no set schedule, and that each shift relies on whichever staff member happens to be available.
The solution was not to blame individuals but to set regular transport rounds, with a clearly designated person responsible on each shift, then to track arrival times for several weeks to make sure the improvement holds.
Practical steps for a successful analysis
- Describe the problem precisely: what is happening, where, when and to what extent, without assuming the cause in advance.
- Contain the effect temporarily to protect users while the analysis is completed.
- Form a small team including people who know the process at first hand.
- Gather facts and data, and observe the process where it takes place.
- Review possible causes with a fishbone diagram, then dig into the most likely ones with the 5 Whys.
- Verify the cause with data before accepting it.
- Implement the corrective action, check that it works, then build the new method into the written procedures.
Pitfalls to avoid
- Stopping at the first easy answer.
- Turning the analysis into a search for someone to blame.
- Relying on opinion without checking the data.
- Settling on a single cause when several combine.
- Confusing immediate correction with corrective action.
- Closing the case without checking that the problem does not return.
The root cause is rarely a person; it is usually a system or procedure that lets the error happen again.
