Root cause analysis (RCA) is a methodology used to solve problems at their root, rather than just fixing the obvious. RCA is often equated to a kaizen improvement process, and rightly so, as it often digs into possible organizational change, rather than localized optimizations. The benefits of RCA are that it uncovers relationships between causes and symptoms of problems, works to solve issues at the root itself and provides tangible evidence of cause and effect and solutions.
If a seamstress makes a shirt, and one sleeve it longer than the other, the easy fix is to fire the seamstress and hire a new one. However, the next seamstress makes the exact same shirt, with the exact same flaws. This introduces cycles and waste and lost revenue and increased overhead because RCA was not performed. Had an RCA kaizen event been triggered, we could have started with the “Why”s. Why was the sleeve too long? Because the seamstress sewed it that way. Why did she sew it that way? Because that’s what the plans said to do. Why did they plans call for one sleeve longer than the other? Because that’s what the measurements were. Why were the measurements off? Because the person who recorded the measurements measure from the top of the shoulder for one sleeve and the bottom of the shoulder on the other sleeve. Why did he measure from two different points of reference? Because he was not adequately trained. Why was he not adequately trained? Because we assumed he didn’t lie on his resume and his training was adequate. The point is, we’ve identified the need to either train or hire a new person to take measurements, not a new seamstress.
If you count the “why”s above, you see we’ve dug 5 deep. The 5 whys is a concept credited to Taiichi Ohno (the father of the Toyota production system) and is used to dig to the root of problems. However, it has its flaws. The flaws aren’t actually with the process itself, but the act of the process performed by an individual or team. If at any point the wrong question is asked, it may send you off on a tangent that isn’t going to lead to the root cause, thus provoking you to take action on the wrong cause. Keep in mind, that you don’t have to stop at the 5th why, but rather the concept is to dig as far as is necessary to identify the root cause of the observable effects.
Above, we’ve taken the process from “fingerpointing” to the seamstress, to a learning process to identify the root cause of the problem. By getting to the root cause of the initially identified problem, we may have also solved many other issues, such as inseams on pants being of different lengths, again, because of the measurements, thus preventing pants with legs of varying lengths.
The quality metrics of a clothing factory do not allow for shipment of these unusable clothes, and if you have those types of quality metrics, you need to have improvement processes in place to quickly and thoroughly identify the roots of problems without spinning your tires firing and hiring seamstresses.
Software is much more difficult however because tangible artifacts are not always present. Its often that we find bugs and hack together fixes, rather than performing RCA to understand the full chain of events and relationships so that the actual root cause is identified, fixed and possibly fixes other bugs that could happen in the future. In that sense, RCA is both reactive and pro-active.
RCA is a process that introduces organizational improvements in many situations, lasting improvements and most importantly, a learning process to follow for thorough understandings of relationships, causes and effect and solutions. By practicing RCA, you eliminate taking action on possible causes, and delay a response to the last responsible moment when the actual root cause of an effect is identified.