Root cause methods I: the five whys and fishbone diagrams

With the evidence gathered and the interviews done, Elena's team sat down to analyse. Sam Pellerin had done a root cause course years earlier at another employer and remembered one technique: ask 'why' five times. He went to the whiteboard and started. 'Why was Marie hurt? Because the forklift ran over her foot. Why? Because Jordan reversed without seeing her. Why? Because he didn't look properly. Why? Because he was rushing. Why? Because of the 3:00 truck.' He stepped back. 'So the root cause is the truck schedule.' Elena asked him to leave it on the board. 'That's one chain,' she said. 'Let's see how many others there are.'

Root cause analysis is the part of an investigation that turns evidence into explanations. There are dozens of methods, some simple and some elaborate. This lesson covers the two most widely used simple methods, the five whys and the fishbone diagram, including how to use them well and where they go wrong. Lesson 9 covers more structured methods for complex events.

What a root cause is

A root cause is usually defined as a fundamental cause that, if corrected, would prevent the incident or similar incidents from happening again, and that the organization has the ability to control. The definition has three useful parts. Fundamental means deeper than the immediate cause: the dead light, not just the collision. Preventive means fixing it actually changes the outcome. Controllable means it is something the organization can change, such as its layout process, rather than something it cannot, such as the fact that winter nights are dark.

Investigators also talk about immediate causes, which are the events or conditions directly before the harm, such as the forklift reversing into the travel aisle, and contributing factors, which made the incident more likely or worse without being enough on their own, such as the fan noise. Many experienced investigators avoid the singular 'the root cause' altogether, because serious incidents almost always have several. Elena prefers 'root causes' and expects a level 3 investigation to find more than one.

The five whys

The five whys technique is usually traced to Taiichi Ohno and the Toyota Production System, where it was used to get past symptoms to the real reason a machine stopped or a defect appeared. The method is simple: state the problem, ask why it happened, then ask why that happened, and keep going until you reach a cause that, if fixed, would prevent a repeat. 'Five' is a rule of thumb, not a requirement; some chains need three whys and some need seven.

The technique's strengths are that it is quick, needs no training or software, and naturally pushes people past the first, most obvious answer. Its weaknesses are just as real. A single chain implies a single cause, when most incidents have several. The answer depends heavily on who is in the room and what they already believe. Different teams asking why about the same incident often reach different root causes. And the chain tends to stop when it reaches a person, because 'he didn't look properly' or 'she wasn't careful' feels like an answer. Sam's chain showed every one of these problems: it followed one path, it passed through 'didn't look properly' without testing it, and it ended at a single cause that was only part of the story.

Using the five whys well

Elena teaches four rules that make the five whys far more reliable.

• Branch. At each step, ask whether there is more than one answer. Most whys have two or three. Follow each branch.
• Test each answer against evidence. Every 'because' should be supported by something the team found: a photograph, a record, a data point, an interview. If it is not, mark it as an assumption to check.
• Do not stop at a person. If an answer describes what someone did or did not do, ask why it made sense to them, using lesson 7. 'He didn't look properly' becomes 'what was he looking at, and why?'
• Stop at something fixable. Stop when you reach a cause the organization can control and that, if corrected, would prevent a repeat. Going further, to 'because the economy is competitive', does not help.

The team redid Sam's chain with the rules. 'Why didn't Jordan see Marie?' had three answers, each supported by evidence: the pallet stack blocked his sightline to the left, the blue light that should have warned her had failed, and his training told him to watch the right-hand blind spot and trust the light. Each became its own branch.

The light branch went: the light was not working because its connector corroded and froze; because cold-storage moisture got into a connector not rated for repeated temperature cycling; and the truck stayed in service with it failed because the pre-use checklist had no line for the light, and because the maintenance system marked the repair 'parts on order' without any rule about taking a truck with a failed safety device out of service. Two fixable causes at the end: the checklist and the out-of-service rule, plus a design question about the connector.

The walkway branch went: the walkway was blocked because empty pallets were stacked on it; because the pallet return area was full; because volume had grown with the new customer and nobody had resized the return area or arranged more frequent pickups; and the blockage stayed for a week because supervisors saw it as a housekeeping nuisance, not a traffic hazard, and the two near misses that pointed to it were closed with reminders. Fixable causes: the pallet return capacity, and the near-miss process.

The route branch went: a reversing truck met a walking picker at that spot because the staging lane opened straight into a pick route; because the lane was created by email without any review of traffic flow; because the management of change procedure did not cover warehouse layouts. Fixable cause: the change process.

Sam's original chain about the 3:00 truck survived too, but as one branch among several. The priority flag and the dispatcher's message added time pressure, which the team recorded as a contributing factor rather than the root cause, because the logger showed Jordan was reversing at a normal speed.

The fishbone diagram

The fishbone diagram, also called a cause-and-effect or Ishikawa diagram, was popularized by the quality engineer Kaoru Ishikawa in Japan in the 1960s. The problem is written at the head of the fish, on the right. A horizontal spine runs to the left, and diagonal bones branch off it, each representing a category of causes. Team members brainstorm possible causes in each category and write them on smaller bones. The diagram's strength is that the categories prompt people to think beyond the first idea; its weakness is that it can produce long lists of possible causes without showing how they connect or which ones actually mattered.

Different industries use different category sets. Manufacturing teams often use six Ms: manpower, methods, machines, materials, measurement and mother nature. Many safety teams prefer neutral labels, and Elena uses six: people, methods, equipment, materials, environment and management. The exact categories matter less than making sure the team looks across all of them, and especially that management and organizational factors get their own bone.

Building a fishbone well

The team built its fishbone on the whiteboard in about forty minutes. Elena's rules for fishbones are similar to her rules for the five whys. Brainstorm freely first, without arguing about whether each idea is right. Then go back through every item and mark it as supported by evidence, contradicted by evidence or not yet tested. Remove anything contradicted. Turn anything untested into a question for follow-up. Then look for items that appear in more than one category or that link to each other, because those are often root causes.

Several ideas came off the board. Someone suggested that Jordan had been on his phone; the logger and the camera showed both hands on the controls, so it was crossed out. Someone suggested the forklift's brakes might have been slow; Luis's inspection found them fine, and the logger showed the truck stopped within about half a metre of the impact, so that came off too. Testing ideas against evidence, and removing the ones that fail, is as important as finding new ones. An investigation that keeps every brainstormed idea ends up with a report that blames everything and fixes nothing.

What remained showed a pattern. The management bone held the most items, and several of them connected to items on other bones. The staging lane created without review explained the route conflict on the methods bone and the mirror pointed the wrong way on the equipment bone. The near misses closed with reminders explained why the blocked walkway on the materials bone stayed for a week. The checklist that was never updated explained why the failed light went unnoticed. Most of the causes at the sharp end traced back to a small number of decisions and processes.

Combining the two methods

The fishbone and the five whys work well together. The fishbone casts a wide net and makes sure no category is forgotten. The five whys then take each important item on the fishbone and dig into it to find the fixable cause beneath. For aisle 14, the team ran a branched five whys on the five items with the most connections. Each chain ended at a process or decision the company could change.

Neither method is perfect for complex events with many interacting factors, long chains of decisions or unclear sequences. For those, lesson 9 covers causal factor charting, which ties causes to a timeline, and barrier analysis, which focuses on the defences that failed. But for most level 2 investigations and as a starting point for level 3, a well-run fishbone followed by branched whys gets a team a long way.

Checking the chains

Elena keeps the team's why-chains in a simple structure and uses a script to check two of her rules: every link needs evidence, and no chain may end at a person's action.

# Each chain: list of (cause, evidence). The last item is where the team stopped.
chains = {
    "light": [("light did not warn picker", "photo E-02"),
              ("connector corroded and froze", "part E-07"),
              ("truck kept in service with failed light", "maintenance record"),
              ("no out-of-service rule for failed safety devices", "procedure review")],
    "walkway": [("picker in travel aisle", "camera"),
                ("walkway blocked by pallet stack", "photos, camera"),
                ("pallet return area full", "interviews"),
                ("return capacity not resized for new volume", "")],
    "sam_v1": [("driver did not see picker", "camera"),
               ("driver did not look properly", "")],
}
person_words = ("did not look", "careless", "not careful", "did not follow")
for name, chain in chains.items():
    missing = [c for c, ev in chain if not ev]
    last = chain[-1][0]
    ends_at_person = any(w in last for w in person_words)
    status = "OK" if not missing and not ends_at_person else "REVIEW"
    print(f"{name:<8} {status}")
    for c in missing:
        print(f"   no evidence yet: {c}")
    if ends_at_person:
        print(f"   stops at a person: {last}")

light    OK
walkway  REVIEW
   no evidence yet: return capacity not resized for new volume
sam_v1   REVIEW
   no evidence yet: driver did not look properly
   stops at a person: driver did not look properly

The check passed the light chain, flagged the walkway chain because nobody had yet confirmed with data that volume had outgrown the pallet return area, and flagged Sam's first chain on both counts. Grace pulled the shipping volumes that afternoon: outbound pallets had risen by about a third since the new customer started, and pallet pickups had stayed at twice a week. The walkway chain got its evidence. Sam's first chain was replaced by the three branches above.