What is your view on driving root cause analysis by using qualitative versus quantitative information? Do you believe it is possible to get to root causes by only driving the analysis with qualitative information?
Well, I believe the majority of people reading this post will say that the best, if not only possible, way to drive root cause analysis is by using quantitative data, correct? This is the common sense thinking when we discuss root cause analysis, bring me the relevant data for the topic in discussion, then make a Pareto diagram prioritizing the issues with highest occurrence level from left to right, apply the 80/20 rule and apply one of the known tools for root cause analysis such as Ishikawa diagram (also known as Fish Bone diagram), 5 Why's , Fault Tree Analysis, among others...
In my experience as a TOC - Theory of Constraints practitioner I have performed a number of root cause analysis for improvement projects implemented worldwide using only or mostly qualitative data. How is that even possible? Well, in TOC - Theory of Constraints we believe that first of all, in many of the companies the process data are not accurate enough for leading to good analysis. Therefore spending time in digging numbers down to understand root cause analysis may not bring the best result in the end, second by involving the key stakeholders of the organization who live day to day the issues of the business for a "brainstorming" session on what are the key issues leading to a poor On time delivery performance, for instance, can bring good results on the potential root causes for that specific issue. Another core belief of this methodology is that the key cross functional team because they face daily the issue in discussion, they have fairly good knowledge or leads to what are causing the issue, so don't think this methodology is a "guessing methodology", it is a well defined process which can lead to great results.
The root cause analysis tool used in TOC - Theory of Constraints is CRT or current reality tree. This is basically a cause and effect tree, which is build up based on the key issues or symptoms brought up by the cross functional team who will be part of the "brainstorming" process.
In a nutshell you put together a cross functional team who is very familiar with the issue to be addressed, let's say "low productivity in product engineering department", then you hold a session for this team to "brainstorm" on what they believe based on their day to day experience are the issues leading to the specific problem to be addressed, later you and perhaps another one or maximum two people from the team will work on building up the CRT using the cause and effect relationship between the problems brought up by the team. You need to have at least this one additional person to help you build the tree, because often you won't be able to have the tr ee complete with only the problems brought up in the "brainstorming" session, you need to thoroughly understand the process in order to fill in the gaps in the cause and effect relationship of the tree. So, after about a couple of days the tree will be ready and then you will gather again the same team who attended the "brainstorming" session and they will have to validate all the relationship build up in the tree. Once the tree is validated then you move on to the next step of your process, which most likely will be defining the actions to address the root causes.
Below you can find a simple example of a CRT - current reality tree:
Next time you have to lead a root cause analysis, think about the possibility of driving a qualitative session and you may be able to surprisingly get great experience and results out of your analysis!