Root cause analysis for equipment failures: finding the cause you can actually fix
When a failure earns an investigation, the steps of one, how evidence is preserved, the methods and when each fits, the physical, human and latent levels of cause and why the level reached decides what the fix is worth, actions that are actually actions, and the defect elimination routine. With a free RCA template.
Key takeaways
- Root cause analysis is a structured investigation of why a failure happened, carried past the broken part and the person nearest it to the condition in the system that let it happen.
- Not every failure earns one. A site sets triggers by consequence, cost, criticality and repetition, and codes the rest on the work order.
- Causes sit at three levels: physical, human and latent. A fix at the physical level holds until the next time, at the human level until the next person, and at the latent level for everyone.
- The method matters less than the evidence. Five whys, a fishbone, a cause map or a fault tree all produce candidates that have to be tested against parts, accounts, positions and paper.
- An action is only an action if it changes a document, a design or a process, has an owner and a date, and is verified afterwards.
A bearing fails and is replaced. Three months later it fails again. The second replacement is faster, because the crew has done it before, and the third is faster still. Nobody has asked why the bearing keeps failing, and the plant is now maintaining a failure rather than a pump. Root cause analysis is the discipline that asks.
The method is not complicated, and the standards that describe it, IEC 62740 among them, are short. What makes it hard in practice is stopping too early. The investigation that ends at the broken part produces a replacement. The one that ends at the person produces a reprimand. The one that reaches the condition in the system that let the person do what they did produces a change that holds.
This guide covers when a failure earns an investigation, the steps of one, how evidence is preserved, the methods and when each fits, the three levels of cause, what makes an action real, and how the single investigation becomes a defect elimination routine. A template workbook carries the steps as sheets.
Free download
Root cause analysis template
A trigger sheet, a problem statement and timeline, an evidence register, a cause analysis that works down through the physical, human and latent levels, and an action list with verification against each line.
When a failure earns an investigation
A formal investigation costs a team several days. Done on every failure it would consume the reliability engineer and produce nothing, and done on none it leaves the repeaters in place. The answer is a trigger rule, set once, that says which events get a formal investigation, which get a short form by the supervisor, and which are coded on the work order and counted.
The thresholds below are a starting shape, not a standard. A site sets its own values from what a lost hour and a repair cost mean to it. The one trigger that should be on every list is repetition, because a failure that recurs inside its planned interval is the plant announcing that its maintenance strategy is wrong, and the bad actor list is where those announcements collect.
| Trigger | Threshold | Response |
|---|---|---|
| Safety | Any injury, or a near miss with the potential for a serious one | Formal, within 48 hours |
| Production | Lost production above an agreed value, or an outage above an agreed length | Formal, within a week |
| Repeat failure | The same failure mode on the same equipment twice within its planned interval | Formal, from the bad actor list |
| Cost | Repair cost above an agreed value | Formal |
| Critical equipment | Any functional failure of equipment rated high criticality | Short form by the supervisor, escalated if a latent cause is suspected |
| Everything else | Below every threshold | Failure coded on the work order, no investigation |
The steps
An investigation runs in the order below, and the order matters. Evidence is preserved before the analysis starts, because the analysis will want it and the plant will have thrown it away. The problem is defined before the causes are sought, because a team that starts with a cause in mind finds it. Actions are chosen after the latent cause is reached, not at the first plausible answer.
| Step | What it does | What it produces |
|---|---|---|
| Trigger | Decide whether this event earns an investigation, by its consequence or because it keeps recurring | A go or no-go against the trigger rule, with the level of effort |
| Define | Write the problem statement: what, where, when, how much, and what it is not | One paragraph everyone on the team agrees describes the event |
| Preserve | Keep the parts, the people's accounts, the positions and the paper before they are lost | Evidence listed with where it is held |
| Timeline | Lay out what happened in order, with sources, back to the last time the equipment was known to be right | A sequence with gaps marked, each entry traceable to evidence |
| Analyse | Work from the event to the physical, human and latent causes with a method that fits the event | Cause chains that evidence supports, and the ones that were ruled out |
| Act | Choose actions at the latent level that remove or control the cause, each with an owner and a date | An action list that changes a document, a design or a process, not a person |
| Verify | Check that each action was done and that the failure has not recurred over an agreed period | The investigation closed with evidence, or reopened |
Define the problem, then preserve the evidence
The problem statement is one paragraph that says what happened, on which equipment, when, how much it cost or lost, and what it is not. The last part is underused. Stating that the failure was on the number two pump and not on the identical number one pump, which runs the same duty, is already an analysis step. A team that agrees the statement before it starts tends to stay on the event rather than drifting to every grievance about the plant.
Evidence is anything the analysis will need, and the useful list is four Ps. Parts: the failed component, kept and tagged, not thrown in the scrap bin or sent back for warranty before anyone has looked at the fracture face. People: accounts from those who were there, taken early and separately, before the story settles into one version. Position: where things were, photographed, measured and sketched before the area is cleaned up. Paper: the work orders, the checklists, the alarms and trends from the historian, the permits and the procedures as they were on the day.
The timeline is then built from the evidence, back to the last time the equipment was known to be right, with a source against every entry and the gaps left visible. Most causes live in the gaps.
The fracture face in the scrap bin was the evidence. Keep the part before you start the meeting.
The methods, and when each fits
There are many named methods, and arguments about which is best miss the point. Each is a way of generating candidate causes and arranging them so the team can see what it does and does not know. None of them produces a finding on its own. Every candidate is tested against the evidence, and a candidate the evidence cannot support is recorded as ruled out, which is as useful as a cause confirmed.
The table gives the common methods, the events each suits and where each stops short. For most equipment failures, a cause map or a fishbone to collect candidates, a failed-component analysis to say how the part actually failed, and the three levels below to make sure the investigation goes deep enough, is a sound combination.
| Method | Fits | Where it stops short |
|---|---|---|
| Five whys | Simple events with one chain of cause, run by a supervisor in an hour | Follows one path and stops where the questioner's knowledge stops. Use it as the first pass, not the finding |
| Cause and effect (fishbone) diagram | Collecting every candidate cause across people, method, machine, material, measurement and environment | Produces candidates, not causes. Each branch still has to be tested against evidence |
| Cause mapping | Events with several contributing causes that combine, which is most equipment failures | Needs a facilitator and evidence for every link, or it becomes a drawing of opinions |
| Fault tree analysis | Failures of protective or redundant systems, where logic gates say which combinations cause the top event | Heavy for a single mechanical failure. Reserve it for safety and protection systems |
| Barrier analysis | Safety-related events, asking which barriers should have stopped it and why each did not | Assumes the barriers were defined. If they were not, that is itself the finding |
| Failed-component analysis | Any event with a broken part: fracture faces, wear patterns and deposits say how it failed | Says how the part failed, not why it was allowed to. Pairs with the methods above |
Physical, human and latent
Every equipment failure has a cause at three levels. The physical cause is the component or condition that failed, in engineering terms: the bearing seized because its lubricant was starved and the cage fractured. The human cause is the action or omission that produced it: the bearing was greased with the wrong grease at twice the quantity. The latent cause is the condition in the system that let that action happen: the job plan names no grease and no quantity, and the store stocks two greases in the same cartridge.
The figure shows why the level reached decides what the fix is worth. Replacing the bearing holds until the next time. Retraining the tradesperson holds until the next tradesperson. Putting the grease and the quantity on the job plan, and separating the cartridges, holds for everyone, every time. Investigations that stop at the human level are the most common failure of the method, because human error is easy to find and comfortable to blame, and it is almost never the end of the chain.
Level 1
Physical cause
Why?
Pump bearing seized: lubricant starved, cage fractured
Fix here
Replace the bearing
Holds until the next time
Level 2
Human cause
Why?
Bearing greased with the wrong grease at twice the quantity
Fix here
Retrain the tradesperson
Holds until the next person
Level 3
Latent cause
Why?
The job plan names no grease or quantity; the store stocks two greases in the same cartridge
Fix here
Put grease and quantity on the job plan, one grease per cartridge colour
Holds for everyone, every time
- ↓ Keep asking why until the answer is a document, a design or a process
| Level | What it is | A fix here | Holds |
|---|---|---|---|
| Physical cause | The component or condition that failed, in engineering terms | Replace the bearing | Until the next time |
| Human cause | The action or omission that produced the physical cause | Retrain the tradesperson | Until the next person |
| Latent cause | The system condition that let the action happen: a missing standard, a bad job plan, a store that issues the wrong product | Put grease and quantity on the job plan, one grease per cartridge colour | For everyone, every time |
If the finding is that someone made a mistake, the investigation is not finished. Ask what let the mistake be made.
Actions that are actually actions
An action list is where most investigations lose their value. Reminded the crew, raised awareness and will monitor are not actions, because nothing in the plant is different the week after. An action changes a document, a design or a process: a job plan rewritten, a spec added to the bill of materials, an interlock fitted, a store layout changed, a task added to or removed from the preventive program. It has an owner, a date, and a way of verifying it was done.
Actions are chosen at the latent level and ranked by how little they depend on people remembering. A design change that makes the wrong grease impossible to fit beats a label, which beats a line in a procedure, which beats a toolbox talk. Each is better than nothing, and the ranking says which to prefer when there is a choice.
Verification closes the investigation, and it has two parts. That each action was done, with evidence. And that the failure has not recurred over an agreed period, read from the failure codes on the work orders. An investigation whose failure recurs is reopened, not filed.
From one investigation to defect elimination
A single investigation fixes one failure. A defect elimination routine decides which failures get investigated, tracks the actions and measures whether the failures stop. It runs from the failure codes recorded on every closed work order, ranked by cost or lost production into a bad actor list, which the trigger rule then reads. The maintenance KPIs guide places the bad actor list among the measures that are read together.
The routine is a monthly meeting with a short agenda: the bad actor list, the investigations open and their actions overdue, the failures that have recurred after an investigation closed, and the one or two new investigations to open. Over a year it moves the maintenance effort from repairing failures to removing them, which is the only way a corrective backlog comes down for good.
Where investigations fail
- Stopping at the broken part, which produces a replacement.
- Stopping at the person, which produces blame and the same failure with a different name on it.
- Starting with a cause in mind, which the team then finds.
- Evidence thrown away before anyone looked at it: the part scrapped, the area cleaned, the trend overwritten.
- Candidates recorded as causes without being tested against evidence.
- Actions that change nothing in the plant: reminders, awareness, monitoring.
- No verification, so the actions are assumed done and the recurrence is a surprise.
- Investigating everything, so the engineer is consumed and nothing is finished.
Common questions
What is root cause analysis?
A structured investigation of why an event happened, carried past the obvious cause to the conditions that allowed it, so that the actions taken stop it recurring rather than repair it once. For equipment failures it works down through three levels: the physical cause, the human action or omission behind it, and the latent cause in the system, such as a missing standard, a bad job plan or a store that issues the wrong part. IEC 62740 is the international standard for the method.
When should a root cause analysis be done?
When the consequence or the repetition justifies the effort. Most sites set triggers: any injury or serious near miss, lost production or repair cost above an agreed value, any functional failure of high criticality equipment, and the same failure mode recurring on the same equipment inside its planned interval. Failures below every threshold are failure coded on the work order so they can be counted, and the bad actor list brings the repeaters back into scope.
What is the difference between a root cause and a contributing cause?
A root cause is a condition that, had it been removed, would have prevented the event, and that the organisation can change. A contributing cause made the event more likely or worse without being sufficient on its own. Most equipment failures have several of each, which is why a single chain of whys tends to find one path and miss the rest.
What are the five whys?
A questioning method that asks why an event happened, then why that answer happened, and so on, usually five times, until the answer is something the organisation can change. It is quick and needs no training, which is its value for simple events. Its weakness is that it follows one chain, stops where the questioner's knowledge stops, and offers no test of whether each answer is true. It is a good first pass and a poor final finding.
What should an RCA template include?
A trigger check, a problem statement that says what happened, where, when, how much and what it is not, a timeline with a source against each entry, an evidence register, the cause analysis worked through the physical, human and latent levels, the actions with owners, due dates and the change each makes, and a verification record. The template offered with this guide carries those as sheets.
What is defect elimination?
The program that uses failure data and root cause analysis to remove the causes of recurring failures, usually starting from a bad actor list of the equipment or failure modes that cost the most. Where root cause analysis is a method for one event, defect elimination is the routine that decides which events get it, tracks the actions and measures whether the failures stop.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- IEC 62740:2015 Root cause analysis (RCA) (IEC)
- ISO 14224:2016 Collection and exchange of reliability and maintenance data for equipment (ISO)
- Root cause analysis guidance document, DOE-NE-STD-1004-92 (US Department of Energy)
- Best practices, metrics and guidelines for maintenance and reliability (SMRP)
- ISO 55001:2024 Asset management system requirements (ISO)
Related case studies and tools
- Weibull Reliability Calculator (tool)
- Reliability engineering and asset strategy program (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.