Business Reason for Root Cause Analysis

Presentation given at QA&Test now available on-line!

Root Cause Analysis (RCA) enables prevention of problems, by analyzing problems that happened in the past. Purpose is to identify main causes that lead to the problem, and to initiate actions to prevent similar problems from occurring. RCA can be applied on any problem case; like major defects, project disturbances, or findings from assessments. What’s the business benefit of doing Root Cause Analysis you may ask? Well, there are several good business reasons to do it.

Root Cause Analysis, as any other improvement initiative, should only be done if it brings benefits for the business. I’ve supported various organizations in deploying Root Cause Analysis, which had different valid business reasons for doing it. So my question to you is: What is your most important Business Reason to do Root Cause Analysis for software development / maintenance? Is it to Improve your delivery chain, enabling your organization to become leaner and release software faster and quicker? Or to optimize your processes to lower operational costs? Or maybe to reduce your project and/or operational risks, or to deliver highest quality software to your customers? I’ve run a Poll on LinkedIn to find out what the most important business reasons are to do Root Cause Analysis.

Results of the Poll

Reducing project / operational risks has been selected by almost half of the attendees of the poll as the main reason to do Root Cause Analysis. Learning from major problems or project disturbances, and taking actions to prevent similar problems in order to reduce risks is considered very important for a software business as the results of this poll shows. I’ve done several Root Cause Analysis sessions on such problems, the benefit that I have seen is that by understanding and addressing the real root causes, similar problems could indeed be avoided.

Delivering high quality software is the 2nd business reason, with roughly 1/3 of the votes. Understanding the causes that have led to software quality issues can significantly improve product quality. I’ve had several occasions where (agile) teams learned and improved their way of working, by examining major and/or reoccurring faults.

I’m a bit surprised to see only a few votes for optimizing the delivery chain, and improving processes. I know that many people are not that fond of processes and process improvement (ok, I have my own view on what a process is), so that may explain the low scores? But still, I’ve seen that using Root Cause Analysis within a Lean Six Sigma approach can give significant benefits. For instance, using a Value Stream Analysis tot find where the delays are in the product life-cycle, and use Root Cause Analysis to determine the causes and take preventive actions.

Continuous Quality  Improvement using Root Cause Analysis

The results of this poll have been presented at QA&Test 2011 on october 28, in my 10th anniversary presentation on Root Cause Analysis. Feel free to download the slides of Continuous Quality Improvement using Root Cause Analysis.

For more information on Root Cause Analysis, see:

Thanks to everyone who contributed tot this poll and who attended QA&Test2011!

(Visited 810 times, 1 visits today)
Tags: , , , , ,

About BenLinders

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , . Bookmark the permalink.

2 Responses to Business Reason for Root Cause Analysis

  1. Pingback: The Clean Coder: A Book on Professionalism and Attitude | Ben Linders

  2. Pingback: The Economics of Software Quality | Ben Linders

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>