5 Whys in maintenance: root cause analysis of a real failure

Replacing the broken part fixes today's downtime. Finding out why it broke is what prevents next month's, and the 5 Whys are the simplest way to start.

What the 5 Whys are

The method is to ask "why?" starting from the observed problem and, for each answer, ask again. At each level you move away from the symptom and closer to the cause that, once eliminated, stops the failure from happening again.

The number five is a guideline, not a rule. Sometimes the root cause shows up at the third why; sometimes at the seventh. The stopping point is something else: you've reached something the team can act on and that, once corrected, breaks the whole chain.

Three conditions make the analysis useful:

• A well-described problem. "The pump stopped" is vague. "Pump B-02 tripped on overcurrent at 2:10 p.m., after 40 minutes of operation" is a starting point.
• Field people in the conversation. Whoever handled the job knows what they saw. Analysis done only in the office tends to stop at hypotheses.
• Evidence for every answer. A reading, a photo, work order history, an operating log. If the answer is a guess, it has to be checked before the next why.

Complete example: the pump that kept tripping

The following case is fictional, put together to illustrate the method.

In an office building, the centrifugal water booster pump B-02 tripped three times in two weeks. Each time, the technician reset the thermal overload relay and the pump started working again. The third time, the supervisor opened an analysis.

Question	Answer	Evidence
1. Why did the pump stop?	The thermal overload relay tripped on overcurrent.	Relay found tripped; current measured above rated value after the reset.
2. Why did the current rise?	The motor was working harder than normal to turn.	Shaft hard to turn by hand, with the motor de-energized.
3. Why was it hard to turn?	The drive-end bearing was damaged.	Noise and high temperature at the bearing housing; visible play on disassembly.
4. Why was the bearing damaged?	It had too little grease, and the grease had dried out.	Dark, hardened grease found on disassembly.
5. Why wasn't it properly lubricated?	Lubrication wasn't in any preventive plan; it depended on someone remembering.	No lubrication work order for B-02 in the history of the past twelve months.

Notice the difference between levels. The first why leads to resetting the relay, which was done three times without solving anything. The third leads to replacing the bearing, which solves it for a while. Only the fifth explains why the bearing will fail again if nothing changes.

From diagnosis to action: containment, corrective and systemic

An analysis that ends without actions that have an owner and a due date was a waste of time. Split the actions into three levels:

1. Containment. What holds the problem in check right now. In the example: switch to the standby pump and monitor B-02's bearing temperature until the repair.
2. Corrective. What eliminates the defect you found. Replace the bearing, check the coupling alignment and lubricate according to the manufacturer's specification.
3. Preventive or systemic. What keeps the root cause from coming back, on this asset and on others. Create B-02's lubrication plan with a defined frequency, check whether the building's other pumps are in the same situation and add a bearing check to the inspection checklist.

The third action is the one that tends to be forgotten, and it's the one that pays off. If the same setup gap left other pumps without lubrication, the next trip is already on its way somewhere else.

Common mistakes in the analysis

Stopping at the symptom

"The relay tripped" or "the bearing broke" describe what happened; they aren't causes. If the proposed action is to replace or reset something, the analysis probably stopped too early.

Blaming the person

"The technician forgot to lubricate" ends the conversation without solving anything. Ask once more: why did it depend on his memory? The answer almost always points to a process that failed, and processes can be fixed.

Forcing a single chain

Some failures have more than one contributing cause. In the example, misalignment could also have been speeding up bearing wear. When two different answers are true for the same why, open two branches and follow both.

Not checking against data

A logical chain can be convincing and still be wrong. Each answer needs something to confirm it: a reading, an inspection, history. Without that, the analysis just formalizes the first hypothesis from whoever spoke loudest.

How to record the root cause on the work order

An analysis that lives on a sheet of paper or in a stray spreadsheet won't be found next time. Its place is the work order, with a coded failure in three fields:

• Symptom: what was observed. E.g., overcurrent trip.
• Cause: why it happened. E.g., lack of lubrication.
• Action: what was done. E.g., bearing replacement.

With fixed lists instead of free text, the same failure gets the same name on any work order, from any technician. Then the history becomes searchable: how many lubrication failures did we have this year? On which assets? Did the cause change after the plan was created?

This record also feeds your metrics. A repeat failure drags down the asset's MTBF, and a well-identified recurring cause usually cuts diagnosis time, one of the five components of MTTR.

When to use other tools

The 5 Whys work well for failures with a fairly linear cause, analyzed by a small group. In some cases it's worth stepping up:

• Ishikawa (fishbone) diagram when there are many possible causes and you need to organize them before investigating (method, machine, material, people, environment, measurement). Then each promising branch can be explored further with the whys.
• FMEA when the goal is to anticipate failures in critical equipment or systems, assessing failure modes, effects, frequency and detection before they happen.

You don't need to start with the most sophisticated option. A team that applies the 5 Whys well to repeat failures is already ahead of one that only swaps parts.

In taskfield, the work order has coded symptom, cause and action, and AI flags failures that repeat on the same asset or the same equipment family to show where an analysis is worth opening. AI suggests, your team decides.