Root cause analysis, when the cause is a person
Why honest RCA must move beyond technical symptoms and name the role, control and ownership that allowed the failure to repeat
By Salman Ahmad Siddiqui | Governance-Led Operational Transformation | Operational Excellence | RCA | SLA Discipline
Main infographic: RCA becomes valuable when it moves from comfortable language to accountable closure.
Executive Summary
Root cause analysis is often misunderstood as a troubleshooting technique. In reality, it is the operating discipline that separates fixing what broke from fixing what allowed it to break. This distinction matters because organizations can restore an incident quickly and still leave the cause alive. When the same failure returns, the problem is rarely that the team did not know the RCA method. The problem is usually that the final cause was softened before it reached accountability.
Most operations teams already know the mechanics:
Five-Why,
Fishbone,
Pareto analysis,
Corrective action planning,
Owner assignment and
Closure review.
The analytical method is not the difficult part. The difficult part begins when the root cause is no longer a machine, supplier, spare, SOP or alarm. It begins when the analysis reaches a person, a role, a supervisor, a manager, a shift lead or a second-line control that did not operate as intended.
This article preserves that central argument. RCA fails not because the tools are weak, but because organizations often become uncomfortable when the cause field needs to name a role. They write 'escalation matrix to be reviewed' instead of 'the escalation had no owner and the shift lead did not check it.' Both may sound true. Only one changes the operating system.
1. RCA Is Not Troubleshooting
Troubleshooting restores the immediate service.
RCA protects the future service.
Troubleshooting asks, 'How do we bring it back?'
RCA asks, 'What allowed this condition to exist, escape detection, repeat, or reach the customer?'
In high-pressure operations, these two activities are often merged because leaders are under pressure to close incidents quickly. But the organization pays heavily when closure is mistaken for correction.
A failed rectifier, delayed turnaround, missed SLA, repeated alarm, poor handoff or site-level breach may all have immediate technical explanations. The rectifier failed. The ticket was delayed. The handoff was missed. The escalation did not happen. But these are symptoms unless the analysis goes deeper. What allowed the maintenance interval to be missed? Who owned the escalation threshold? Why was the breach not detected earlier? Why did the previous corrective action not prevent recurrence?
The return on RCA comes from discipline. It stops leaders from distributing effort evenly across problems that are not evenly expensive.
- A Pareto cut reveals that a small number of causes usually produce a large share of the loss.
- A fishbone map prevents the team from reducing a complex failure to one convenient explanation.
- Five-Why forces the team to travel from visible symptom to operating design.
Together, these tools can become the highest-return discipline available to an operations head.
Illustrative Pareto chart: RCA effort should focus on the vital few causes creating most of the loss.
2. The Fifth Why Nobody Writes Down
The mechanics of RCA work cleanly when the cause is technical. Ask why five times about a failed rectifier and the team may reach a maintenance interval, equipment specification, supplier quality issue, spare availability problem or preventive maintenance gap. These causes are relatively easy to write. Nobody feels personally exposed by a maintenance interval. Nobody becomes defensive when a supplier specification is named.
The same method becomes harder when the failure is behavioural or managerial. Ask why five times about a repeatedly missed turnaround and by the third or fourth step the analysis often moves away from process and starts describing a person who did not do something. A role did not own the escalation. A supervisor did not check closure. A shift lead did not confirm the handoff. A manager did not challenge a repeated exception. This is the moment where many RCA documents quietly step back.
Instead of writing the operational truth, the cause field becomes safer. 'Escalation matrix to be reviewed.' 'Communication gap observed.' 'SOP adherence issue.' 'Training to be conducted.' These sentences are familiar, but often incomplete. They describe an organizational smell without naming the control that failed. The result is a finding that sounds professional but cannot be assigned with precision.
That is the fifth why nobody writes down. It is the point where the method reaches human accountability and the organization chooses comfort over clarity.
Infographic: the fifth why is where technical RCA often reaches role-level accountability
3. Soft Findings Do Not Remove Causes
Soft RCA language is attractive because it keeps the meeting calm. It avoids naming a role. It avoids naming the missing decision right. It avoids identifying who should have checked, escalated, challenged or closed. It keeps everyone comfortable in the room, but it leaves the failure mechanism alive in the operation.
Consider the difference between two sentences:
- The first says, 'Escalation matrix to be reviewed.'
- The second says, 'The escalation had no named owner and the shift lead was not required to confirm handoff within the breach window.'
- The first sentence creates a discussion.
- The second creates a control.
- The first can be closed by circulating a document.
- The second requires an authority matrix, a time trigger, a named owner, evidence capture and review discipline.
This is why repeat faults survive competent analysis. The analysis may have been technically correct, but the conclusion was softened at the last step. Once softened, it could not be assigned to anybody. Once it could not be assigned, the corrective action became generic. Once generic, it did not remove the condition that allowed the failure to repeat.
A cause field that is never allowed to name a role is not a cause field. It is a record of the organization’s discomfort. That discomfort is understandable, but it is expensive.
Illustrative graph: RCA findings often become less explicit as they move toward role-level accountability
Data table: soft RCA language versus honest, useful RCA language.
4. Naming a Role Is Not Blame
The most important distinction in human-linked RCA is the difference between blame and accountability.
Blame is retrospective and personal. It asks, 'Who failed?'
Accountability is prospective and structural. It asks, 'Which role had the control, what was the expected behaviour, and what must change so the failure does not repeat?'
This distinction is easy to state and hard to hold during a review meeting. The moment a role is named, some participants may hear accusation. That is why the distinction cannot depend only on the temperament of the person chairing the meeting. It must be built into the RCA format. The form must permit role naming. The governance rhythm must expect it. The corrective action format must require owner, date, evidence and effectiveness check.
A mature RCA does not say, 'Amit failed to escalate.' It says, 'The shift lead role did not have a defined escalation trigger for this condition; the duty supervisor did not have a closure-verification checkpoint; and the NOC handoff did not require acknowledgement within a defined time.' This is not personal blame. This is the design of operating control.
When the role is named properly, the organization can fix the control instead of attacking the person. It can rewrite decision rights, revise escalation thresholds, add a supervisor checkpoint, automate alert acknowledgement, introduce breach-linked retraining, or change the review cadence. That is the value of accountability.
Infographic: role-based accountability must be separated from personal blame.
5. How to Keep RCA Honest
The fix is structural rather than cultural. Culture follows what the format permits. If the RCA template never asks for the role that owned the control, people will not write it. If the template allows only department names, accountability will remain diffuse. If corrective actions can be assigned to a quarter rather than a date, closure will drift. If repeat incidents are treated as fresh incidents rather than failed previous RCA, the organization will keep analyzing the same failure under different headings.
A practical RCA governance system should ask four hard questions. First, does the cause field allow a role to be named, and is it actually filled that way when appropriate? Second, is a repeat of the same fault treated as failure of the previous RCA, not as a new incident? Third, is the corrective action tied to a named owner and date, or to a department and a quarter? Fourth, does anyone check later whether the action taken actually removed the cause?
These questions change the quality of RCA immediately. They move the conversation from vague improvement intent to operational specification. The output is no longer 'training to be conducted' but 'breach-linked retraining for shift leads on escalation trigger X, completion by date Y, effectiveness checked by supervisor Z through next four incidents.' The first sounds active. The second is governable.
Data table: RCA form specification that keeps analysis honest.
6. The Pareto Does the Rest
Once the RCA process becomes honest enough to write causes clearly, Pareto analysis becomes powerful. A small number of causes are usually producing most of the operational loss, and they are almost always the causes the current process is least comfortable writing down. That is why the Pareto must not only rank technical causes. It must also rank repeat behavioural, governance and control failures.
For example, an operations head may find that the top loss contributors are not only equipment failure or vendor delay, but unclear decision rights, late escalation, lack of supervisory verification, no NOC acknowledgement, weak handoff ownership and generic retraining. These are not soft issues. They are hard operating controls expressed through human behaviour.
The Pareto cut helps leadership avoid symbolic action. Instead of launching broad training, the team can attack the 20 percent of causes creating 80 percent of the loss. If late escalation is one of those causes, then the corrective action is not a leadership course. It is an escalation threshold, named owner, time trigger, early escalation protection and consequence for late escalation. If closure verification is a top cause, the corrective action is not another SOP email. It is a supervisor checkpoint with evidence and audit.
7. A Practical RCA Governance Model
For RCA to work in real operations, it must become part of governance. The following model converts RCA from a document into an operating control:
8. What Operations Leaders Should Change Immediately
First, redesign the RCA template. Add fields for role owner, decision right, escalation threshold, repeat incident flag, corrective action evidence and effectiveness check. Make it impossible to close an RCA with only department-level ownership.
Second, change the review rule for repeat faults. A repeat fault should not automatically receive a fresh RCA number and a fresh explanation. It should reopen the previous cause and ask why the earlier corrective action failed. This prevents organizational amnesia.
Third, separate blame language from accountability language. Do not write personality judgments. Write operating specifications. The objective is not to punish people; it is to define the control that must exist even when people change.
Fourth, make leadership review sharper. Every RCA review should challenge three weak phrases: 'communication gap', 'training required' and 'matrix to be reviewed.' These phrases may be valid starting points, but they are rarely valid final causes.
Fifth, close the loop. An action is not closed when it is assigned. It is not closed when training is completed. It is closed only when evidence shows that the cause has been removed or reduced.
Conclusion: Honest RCA Is a Leadership Discipline
Root cause analysis is not difficult because the tools are complicated. It is difficult because the tools eventually ask the organization to describe itself honestly. They ask who had the decision right, who owned the handoff, who should have checked, who escalated late, who closed without evidence and who allowed the same failure to return.
The answer is not to turn RCA into a blame exercise. That would destroy trust and weaken reporting. The answer is to make accountability structural. Name the role, not the personality. Define the control, not the excuse. Assign the owner, date and evidence. Review whether the action removed the cause. Treat recurrence as a failure of the previous RCA.
When RCA is allowed to name the role, Pareto does the rest. The vital few causes become visible, the expensive repeat failures become governable, and operations move from troubleshooting to true operational excellence. That is where RCA stops being a form and becomes a leadership discipline.
About Author:
Salman Ahmad Siddiqui
Independent Director inoperant | Operational Excellence & Board Intelligence Practitioner
Founder & CEO SyhaConnect Innovations
Contacts: +91 9625899500 | +91 9582649500
Email: hello@salmansiddiqui.in | connect@syhaconnect.in | syhaconnect@gmail.com
LinkedIn: https://www.linkedin.com/in/salmansiddiqui38442236/
Web Site: www.salmansiddiqui.in | www.syhaconnect.in
Author Positioning
Prepared in my voice and professional positioning as Salman Ahmad Siddiqui — a governance-led operational transformation leader focused on SLA discipline, NOC/PMO execution, OPEX control, field-force productivity, second-line leadership and my signature Analyze – Act – Adhere methodology.
My professional journey as an Air Force veteran, Founder & CEO of SyhaConnect Innovations, Operational Excellence Strategist, ILA-certified corporate trainer and enterprise coach has been shaped by more than 30 years of experience across telecom infrastructure, DMS/IDP operations, fibre, tower operations, NOC/PMO leadership, multi-site execution and governance-led business transformation.