Buried in COBIT 5 processes such as APO11 Manage quality and APO12 Manage risk in the Align, Plan and Organize (APO) domain, you will find a root cause analysis (RCA) as an output of the management practices. The RCA output is used by numerous other processes. Obviously, knowledge of RCA methods and techniques are essential for the Deliver, Service and Support (DSS) processes DSS02 Manage service requests and incidents and DSS03 Manage problems.
However, at times, COBIT uses the term RCA imprecisely. For instance, the Build, Acquire and Implement (BAI) process BAI01 Manage programs and projects calls for the user to “perform root cause analysis for deviations from the plan.” My management accounting education tells me this is really a variance analysis, which quantitatively investigates the difference between actual and planned behaviors. It is possible that when you determine the variance and the reason for it, you may need to get at the root when you perceive that there is a systemic reason for the deviation. But when it is just a deviation, variance analysis is the way to go. Any tradesman will attest that you have a tool kit and each tool has a particular purpose. Yes, you could use a wrench to drive in a nail, but a hammer works better. Are you confused yet? Perhaps, I need to step back and define RCA.
Everything you do in your organization is a process or part of a process. You can characterize every process by its average performance and variation from the average. Processes are optimal when the result of the process is at the expected value, meaning there is minimal variation. However, occasionally, things go wrong. In Six Sigma, they say “shift happens.” This means the process is wobbling and drifting from average performance. (We will not even talk about entropy.) ISO 13053-1 Clause 9.3.3 states, “Each particular problem is the product of an errant system (or process). The frequency and magnitude of the problem should be monitored to determine whether it is constant or sporadic, increasing in magnitude or decreasing, etc.”1
Processes are optimal when the result of the process is at the expected value, meaning there is minimal variation.
So we need to use a problem-solving method such as Global Eight Disciplines (G8D); Kepner-Tregoe Problem Solving and Decision Making (PSDM); Kaizen Define, Measure, Analyze, Improve and Control (DMAIC); Plan-Do-Check-Act Cyle (PDCA); Rapid Problem Resolution (RPR); Symptom-Cause-Outcomes-Resources-Effect (SCORE); Six Sigma; ThinkX Productive Thinking Model; or Theory of Inventive Problem Solving (TRIZ or TIPS) to figure out why actual performance is varying from plan. Even the word “problem” gives us a simple method: profile, root cause, options, balance, launch, evaluate and maintain (PROBLEM). Like PROBLEM, most problem-solving methods call for RCA.
RCA is an objective, thorough and disciplined methodology employed to determine the most probable underlying causes of a problem and undesired events within the organization. It is based on the aim of formulating and agreeing on corrective actions to at least mitigate, if not eliminate, those causes to produce significant, long-term performance improvement.
But this begs the question, “What is a root cause?” A root cause is the most reasonably identified basic causal factor, or factors, which, when corrected or removed, will prevent (or significantly reduce) the recurrence of a situation, such as an error in performing a procedure. It is also the earliest point where you can take action that will reduce the chance of the incident happening.
Notice the use of the word “factors;” there is usually not one factor, but many contributing factors. Think of the root cause of world hunger. We have enough food to feed everyone, so why are some people starving? There are many contributing factors, including environmental, political, social and economic issues. And there are even more factors contributing to each of those high-level areas. You can work on the problem by working on the contributing factors. Remember, in COBIT you are looking for progress, not perfection. Just chipping away at any contributing factor has a mitigating effect on the problem.
When looking for root causes, look beyond the obvious. Usually your initial response to a problem is a symptom of the root cause and not a cause. A successful analysis is complete, credible and comprehensive. And do not forget to document your analysis using the five Cs: criteria, condition, consequence/effect, cause and corrective action/recommendation. This article was brought to you by the letter of the day: C.
So the next time you have a problem, agree on a method you all could use to analyse causes and get cracking to find those contributing factors.
Peter T. Davis, CISA, CISM, CGEIT, COBIT Foundation, COBIT Implementation, COBIT Assessor, COBIT INCS, CISSP, CPA, CMA, CMC, ITIL FC, ISO 9001 FC, ISO 20000 FC/LI/LA, ISO 27001 LI/LA, ISO 27005 Lead Risk Manager, ISO 28000 FC, ISO 31000 Lead Risk Manager, ISTQB CTFL, Lean IT FC, Open FAIR FC, PMI-RMP, PMP, PRINCE2 FC, SFC, SSGB, RESILIA FC
Is the principal of Peter Davis+Associates, a management consulting firm specializing in IT governance, security and audit. He currently teaches COBIT 5 Foundation/Implementation/Assessor, ISO 27001 Foundation/Lead Implementer/Lead Auditor, ISO 31000/ISO 27005 Risk Manager (RM), ISO 20000 Foundation/Lead Implementer/Lead Auditor, ISO 22301 Foundation, ISO 9001 Foundation and Project Management Institute Risk Management Professional (PMI-RMP) courses.
Endnotes
1 International Organization for Standardization, Quantitative methods in process improvement -- Six Sigma -- Part 1: DMAIC methodology