The key to root cause analysis is making sure it’s controlled by a robust process – and creating a positive action plan to prevent recurrence.
Root cause analysis is a process. It is neither haphazard nor uncontrolled. This understanding is essential to effective implementation.
Once it is perceived and controlled in the same manner as other processes in the organisation’s quality management system, it is possible to implement root cause analysis effectively.
Root cause analysis creates the input to corrective action planning by establishing requirements. Without thorough and well-controlled investigation of the root cause of a given problem, any attempt at corrective action is doomed. It would be like manufacturing a product without fully developing the specifications needed to fulfil the design requirements.
Root cause analysis investigates the root cause of identified problems in order to develop and implement a plan for corrective action. Note that the specific intent is to move on to corrective action.
ISO 9001 states: ‘Corrective actions shall be appropriate to the effects of the non-conformities encountered.’ In order to fulfil the requirements of this ‘shall’ you must evaluate what the effects of the non-conformities actually are. There must be a correlation between the negatives – cost, comparable loss or appreciable risk – and the action taken.
Only those problems and non-conformities that meet the criteria of this evaluation flow through to the corrective action process. It is inappropriate to expend large amounts of money and resources on a situation posing a minimal risk to the organisation. Therefore, since the process that precedes corrective action is root cause analysis, you can conclude that root cause analysis only occurs if there’s been a decision to conduct corrective action.
This distinction should allow you to better comprehend the difference between evaluating a nonconformity and conducting root cause analysis. The former will result in the decision to take some action, such as correction, remedial action, rework, monitoring etc. The latter will result in the identification of the causes of the problem and the development of an appropriate action plan in order to prevent recurrence.
The first step in this process is to evaluate the situation – the inputs – and arrive at a conclusion in order to initiate root cause analysis. The second is to select the members of the team who will conduct the root cause analysis. Giving thoughtful deliberation to the assignment of team members is as important as it is for any other process. It’s important to assign tasks to competent individuals, to communicate expectations and to ensure their availability for the project.
As you begin to select participants, it’s important to communicate the distinction between evaluation and root cause analysis. Otherwise there will be the predictable confusion, with individuals assuming that once they’ve told you that the bore is undersized or the battery needed to be replaced or a test wasn’t correctly scheduled that their job is done. What they need to understand is that root cause analysis has just begun.
There are myriad tools and techniques available for this process, but not all tools are used every time. In each instance, individuals involved should have the latitude to select the tools that best fit the situation.
In many instances the basic tools are the best. Using these tools also serves to increase individuals’ confidence in their ability to make a meaningful contribution. The introduction of complicated tools can alienate people who could otherwise provide valuable input.
Once the team has been assembled, the next step is to examine the documentation that relates to the situation to ascertain the requirements. It is often the case that assumptions are made about requirements that are not substantiated by documentation. This crystallises in the team’s mind what the requirements actually are.
In addition to establishing what the ‘right’ thing is, document review will reveal issues such as:
- Incomplete or missing requirements
- Requirements not adequately described
Now that the team has determined the requirements, it is necessary to verify that they are being fulfilled. Reviewing the documentation allows individuals to prepare questions to ask process owners that will help to verify conformance to the defined requirements.
Verification takes two paths. One is through interviewing, and the other is through looking at records and other evidence. Interviewing will provide information as to the level of conformance to documented procedures. Are people doing what the documents say they should? Are they conducting processes in the same manner as described? If there are variations, it is appropriate to investigate further to determine if the variance is part or all of the root cause. Accessing records will facilitate this determination.
Flowcharting is often a by-product of interviewing. The process is drawn twice – once as it is documented, then again as it is implemented. Comparisons between the two quickly reveal breakdowns. The act of flowcharting also makes process owners think about what they do as they are drawing the flow of activities. This sometimes allows them to pinpoint errors and omissions that show a process to be losing control.
Records form the foundation for root cause analysis. The integrity of the organisation’s record retention practices has direct influence on the effectiveness of this process. Root cause analysis doesn’t begin the day an organisation becomes aware of a problem. It starts months earlier with the aggregation of good data.
Once the interviewing and/or flowcharting processes are complete, the records can be accessed to substantiate or refute what has been conjectured as a possible root cause. Training people to do root cause analysis should include guidance on how to access records. Coaches and mentors should ensure that individuals are familiar with the organisation’s control of the quality records procedure and whatever other documents, like a record retention matrix, that provide information about location, access, owners, identification and retention period.
Brainstorming & ‘Five Whys’
There are two simple tools that help to generate ideas about what could have happened. They are brainstorming and the ‘five whys’. The overwhelming benefit of both of these is that they stimulate our creativity; they get us out of our habitual narrow focus so that we can explore other possibilities.
The results of both of these exercises should be used to populate a cause and effect diagram – also called fish bone diagram. This diagram should be used at the most basic level to keep the process simple.
The results of the brainstorming session can be paraphrased as questions and then used to populate the various blocks of the diagram. For example, figure 1 shows the material block populated with questions derived from a brainstorming session about late deliveries.
When all of the blocks have been populated with the output of the brainstorming session, the team begins the task of seeking out the records that will provide objective evidence to answer the questions.
The results of the exercise are recorded on a worksheet. For example: checked specifications developed by engineering; matched specifications against requisition, purchase order and receiving records. All match: no problem found. It can therefore be concluded that the purchasing function ordered what was specified and the supplier shipped what was ordered.
Root cause analysis is nothing more than a process of elimination, so it’s vital to remain objective and use thought-stimulating tools like brainstorming and the five whys. At the end of this fact finding exercise, the team will know exactly what processes related to this situation are acceptable and which ones have problems. By following the trails, the root cause will be identified.
Additionally, any contributing factors or secondary causes will also be uncovered. This allows for the development of a corrective action plan that addresses both the root cause and the ancillary issues that are contributing to it.
It is impossible to develop an effective action plan without thorough root cause analysis. Equally, it is impossible to conduct root cause analysis effectively without implementing it as a controlled process.
How to complete the five whys:
- Write down the specific problem. Writing it helps you formalise the problem and describe it completely. It also helps a team focus on the same problem
- Ask why the problem happens and write the answer down below the problem
- If the answer you just provided doesn’t identify the root cause of the problem you wrote down in step one, ask why again and write that answer down
- Loop back to step three until the team is in agreement that the problem’s root cause is identified. This may take fewer or more than five whys!
- Help to identify the root cause of a problem
- Determine the relationship between different root causes of a problem
- One of the simplest tools – easy to complete without statistical analysis, ambiguous or conflicting instructions (for example, both inch and centimetre references on a specification)
Brainstorming ground rules
- There are no bad ideas. It’s a brainstorming session, not a serious matter that requires only serious solutions. Remember, this is one of the more fun tools of quality, so keep the entire team involved.
- Don’t criticise other people’s ideas. This isn’t a debate, discussion or forum for one person to display superiority over another.
- Build on other people’s ideas. Often an idea suggested by one person can trigger a bigger and/or better idea by another person.
- Reverse the thought of ‘quality over quantity.’ Here we want quantity; the more creative ideas the better.
- As a facilitator, you can even make it a challenge to come up with as many ideas as possible and compare this team‘s performance to the last brainstorming session you conducted.
If you want to see more problem solving tool explanations, visit our related posts below: