Sponsored By Aspose - File Format APIs for .NET


Benefits of Root Cause Analysis

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.

This entry was posted in Agile, Alt.Net, Lean. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

11 Responses to Benefits of Root Cause Analysis

  1. Liam Westley says:

    Interesting summary of RCA as a process. I do find that in some organisations the presence of a blame culture can put a brake on this type of process.

    I’m always striving to convince people to be open and be quick to admit where things have gone wrong without worrying about the consequences. Or rather, they don’t need to worry about personal consequeneces – there shouldn’t be any. The only consequences should be those of putting in procedures to make sure whatever went wrong doesn’t occur again.

    I don’t think you can underestimate the effort this can sometimes take. It’s worth it though.

  2. Cory Boisoneau says:


    While there are a variety of programs out there for documenting RCAs, the most effective I’ve seen is RealityCharting. It is based on cause and effect and does a great job of visually communicating the cause and effect relationships that come together to cause a problem. It is based on the Apollo RCA methodology and is very easy to use. You can read more and download a free trial at:


  3. Derick,

    Tangible in the essence of being definitive. Often software issues are vague and elusive, and this is the meaning behind that phrase. Things that are tangible are concrete, definite, obvious etc. No doubt we can discover the root causes, but it can be more difficult. If your shirt sleeve is longer than the other, that’s a problem for anybody who wears the shirt, and it is what it is. If somebody can’t login to your system and reports a bug, is it a bug with the entire system, with that person, the client machine, etc. Its vague and more difficult to track down, thus makes RCA more difficult.

  4. “tangible artifacts are not always present.”

    Can you expand on that a little more? I’m not sure I agree with it, off-hand. Isn’t our code a tangible artifact? Isn’t the customer’s acceptance of a feature tangible? Maybe I’m thinking about this too literally, or too abstractly. It seems that we should be able to find the root cause of a feature not being implemented correctly, or a bug being introduced.

  5. Steve, without going deep into RCA, the simple answer to your issue is that you don’t have control over “a butterfly flapping its wings in australia”, so how are you supposed to invoke change on that event? RCA is about investigation. In Apollo Root Cause Analysis, there is a quote of a study that says only 20% of problems are actually investigated to the point, and in enough detail, to provide an adequate and efficient solution. And of course, you don’t do RCA on your own, but rather as a team. This helps to combat situational awareness and behavioral issues. RCA is about efforts and learning processes to adequately and efficiently provide solutions to thoroughly investigated issues.

  6. Steve Bohlen says:

    One of the other issues with the process of RCA is that its (nearly always in my experience) completely arbitrary where you choose to STOP (e.g., how do you know when you have indeed arrived at the ‘root’ cause of something?).

    For example, let’s assume that instead of determining that there was an assumption about the skill of the measurer, we found that the company simply provided inadequate training. Then we determine this was because the company didn’t allocate enough on the training budget that was because this year’s budget was less than last years that was because the company had wide-ranging budget cuts that was because they were spending money breaking into new overseas markets and shifted resources to marketing that was because the domestic shirt market had dried up that was because styles had changed and everyone was going barechested in the country that was because someone on the cover of a fashion magazine posed shirtless.

    This is an admittedly silly example, but the point is that the trouble with RCA is that the temptation is to arbitrarily draw the line SOMEWHERE and all too often that somewhere seems to be where “the influence of the person performing RCA ends” and this means the problem never gets truly solved.

    The ‘5 whys’ is at least a guiding rule about how deep to dig, but sometimes 3 is enough and sometimes 5 is too little and this (in my experience) is the great challenge of RCA — if you keep digging, you eventually end up at “a butterfly in australia flapped its wings” 😀

  7. Alena says:




  8. Daiv, I’ve studied fishbone quite a bit, but never applied it yet as a style for RCA and documentation, although I’m very interested in that technique. I’m hoping to put some practical experience with it in use in the near future.

  9. Daiv Russell says:


    To document your root cause you might want to use a process I outline in my white paper on the process.


    I’m REALLY into root cause analysis and enjoy helping people get up to speed on the process.

    – Daiv Russell – http://Twitter.com/DaivRawks

  10. Neil,

    There are structured ways of performing root cause analysis. You can see these on the wikipedia entry. Some of the documents you can collect are timelines, cause and effect trees, casual factor charts etc.

  11. Neil says:

    Nice article. Any advice on how you’d document RCA?

Leave a Reply