Over the past 14 years working in the internal audit arena I have seen a growing interest in the topic of Root Cause Analysis (RCA). My involvement in the topic has evolved from using it as part and parcel of a “lean auditing” approach, to running RCA webinars and seminars for the IIA UK, to the delivery of various in-house training workshops on this topic, and now more recently, offering a 1 day open course on RCA, as well as supporting the IIA UK to write a new practice guide on the topic.

This article explains:

• What Root Cause Analysis is
• What involvement should IA have in RCA
• Why effective RCA is not as straight-forward as you might think
• Why RCA is gaining interest in audit
• Some practical steps audit teams can take

What is RCA?
RCA is about identifying why an issue occurred compared to simply reporting the issue, or its immediate or contributing causes. The issue could be an error, non-compliance, and non-delivery of an objective or anything else that would be regarded as a failure or problem in the eyes of stakeholders.

What role should IA have in RCA?
The IIA has a clear practice advisory (2320-2) on this topic: “Auditors whose reporting only recommends that management fix an issue and not the underlying reason that caused the issue are failing to add insights that improve the longer-term effectiveness and efficiency of business processes and thus the overall GRC environment”.

It goes on to say: “A core competency necessary for delivering insights is the ability to identify the need for RCA and, as appropriate, actually facilitate, review and/or conduct a root cause(s) analysis”.

In my experience most audit teams believe they are analyzing root causes but in practice their level of skill in doing this can be rather mixed, with only a few teams having an explicit RCA methodology and offering structured training on effective RCA techniques. I think the reason for this is that many internal auditors think they will naturally be good at RCA: in my experience many auditors are not as good at RCA as they might think. However, that is not to say that competence in RCA is strong in many other managers either!

Why effective RCA is not as straightforward as you might think
When things don’t go according to plan in an organization there can often be a pressure to avoid taking the blame for what has gone wrong (for fear of the impact this might have on ones performance assessment or potential rating).

Consider an IT system implementation that was delayed and over budget: it can be tempting to “point the finger” at external factors (“the IT contractor made things too complicated, adding time and cost”), or, if internal factors have to be acknowledged, to come up with a politically acceptable reason for the problem (“the IT department didn’t manage the project so well”). Another organizational defense can be to say, “projects are always over budget and a bit late, its just one of those things” – resulting in no organizational learning and reinforcing a culture of project failures being part of business as usual.

Even where there is a bona fide intention to carry out an unbiased RCA it can be easy to identify “obvious” issues that can be improved and to classify these as the root causes. For example, in the case of the IT system implementation:“The finance department didn’t properly keep track of the project costs”, (which may have been the case) resulting in the supposed Root Cause Analysis that “finance needs to keep a closer track of IT project costs in future”. Despite this perhaps being true, such an analysis of does not represent a proper RCA. To carry out a proper RCA other avenues need to be pursued, even when “obvious” issues clearly need to be fixed. In the example above, two other avenues need to be pursued i) Why was the finance department not keeping track of the IT project costs? and ii) were there other factors responsible for the problem in addition to the first point?

If we continue with the example (based on real experiences), we might discover that there is no explicit role for finance staff to monitor IT project costs and limited training about the sorts of issues that can arise and how to identify them on a timely basis. Further, we might find that the finance department has limited resources and therefore there may be limited time for finance staff to do the analysis that might uncover issues with IT project cost estimates. Thus simply saying that finance department should keep track of
project costs can easily ignore the underlying causes that led to this, and therefore not offer a lasting long-term solution.

Looking at other reasons that may have contributed to the project running late and over budget we might uncover that project decisions (to adjust the scope of the system implementation) were being made without fully thinking through the impact on time and cost, and finance staff were not involved in these decisions. Furthermore, we might uncover that some users of the IT system were not fully engaged early enough in the details of what was going to be delivered resulting in issues at the testing stage, causing rework, delays and additional costs. And we can go further: why were the some users of the IT system not engaged as extensively as they might have been? Because they were busy on other business tasks and initiatives, which meant they did not contribute as fully as they could have done at the early stages of the project about what was going to be really important. And why was this the case? Because the project budget had limited provision for back-filling operational staff so that they could fully contribute to the project at an early stage. And why was the budget for back filling constrained? Because senior decision makers wanted the project to come in under an earlier high-level estimate they have provided. Etc. Etc.

Thus an effective Root Cause Analysis will normally reveal multiple factors leading to the difficulties that have arisen. Indeed although a proper RCA process is more “forensic” than an intuitive approach, it is actually less likely to blame any one individual or process. In reality the reasons for many issues are due to a complex blend of process, system and organizational factors and effective RCA will make this clearer, effectively revealing cultural factors that can lead to issues re-occurring.

Why RCA is gaining an interest in audit
Apart from the fact that it is good practice to carry out robust RCA, my experience is that the growing interest in being more professional in relation to RCA is due to two key factors:

1. An increasing realization by IA teams that some issues keep repeating themselves, despite IA raising the same, or similar, audit points on a regular basis. I call this the “Groundhog day” phenomenon based on the film in which the lead character has to live the same day over and over again. Indeed some HIAs that I have worked with have said: “I could often write 80% of an audit report in advance – there will always be problems with accountabilities, risk registers will normally not be up to date, managers will not do enough monitoring. Etc. Etc.” This is a clear warning sign that Root Causes are not being addressed effectively.
2. A recognition of the importance of understanding the cultural factors that are contributing to audit findings, with an increasing expectation that audit teams should comment on the risk and control culture of the organization, and a realization that effective RCA is an important “window” into the culture of an organization (as discussed earlier). Note
   that reporting on risk culture has been recently enshrined by regulations in the UK covering the expected scope of IA functions in the financial services sector.

Some practical steps audit teams can take

My first advice would be for audit teams to consider and debate:

1. How often do issues repeat themselves (e.g. are there common themes uncovered by audit, or through any management incident reporting?);
2. How much do we have a structured approach to assessing the risk and control culture of our organization?
3. What does the current IA methodology say about RCA and what guidance and training is provided to IA team members concerning RCA?

If there is room for improvement in any of these areas, auditors should familiarize themselves with the IIA practice advice materials and either i) start to pilot the use of techniques such as the “5 whys” and “the fishbone diagram” in selected assignments or ii) try to analyse the common themes in audit findings and assess the root causes for these using an organizational model such as “Burke Litwin”. In addition, audit teams might want to consider whether more in-depth training could be used as a way of building IA team competence and clarifying priority areas for action.

If you are interested to learn more about Root Cause Analysis and how it can help Internal Audit teams contact jcp@RiskAI.co.uk or attend an up-coming course.