Process Improvement First or RCA Improvements?
This decision framework helps determine whether to conduct a root cause analysis (RCA) or directly work on process improvements. If the causes of a recurring problem are unclear, RCA is recommended; if you already have hypotheses, validate them and proceed with process changes.
THE IDEA
Process Improvement First or RCA Improvements?
Choose the next step based on how well the causes are understood:
- If you and other colleagues are unsure why a problem keeps recurring, then a robust RCA analysis might help clarify the reasons for the problem, so you have a more focused way ahead.
- However, suppose you and other colleagues already have a good idea (or working hypotheses) of why a problem is happening. In that case, it may be better to work directly on the following:
- validating the facts and evidence for the causes, and then
- proposing changes to improve relevant organisational processes, projects, etc., rather than working on RCA first.
Here, we see a fundamental point about RCA: RCA tools and techniques are there to improve organisational performance and avoid setbacks but need not be an immediate top priority unless there is – for example – a specific regulatory requirement or there is a good case for improving this capability in certain areas.
If a proposed improvement meets resistance, investigate the reasons, including human factors, budget constraints, and dependencies on other activities.
Whether or not you can take ‘direct action’ improving business activities based on RCA insights, you may still want to improve RCA practice in your organisation.
When to use it
When a problem's causes are unknown and need exploration through structured RCA.
When you have strong hypotheses and want to implement quick, evidence-based process improvements.
When regulatory requirements mandate a formal RCA before any changes are made.
When organizational resistance requires understanding human factors and other constraints before taking action on process improvements.
FROM THEORY TO EVERYDAY LIFE
In practice
Manufacturing Equipment Breakdowns
A manufacturing team experiences frequent equipment breakdowns. They suspect the cause is inadequate maintenance scheduling. Instead of a full RCA, they validate this hypothesis by reviewing maintenance logs and then implement a new schedule, directly improving the process.
Software Bugs
A software team faces recurring bugs in a module. They are unsure why the bugs occur, so they conduct an RCA using fishbone diagrams and the Five Whys to identify root causes, leading to targeted code reviews and testing improvements.
A MOMENT TO REFLECT
Put it to work.
Think of a recurring problem in your work. Are you confident about its causes? Would you benefit more from an RCA or direct process changes?
What evidence do you have to support your hypotheses about a problem's root causes? How can you validate it quickly?
How do regulatory requirements or organizational resistance affect your choice between RCA and direct improvement?
Often confused with
CONTINUE THE CONVERSATION
Source texts
- Beyond the Five Whys Root Cause Analysis and Systems Thinking (James C. Paterson)