I’ve been thinking lately about human error in root cause analysis (RCA), and whether we sometimes stop our investigations a little too early. There’s a growing argument that it shouldn’t. And I understand why.
We’ve all seen investigations where something goes wrong, someone makes a mistake, and the conclusion is that the person needs more training. The report gets completed, corrective actions are assigned, and everyone moves on. Then, a few months later, the same thing happens again. So, what did we actually fix?
I agree that blaming someone for making a mistake doesn’t tell us much about why the failure happened. But I’m also not convinced that we should completely remove human error from the discussion.
I think the bigger problem is that we sometimes treat human error as the final answer, when it should be the beginning of a much more interesting conversation.
There’s Usually More to the Story
Let’s say a maintenance technician installs a component incorrectly, and shortly after the equipment returns to production, it fails.
The obvious conclusion is that the technician made a mistake. Fair enough. But why?
Was the technician properly trained? Were the instructions clear? Did they have the right tools? Was the job rushed because production needed the equipment back? Was the component difficult to install correctly in the first place?
And perhaps just as importantly, was there anything in the process that could have caught the mistake before the machine went back into service?
These aren’t questions we’re asking to excuse poor workmanship. We’re asking them because we want to understand what really happened. Maybe the technician wasn’t trained properly, maybe the procedure was outdated, and maybe the equipment design made the mistake surprisingly easy to make. Or perhaps all the necessary controls were in place, but someone chose not to follow them.
Each possibility leads us somewhere different. That’s why I believe a good Root Cause Analysis needs to go beyond identifying the last person who touched the equipment.
Let’s Take a Simple Maintenance Example
Imagine a technician forgets to lubricate a critical bearing during preventive maintenance. A few weeks later, the bearing fails. We investigate, discover that the lubrication task was missed, and record human error as the root cause.
The corrective action? Retrain the technician. Problem solved, right? Well, maybe not. What if the lubrication point was difficult to reach? Or perhaps the PM instructions didn’t clearly identify it. What if the technician was interrupted halfway through the job?
Now suppose we discover that the PM was written years ago and never updated after an equipment modification. That raises another question. Why wasn’t it updated?
Perhaps there’s no clear process for reviewing preventive maintenance tasks when equipment changes.
Suddenly, what started as a technician forgetting to lubricate a bearing has led us to a weakness in the maintenance management system. And that’s where the investigation becomes useful. It’s also why I believe regularly reviewing preventive maintenance programs is so important. A maintenance plan should evolve as we learn more about the equipment.
Of course, we shouldn’t assume that every missed task is caused by a system failure. We need evidence to support our conclusions. But if we simply retrain the technician without addressing an incomplete PM or a poorly designed process, there’s a good chance we’ll see the same problem again.
The purpose of Root Cause Analysis isn’t just to explain why something failed. It’s to help us prevent it from happening again.
But Someone Is Responsible for the System, Right?
Here’s where I think the conversation gets a little more complicated. We often hear that we shouldn’t blame the individual, but instead look at the system. I agree with that approach, to a point.
After all, systems don’t design, maintain, or improve themselves. People make decisions about training, procedures, equipment, materials, maintenance strategies, and the resources available to do the work. When a technician wasn’t trained, someone should have made sure the necessary training was provided. Similarly, if a procedure was inadequate, someone was responsible for developing and maintaining it. The same applies to material selection. If the wrong material was selected, there were decisions and approval processes behind that selection, and if a known risk wasn’t addressed, we need to understand why.
Does that mean we should simply move the blame from the technician to the manager? Absolutely not. A manager might have been working with limited resources, unclear responsibilities, or a process that didn’t make the problem visible. We need to understand those circumstances too.
There’s a big difference between identifying who was responsible for a decision and deciding that person is guilty of causing the failure. To me, that’s one of the most important things to get right in an investigation. This is one reason I put so much importance on consistent leadership practices and daily management. Clear responsibilities and regular follow-up can help us identify weaknesses before they lead to failures.
Accountability should be based on facts, not on finding someone to blame.
Human Error and System Problems Can Exist Together
I think we sometimes make this discussion more complicated by treating it as a choice between two explanations.
Either a person made a mistake, or the system failed.
But why can’t both be true?
A technician might make an incorrect decision while working with confusing instructions. An operator might miss a warning because the alarm system is poorly designed. Someone might skip a step because the task is unnecessarily complicated or they’re under pressure to finish quickly.
The human action is still part of what happened. But so are the conditions that influenced it.
And sometimes, after a proper investigation, we might find that someone knowingly ignored a clear and effective procedure, despite having the training, tools, and time to follow it.
We shouldn’t ignore that possibility either.
Creating a learning culture doesn’t mean removing accountability. It means understanding the difference between an honest mistake, a poor decision, and a deliberate violation.
If we want people to report problems openly and participate in investigations, they need to trust that the process is fair.
At the same time, everyone needs to understand that their decisions and actions matter.
I don’t see those two ideas as contradictory.
What Does This Mean for Maintenance and Reliability?
For anyone working in maintenance, this discussion has a very practical side. When equipment fails, it’s easy to focus on the broken component. We replace it, get the machine running, and move on.
But what caused the component to fail? Was it the operating condition? The maintenance strategy? The quality of the previous repair? A design issue? Or something that was missed during planning or inspection? The same thinking should apply when people make mistakes.
Instead of immediately recommending more training, we should look at how the work was organized and whether the process made it easy to do the job correctly. Sometimes the answer really is training. But other times, a clearer procedure, better tooling, improved equipment access, or an additional verification step might make a much bigger difference.
I particularly like the idea of making the correct action easier and the incorrect action harder. For example, if a component can be installed in the wrong orientation, could we change the design so it only fits one way? If a maintenance task is frequently missed, could we improve the job plan or introduce a simple verification step?
These kinds of improvements don’t depend entirely on people remembering to be careful every single time. And that’s important because, no matter how experienced or well-trained we are, we’re still human.
How Do We Know We’ve Done a Good RCA?
I think there are three questions worth asking before closing any Root Cause Analysis:
Do we understand what actually happened, including the immediate causes? Have we identified the conditions and decisions that contributed to the failure? Have we made changes that address those causes, and do we have a way to verify that the changes work? That last question is especially important.
I’ve seen how easy it is to complete an investigation, assign corrective actions, and consider the job finished. But closing an action in a system doesn’t necessarily mean we’ve eliminated the problem. If the same failure happens again six months later, we need to ask ourselves whether our corrective actions were effective. And this is where leadership becomes part of the conversation.
The people closest to the equipment often have valuable insight into what makes a job difficult, where procedures fall short, and what could be improved. We need to involve them, listen to their experience, and make it easier for them to speak up.
But leaders also need to be willing to question their own decisions, priorities, and processes. Sometimes the investigation leads us to a technical issue, sometimes to a training gap, and sometimes to something in the way the organization is managed.
And finding the problem is only half the job. We still need to make sure the corrective actions actually work. That’s where effective daily management makes a difference. It’s not enough to assign an action and consider it done. We need to follow up and see whether we’ve actually solved the problem.
We have to be prepared to follow the evidence wherever it takes us.
So, Is Human Error a Root Cause?
My answer is that it depends on what we mean by root cause and what the investigation actually reveals.
I don’t think we should ignore human error. It’s often an important part of understanding how a failure happened. But I also don’t think writing ‘human error’ in an RCA report tells us enough to prevent the next failure.
We need to understand why the error occurred, what conditions contributed to it, and what could have prevented it or reduced its consequences.
That might involve equipment design, maintenance procedures, training, work planning, supervision, or management decisions. Quite often, it’s a combination of several things.
And yes, sometimes individual choices and accountability will be part of the answer.
The important thing is that we reach those conclusions through a proper investigation, not through assumptions.
For me, a good Root Cause Analysis isn’t about finding someone to blame or producing a report that looks complete. It’s about learning something useful and making a change that improves reliability. Because if our only corrective action is to tell people to be more careful, we probably haven’t learned enough.
Maybe the better question isn’t ‘Who made the mistake?’ but ‘Why was the mistake possible, and what can we do to prevent it from happening again?’
I’d be interested to hear what others think. Should human error ever be recorded as a root cause, or should it always lead us to investigate further?
For more thoughts on maintenance, reliability, and leadership, feel free to connect with me on LinkedIn.
