Root cause analysis is a process for understanding 'what happened' and solving a problem through looking back and drilling down to find out 'why it happened' in the first place. Then, looking to rectify the issue(s) so that it does not happen again, or reduce the likelihood that it will happen again.
This guidance provides an overview of root cause analysis and how internal auditors can use the techniques, along with some examples.
What is root cause analysis?
Who uses root cause analysis and why?
Why root cause analysis is of interest to internal audit
What are the benefits of root cause analysis for internal audit?
How and when root cause analysis might be applicable
What are the potential issues for internal audit applying root cause analysis?
What root cause analysis techniques are there and where do they come from?
The five whys?
Ishikawa diagram (fishbone)
Logic tree
Failure mode effects analysis (FME)
Fault tree analysis
Conclusions
Report templates and generic set of root causes
The three basic types of causes of a problem are physical, human and organisational e.g. a material item failed, someone made an error, a system, process or policy is faulty. Most problems in complex systems are made up of more than one single cause. A range of approaches, tools and techniques can be used to help identify the issues.
'A root cause is a factor that caused a non-conformance and should be permanently eliminated through process improvement. Root cause analysis is a collective term that describes a wide range of approaches, tools, and techniques used to uncover causes of problems.' Source: American Society of Quality
'Identification and evaluation of the reason for non-conformance, an undesirable condition, or a problem which (when solved) restores the status quo.' Source: Business dictionary
There are a wide range of industries using root cause analysis that includes healthcare, manufacturing, transportation, construction, chemical, petroleum and power.
It may be used to assist in any situation where there is a gap between actual and desired performance, recurring errors or failures with specific processes and undesirable events reoccurring.
It can be used in areas such as quality control, change management, health and safety, business process improvement, operations and project management to name but a few.
Poor organisational culture has been identified as the root cause of problems in a number of different business sectors which has resulted in great cost to organisations. Paying attention to culture and behaviours within internal audits is an important step forward for our profession, more detail can be found on this within the guidance on auditing culture.
In particular internal audit can help the board understand how the organisation’s culture is embedded in a way that affects behaviour throughout the organisation through identifying what needs to be done differently or better. However, poor organisational culture is not a root cause in its own right, cultural issues are caused by a range of organisational, process and behavioural factors.
Internal audit has a role to play in supporting the board and senior executives, be seen to be adding value to the organisation and raising the profile of the internal audit function. Given internal audits overview of the organisation they are in an ideal position to identify any potential themes developing, behaviours that influence decisions, etc.
By applying root cause analysis internal audit reports can be streamlined with higher impact recommendations that are more meaningful to management, reduce risks, add insights that improve the longer term effectiveness and efficiency and performance of business processes as well as the overall governance, risk and control environment, refer to Practice advisory 2320-2 on root cause analysis (RCA).
This will not only provide a better understanding and more in depth learning for internal auditors on particular systems and processes but also the users of these systems. However, to do this auditors will need to have the required skills and experience to perform such work , undertake training, seek outside assistance or recommend in the internal audit report that management perform root cause analysis.
The following provides a list of frequently asked questions and answers on root cause analysis.
The time to use root cause analysis is where there has been a significant event, for repetitive errors and where there is poor performance or where there is no or limited assurance given on an audit.
Of course, line management (first line or defence) or other functions (second line of defence) should carry out root cause as part of business as usual and this should always be considered (or supported) in the first instance. However where internal audit can add value could be:
This does not have to add a significant amount of time to the audit and may in fact replace some testing. A discussion needs to take place with the audit manager to decide on the way forward.
Before getting to the draft report stage discussions need to take place about undertaking root cause analysis. This will save time on writing/re-writing the report and likely to reduce the number of findings. At the end of this guidance some examples are provided of a reporting template and generic set of root causes.
There are several models to use (see comments below) but consider your choice based on the assignment you are undertaking and discussion with your head of internal audit/audit manager rather than a favourite technique that might not be right for the job. It may be appropriate to use a combination of approaches.
The culture of an organisation can sometimes prevent staff getting to the true root cause of the problem:
There are a range of tools and techniques that can be used for root cause analysis. Examples of such tools are shown below with background information provided on a selection of the techniques and how to use them.
The five why’s technique was originally developed in the 1930s by the Founder of Toyota Motor Corporation, Sakichi Toyoda. Through the Toyota production system it became popular in the 1970s.
The first basic concept was used in the 1920s but popularised in the 1960s through use in quality management in the Kwasaki shipyards. The diagram was also used to help develop the Mazda Miata car.
Developed in the late 1940s to study the problems of malfunctions in military systems, this was then more fully developed by aerospace and automotive industries.
This was developed in the early 1960s for the US Air Force for use with the Minuteman system by Bell Telephone Laboratories. It was subsequently used by Boeing and adopted by the Aerospace industry in the 1970s. In the 1980s and 90s adopted by Chemical, Robotic and Software industries.
Basically it is a case of asking 'why' five times and through each cycle drilling down to identify the root cause. It maybe that you need to ask 'why' more than the five times, but great care should be taken to stop before five questions. Specifically the fact that a solution is available at one level does not mean that the root cause has really been found. When it works well the five why’s should uncover a range of root causes and, therefore, provide all of the realistic solution options.
The five whys is easy to use, useful when problems involve human factors and best for simple to moderately difficult problems with regards to trouble shooting, quality improvements and problem solving. It can also be used alongside other methods.
A complaint is received from a customer as the goods ordered where not delivered on the agreed delivery date.
The company did not have the goods in stock to supply.
The product had not been received from the manufacturer before supplies ran out.
The volume of sales of the product increased significantly over the period.
A marketing campaign had been undertaken and the goods offered at a discounted price.
The warehouse was not aware of the promotion and therefore of the change in sales pattern.
One key root cause is the lack of communication between department’s therefore stock economic ordering quantities had not been adjusted to take account of the increase in likely sales. There is normally more than one root cause and a further cause could be that the stock system was not up-to-date; it may be that it is only updated periodically, possibly at the end of each day and appearing to hold stock than is actually is when the system is checked.
The Ishikawa model of root cause analysis takes you through a process of first of all describing the problem, collecting and analysing data and then through possibly brainstorming identifying potential causes. This should then enable you to analyse and identify the root cause(s) and then advise on possible solutions. It may take a number of steps to trace the problem back to the ‘root cause’ by going through a series of questions:
Causes are usually grouped into major categories to identify these sources of variation. The categories typically include those shown in the diagram below.
The outcomes from this show that there are a number of problems some cultural and the mind set that this is your problem not mine, just get on with it. This needs to be addressed starting with the board and senior management and the tone at the top through to the need for policies and procedures and training for those involved with business continuity along with updating of systems to ensure efficiency and effectiveness.
A logic tree is a visual problem solving tool that breaks a problem into discrete chunks and helps you search for all the possible causes of a problem through asking questions that lead you to the next level of detail. This can help simplify complex problems and makes it easier for you to get an overview of your options.
This involves a cross-functional team of people with diverse knowledge about the process, product or service and customer needs, going through and identifying all the ways failure could happen, identifying the consequences and the seriousness of each effect.
For each failure mode the potential root causes are determined. Rating estimates on the probability of failure occurring along with the current controls are recorded as well as the detection rating (this rating estimates how well the controls can detect either the cause or its failure mode after they have happened but before the customer is affected).
Detection is usually rated on a scale from 1 to 10, where 1 means the control is absolutely certain to detect the problem and 10 means the control is certain not to detect the problem (or no control exists).
Fault tree analysis is a top down approach that is used to help identify potential causes of a system failure before any failures actually take place and then take action to reduce risk on a complex system. It is a graphical model of the pathways within a system that can lead to a foreseeable failure. The process goes through five steps of: