Every postmortem includes the moment when the team reaches a consensus on the probable cause of the incident and closes the ticket.
Then, a few weeks later, the same alert is received.
The system could be different, the impact reduced, or the incident could have a new name. However, the weakness still exists, which is why the root cause analysis checklist is so important: it allows IT, operations, quality, and service management teams to verify that they have fixed the problem properly, rather than just removing its most visible symptom.
What Do We Mean by “Root Cause”?
The root cause is the fundamental reason the process or system failed or continues to fail.
Consider, for example, a server running out of memory. This is an observable event. But the real reasons could be a memory leak, lack of testing, or other contributing factors.
Incident management is a process in IT service management that focuses on restoring normal service as quickly as possible. Problem management looks for the causes of incidents, handles workarounds and supports actions to reduce the likelihood or impact of recurrence.
Rebooting the server may restore service, but it doesn’t fix the underlying problem.
The Dangers of Putting an Issue to Rest Prematurely
When dealing with a serious issue, many teams put a case to rest at the conclusion of the last event connected to it. Although this course of action can be understandable under the pressure generated by an incident, it does involve some pitfalls:
- Workarounds may be misinterpreted as fixed solutions.
- The same weakness may remain in another application, location, or team.
- Engineers may need to repeat the same analysis in the future.
- Management may assume that a risk has been eliminated when it has only been reduced.
In ITIL terms, a known error is a problem that has been analyzed and whose root cause is understood; a workaround may exist, but it does not constitute a permanent fix.
The Completion Checklist for Root Cause Analysis
When wrapping up a problem record, confirm the following:
- Is the problem statement clear? Have we explained how the problem occurred, when it took place, which services were affected, and what the business impact was?
- Have we separated the cause from the symptom? Is the proposed cause more than the alert, outage, or error message?
- Is the analysis supported by evidence? Have we reviewed logs, monitoring data, configuration documents, deployment history, the incident timeline, and other relevant records?
- Would the proposed corrective action have prevented the incident? If it had existed from the start, could the incident have been prevented?
- Have we identified the contributing factors? Have we considered gaps in procedures, unclear ownership, poor documentation, capacity problems, supplier issues, or operational failures?
- Is the action permanent or just a temporary solution? If it is temporary, is it documented, communicated to the relevant stakeholders and connected to follow-up actions?
- Was the fix tested? Was the change verified under suitable conditions, and was the service monitored after introduction?
- Is it the same problem in other locations? Have we considered similar systems, services, suppliers, regions, departments?
- Are preventive controls enhanced? Did the team add new tests, alerts, automation steps, checks?
- Will another engineer easily understand the record? Does the documentation provide enough evidence, decisions, actions taken, responsible owners, deadlines, and results?
Which RCA Method to Choose?
The root cause analysis technique should be selected according to the problem.
| RCA method | Most applicable to |
| 5 Whys | Cases with simple cause-and-effect chains |
| Fishbone diagram | Situations involving people, processes, technology, and environmental factors |
| Pareto analysis | Prioritizing the causes contributing most to repeated failures |
| FMEA | Identifying, assessing, and prioritizing potential failure modes and their effects |
| Fault tree analysis | Complex failures with interrelated conditions or multiple system paths |
Create Consistent RCA Capabilities
The effectiveness of a checklist depends partly on consistent evidence standards, terminology, and closure criteria across an organization.
SPOCLEARN provides corporate group training and consulting in Root Cause Analysis. Its program covers practical training in RCA methods and tools, including the 5 Whys, fishbone diagrams, Pareto analysis, FMEA, and Fault Tree Analysis.
Would you like your organization to use standard RCA methods and closure practices? Speak to one of our experts.
Questions and Answers
What’s the distinction between a root cause and a workaround?
A workaround reduces or eliminates the impact of an incident or problem when a full resolution is not yet available. A root-cause corrective action addresses the underlying conditions that allowed the problem to occur.
How many times should the “why” question be asked in a 5 Whys approach?
Five is just a guideline. You should stop once your group has sufficiently identified a cause that can be tackled through a corrective or preventive action.
Who must take part in the root cause analysis process?
Participants may include incident responders, system or service owners, developers, engineers, process owners, support personnel, quality assurance staff, and stakeholders with knowledge of the business impact.