Root Cause Analysis: Replacing the Part Again Is Not a Fix

A bearing fails. The crew replaces it, the line restarts, and the work order is closed. Six months later the same bearing fails again. Nothing was fixed, because nobody asked why the first one failed. Root cause analysis (RCA) is the discipline of asking that question properly.

This is the fourth article in our Reliability Engineering for Maintenance series. It follows reliability engineering, where bad-actor analysis told you which failures deserve this kind of attention.

What RCA is, and what it is not

RCA is a structured method for finding the underlying causes of a problem so that you can eliminate them, rather than repeat the repair. It usually finds causes at three levels:

• Physical causes: the part broke because of fatigue, overload, or contamination
• Human causes: a decision or action allowed the condition to develop
• Latent (system) causes: the procedures, training, specifications, or management practices that made that decision likely

Most real fixes live at the third level. Replacing a failed part addresses the first. Retraining one technician addresses the second. Changing the system that let it happen prevents the next ten.

RCA works on both sides of the curve

On the P-F curve, RCA is most often triggered after Point F, when something has actually failed. But it is just as valuable on the left. When a condition-monitoring route finds a defect at Point P, asking why the defect formed turns a repair into a prevention. A bearing replaced inside the P-F interval will fail again if the misalignment that damaged it is still there.

A practical process

1. Set trigger criteria. You can't analyze every failure. Define thresholds: safety events, high-cost or high-downtime failures, repeat failures on critical assets, and recurring problems on bad actors.
2. Define the problem clearly. State what happened, where, when, and what it cost, without assuming a cause.
3. Preserve and collect evidence. Keep failed parts, take photographs, record operating data, gather work history, and interview the people involved. Evidence disappears fast, and RCA done only from a conference room tends to produce guesses.
4. Build the cause-and-effect picture. Techniques such as cause trees, fishbone diagrams, and 5 Whys help organize the evidence. Each proposed cause should be backed by evidence, not just plausibility.
5. Identify root causes you can control. Keep asking why until you reach causes that your organization can actually change.
6. Define and assign corrective actions. Each action needs an owner and a date.
7. Verify the fix worked. Track whether the problem recurs. An RCA without follow-up is a report, not an improvement.

Common mistakes

• Stopping at human error. "Technician error" is rarely a root cause. Ask why the error was possible.
• A single chain of 5 Whys. Real failures usually have several contributing causes. A single thread of whys can lock in the first plausible story.
• Blame. If people expect punishment, they will hide information, and the analysis suffers.
• Actions that are only reminders. "Be more careful" and "retrain staff" are weak. Prefer changes to the design, procedure, or system.
• No closure. Many RCAs end with a presentation. The value comes when the actions are completed and verified.

Building the habit

RCA is a skill, and a culture. The plants that benefit most have a clear trigger policy, trained facilitators, a simple way to track actions, and leaders who ask about the corrective actions as often as they ask about the outage.