Looking for a List of Root Cause Categories? Rethink Your Approach
Clients often ask us for a list of standard root cause categories. I understand the impulse to seek out such a resource. Categorizing root causes seems like a logical step toward understanding trends and driving improvement. A pre-built list feels like it could save time and reduce debates over how to organize data.
But whether companies create their own root cause categories or use ones built into software systems, we’ve found that they don’t get much value out of tracking root causes as a data point. Analyzing incident data is a smart way to identify trends, but root cause categories aren’t the best tool for the job.
Why Root Cause Categories Fall Short
It’s not hard to find a list of root cause categories. You can find them in problem-solving tools such as fishbone diagrams. Many software systems come preloaded with options like “procedure not followed,” “equipment failure,” and “improper training.” A quick Google search for “root cause categories” will also yield plenty of results.
The problem isn’t a lack of categories, it’s that they’re generic and not actionable. Imagine running a report for incidents from 2024 and seeing that 25% were categorized as procedure not followed, 40% equipment failure, 20% improper training, and 15% environmental factors. What can you do with that information? Other than making a colorful pie chart for management, not much. If 40% of incidents have a cause category of equipment, what specific actions should the company take? Overhaul all the equipment? Upgrade all the equipment?
It reminds me of a time earlier this year when I met with a client’s leadership team. On the call, they pulled up their dashboard of incidents categorized by root cause. The number-one root cause? “Other.”
The problem with root cause categories mirrors the flaws of labeling a single “root cause” in an incident, but on a larger scale. Incidents involve multiple factors. Unclear procedures, equipment issues, gaps in training, and environmental challenges might all contribute to the same event. Yet, if your system forces you to select just one root cause, you're left making an arbitrary choice that oversimplifies the problem and limits the solutions you can apply to prevent similar issues.
Root cause categories tend to fall short of helping you identify specific actions. Even standardized root cause sub-categories don’t often help the situation, because they’re also generic and not actionable.
A Better Approach: Categorize Incidents by Process
Since all incidents begin with a breakdown in processes, my proposal is instead of categorizing incidents by root causes, shift your focus to work processes such as lockout/tagout (LOTO), management of change (MOC), and pre-job planning. Process categories highlight patterns that root cause categories won’t catch, and they help pinpoint improvement opportunities you can apply across the entire company.
If you run your incident report and see that 25% involved the LOTO process, for example, that’s a clear signal of an opportunity in LOTO. To improve LOTO, you could do a deep dive into the process with the people who do the work—when it goes well and when it doesn’t—to identify lessons learned and best practices. By learning from the people who perform the process, you’re able to identify targeted actions such as updating LOTO instructions with specific details for different types of equipment and introducing a checklist system to confirm all LOTO steps are completed.
Stuck with Root Cause Categories? Here’s My Workaround
Analyzing incident data by process just makes sense. The goal of analyzing trends across multiple incidents is to improve reliability and performance. You do that by improving work processes, so why wouldn’t you use work processes as your categorization system?
Unfortunately, many people are stuck categorizing incidents by root causes, whether they like it or not. Your software might not support process-based categorization, or you might not have the authority to make the change. If you’re in this situation, here’s my advice:
Categorize incidents by the "root cause" that best aligns with the solution offering the most significant impact to your business. For example, if a recurring issue ties back to both training and outdated equipment, and upgrading the equipment will yield the most improvement, select "equipment failure" as your category. While this approach isn’t perfect, it prevents categorization from impeding your investigation and still maintains efficiency and the benefits that come with Cause Mapping® root cause analysis.
At the end of the day, the goal isn’t to check boxes or make pretty charts—it’s to solve problems and prevent incidents. Whether you can shift to process-based categorization or must make do with existing root cause categories, be sure there’s a purpose behind your categorization approach.
