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. The purpose is to identify the main causes that lead to the problem, and to initiate actions to prevent similar problems from occurring. RCA can be applied to 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 the 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 show. 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.
[pdf https://www.benlinders.com/wp-content/uploads/Continuous-Quality-Improvement-Using-Root-Cause-Analysis-QATest-2011-Ben-Linders.pdf 640 500]
For more information on Root Cause Analysis, see:
Thanks to everyone who contributed to this poll and who attended QA&Test2011!
My 2nd book What Drives Quality, released in 2017, helps you to improve the quality of the software products and deliver high-quality products to your customers and stakeholders.
There’s also a handy booklet on RCA: Tools for Root Cause Analysis which provides a process, checklist, and templates for doing effective Root Cause Analysis.
This Post Has 4 Comments
As an FYI, I adapted some of your Root Cause Analysis presentation for use with my Hardware Development organization. We are trying to get everybody to do Retrospectives as a method of improving quality and efficiency (eventually, everybody will also utilize more Agile methods as well).
I ensured that I gave credit to you and this web site.
Andy Thomas, @pmgeekandy on Twitter.
Thanks Andy, great to hear this!
Would love to hear from you on how retrospective work out with hardware development. I’m sure that they will be valuable for your teams.
If you’re interested to write a guest blog to share your experiences, let me know 🙂