This informal CPD article ‘Solving the Right Problem - Why Root Cause Analysis Is the Most Undervalued Skill in Business’ was provided by Anexas, a global organization for training and consulting. They have a network of attached professionals and organizations catering to diverse industries.
There is a particular kind of meeting that happens in almost every organisation, in every sector, on a daily or weekly basis. A problem is raised. Discussion follows. Someone proposes a solution, usually quickly, usually based on experience, usually with confidence. The solution is implemented. The problem goes away. Two months later, the same problem, or something very similar, is back on the agenda.
This cycle is so familiar that many professionals have come to accept it as the normal way that organisations work. It is not. It is the expected result of one of the most common mistakes in professional practice: fixing the symptom instead of the cause. And this failure is almost completely avoidable, unlike many others.
The Difference Between a Symptom and a Cause
When a patient visits a hospital with a headache, the headache is the symptom. A painkiller addresses the symptom. What the clinical team needs to find out is what is actually causing it, because the answer might be dehydration, high blood pressure, a neurological condition, or any other reason. The treatment for each cause is completely different. It is not only unhelpful to treat the symptom without addressing the cause, but in some cases, it may also be dangerous.
The same logic applies to problems in organisations as well. A spike in customer complaints is a symptom. Rising staff turnover, a pattern of product defects, repeated invoicing errors, and consistently missed deadlines are all symptoms. Each one points to different issues that lie earlier in the process. If those are not fixed, the same problems will keep coming back, no matter how many times organisations try to patch them at the surface level.
Consider a manufacturing company issuing refunds repeatedly for a particular product fault. The natural response is to improve the final quality check at the end of the production line. The fault rate goes down for a short time before going back up. This is because the check was finding problems, not preventing them. The root cause: a calibration drift in one piece of equipment, was never identified. After six months of refunds, rework, and management effort, the real problem is still exactly where it all started.
The main goal of Lean Six Sigma is to stop this from happening. The Analyse phase of the DMAIC framework (Define, Measure, Analyse, Improve, Control) is dedicated entirely to root cause. Before designing solutions or implementing any changes, practitioners must ask one question above all others: what is actually driving this problem? Not what it looks like from the outside, not what worked in a similar situation before, but what the evidence shows is happening at the source.
Why Organisations Consistently Skip This Step
Root cause analysis usually takes time, requiring data collection, structured thinking, and the ability to tolerate uncertainty rather than act prematurely. That is why, in environments where speed is rewarded and visible activity is equated with progress, this approach feels uncomfortable. There is a pressure to act quickly and visibly to a problem, often resulting in solutions that address symptoms rather than actual underlying causes.
There is also a cognitive dimension to consider here. Human beings are natural pattern matchers: They encounter a problem, they recall a similar situation, and they apply the same solution. This is efficient under routine conditions, but this approach often leads to misdiagnosis in complex or unfamiliar contexts. The problem looks familiar. The underlying cause may be different. When the familiar solution fails, teams are left confused, having done what had worked before.
Research in quality management indicates that approximately 90% of problems in any system originate from the process itself (2), by the way work is designed, resourced, and managed and not from the individuals within it. This idea, associated with the quality expert W. Edwards Deming, has very important implications for how organisations deal with failure. It means that most of the solutions organisations rely on, such as performance management, additional training, and closer supervision, all target the wrong level. The process is the problem, and the solution must be found within it.
Regression analysis identifies the variables
What Structured Root Cause Analysis Looks Like
Effective root cause analysis is not a single tool; it is a disciplined approach that uses different techniques depending on the complexity of the problem.
For simpler problems, the 5 Whys method is surprisingly powerful. By repeatedly asking "why?" in response to each answer, drilling down through layers of explanation, teams can often arrive at a root cause in minutes that might otherwise take weeks to uncover through trial and error. The discipline lies in continuing beyond the first seemingly correct answer, which is rarely the true root cause.
For more complex or multi-variable situations, teams can use cause-and-effect diagrams, often referred to as fishbone or Ishikawa diagrams, to map potential contributing factors across the 6M categories: Man, Machine, Method, Material, Measurement, and Mother Nature/Environment (3). This visual map helps prevent the common trap of focusing on obvious causes while missing out on deeper, less visible drivers.
Statistical tools help teams add another layer of confidence. Hypothesis testing allows teams to establish whether a suspected cause is actually linked to the problem, or if it just looks that way by coincidence. Regression analysis identifies the variables that actually drive outcomes and those that simply add unnecessary complexity to the model. Pareto analysis, based on the well-established principle that roughly 80% of problems typically stem from 20% of causes (4), helps teams to focus improvement efforts where they will have the greatest impact, rather than treating all the factors as equally important.
What these tools have in common is a disciplined commitment to evidence over instinct. The question of ‘what is causing this?’ must be answered through data-driven analysis rather than organisational hierarchy, recent experience, or reliance on previously implemented solutions.
The Organisational Payoff
When root cause analysis is embedded as a genuine organisational practice, its benefits compound over time. Defect recurrence rates decline. The same problems stop consuming management time year after year. Teams that once spent most of their effort firefighting begin to focus on improvement.
The financial case is equally clear. The Cost of Poor Quality — which encompasses rework, warranty claims, customer attrition, regulatory penalties, and the operational waste of firefighting (1) — is estimated to represent between 15% and 30% of annual revenue in organisations that do not systematically manage process quality. Even a modest reduction in these costs, achieved by resolving problems at their root rather than repeatedly patching their surface, produces returns that far outweigh the investment required to build the capability.
But perhaps the most important benefit is cultural, not financial. Organisations that make root cause analysis a shared discipline, where people at every level know how to define problems clearly, use reliable data, and test assumptions before acting, develop something more valuable than any single improvement project. They build the habit of asking better questions. And over time, better questions lead to better organisations.
We hope this article was helpful. For more information from Anexas, please visit their CPD Member Directory page. Alternatively, you can go to the CPD Industry Hubs for more articles, courses and events relevant to your Continuing Professional Development requirements.
References
1. American Society for Quality. Cost of Quality. ASQ Quality Resources. https://asq.org/qualityresources/cost-of-quality
2. Deming, W. E. (1986). Out of the Crisis. MIT Press.
3. Ishikawa, K. (1986). Guide to Quality Control. Asian Productivity Organization.
4. Juran, J. M. & Godfrey, A. B. (1999). Juran's Quality Handbook, 5th Edition. McGraw-Hill.
