Downloaded 25 times
Uploaded byQualitest
Root Cause Analysis | QualiTest Group
This document provides an overview of root cause analysis (RCA). RCA is a process used to investigate events that impact safety, quality, reliability and production. It involves collecting data, identifying causal factors, determining root causes, and generating recommendations. Root causes are underlying issues that management can control and for which effective recommendations can be made to prevent recurrence. The document outlines the four major steps of RCA and provides examples of using RCA to improve software processes, support agile development, and address issues with third party integrations.
More Related Content
Similar to Root Cause Analysis | QualiTest Group
Root Cause Analysis | QualiTest Group
- 1. Root Cause Analysis KevinWilkes & Richard Morgan November 2016
- 2. Presenters: Richard Morgan UK DeliveryManager Kevin Wilkes Senior Consultant 2
- 3.
- 4. Some questions to answer |Where didthe event arise? |What was the source of the problem? |What can I do so this does not happen again? |What is a Root Cause Map? |When do I stop looking? 4
- 5. What is RCA? |Root CauseAnalysis (RCA) is a process designed for use in investigating and categorizing the root causes of events with: |Safety |Environmental |Health |Quality |Reliability |Production impacts 5
- 6. What is anevent? |The term “event” is used to generically identify occurrences that produce or have the potential to produce these types of consequences. |Simply stated, RCA is a tool designed to help identify not only what and how an event occurred, but also why. 6
- 7. Definition of Root Cause |Rootcauses are those for which effective recommendations for preventing recurrences can be generated. 7 The Symptom The Cause
- 8. Root causes are underlying causes |The investigator’sgoal should be to identify specific underlying causes. The more specific the investigator can be about why an event occurred, the easier it will be to arrive at recommendations that will prevent recurrence. 8
- 9. Root causes are those thatcan reasonably be identified |Occurrence investigations must be cost beneficial. It is not practical to keep valuable manpower occupied indefinitely searching for the root causes of occurrences. |Structured RCA helps analysts get the most out of the time they have invested in the investigation. 9
- 10. Root Cause Category NearRoot Cause Category Primary Source Root Cause Problem Category No Training Training in error •Not up to date •Training material in error Training to be made •On the job training •Abnormal event Cause Software Reliability Fault Installation Fault Training Handset Problem Procedure Tariff Problem Design Fault Equipment Misuse 10 •Decision not to train •Training requirements not identified
- 11. Root causes are those overwhich management has control |Analysts should avoid using general cause classifications such as operator error, equipment failure or external factor. Such causes are not specific enough to allow management to make effective changes. 11
- 12. Root causes are thosefor which effective recommendations can be generated 12 |Recommendations should directly address the root causes identified during the investigation.
- 13. Four major steps |The RCA isa four-step process involving the following: 1.Data collection 2.Causal factor charting 3.Root cause identification 4.Recommendation generation and implementation 13
- 14. Step 1 Data collection |The firststep in the analysis is to gather data. Data Collection: |Talk to people |Analysis gathering |Investigate the cost |Look at the process |What data was used |What triggered the event 14
- 15. Step 2 Causal factor charting |Causal factorcharting provides a structure for investigators to organize and analyse the information gathered during the investigation and identify gaps and deficiencies in knowledge as the investigation progresses. Cause Human Error Computer Error SoftwareHardware Process Error Other Other 15
- 16. Step 3 Root cause identification |Afterall the causal factors have been identified, the investigators begin root cause identification. Symptom Root Cause 16
- 17. Root Cause Category NearRoot Cause Category Primary Source Root Cause Problem Category No Training Training in error •Not up to date •Training material in error Training to be made •On the job training •Abnormal event Cause Software Reliability Fault Installation Fault Training Handset Problem Procedure Tariff Problem Design Fault Equipment Misuse 17 •Decision not to train •Training requirements not identified
- 18. Root Cause Category NearRoot Cause Category Primary Source Root Cause Problem Category No Training Training in error •Not up to date •Training material in error Training to be made •On the job training •Abnormal event Reliability Fault Installation Fault Handset Problem Procedure Tariff Problem Equipment Misuse 18 •Decision not to train •Training requirements not identified Design Fault Software Training Cause
- 19. Root Cause Category NearRoot Cause Category Primary Source Root Cause Problem Category Zones 1-5 Infrastructure Charging Installation Fault Handset Problem Procedure Tariff Problem Reliability Fault Equipment Misuse 19 •Zone Config agreed •Zone Config applied Design Fault Software Training Cause
- 20. Step 4 Recommendation generation and implementation |Thenext step is the generation of recommendations. 20
- 21. |Example table: Root CauseSummary Table Description : Cause identified Paths through Root Cause Map Recommendations 1. Not able to use the application to change the user profile on the mobile device • Handset problem • Design fault misuse • Training • Training to be updated to include new feature • Update manual 2. Issue 2 • Path 2 – level 1 • Path 2 – level 2 • Recommendation • Recommendation 21
- 22. RCA for Defects |Thenext step is the generation of recommendations, having identified the root cause of the problem. 22
- 23. RCA Examples |RCA can beused to support Agile where the timelines may be much shorter |RCA can be used in any size organization to support Process Improvements both in software and processes |RCA can be used to support 3rd party integrations |RCA is a Method to help communicate where improvements can be made Not just for bugs! 23
- 24. |Agile Example : RootCause Summary Table Description : Cause identified Paths through Root Cause Map Recommendations 1. Missing acceptance criteria for new feature for the user story and new user • User story accepted into sprint • User story created • Acceptance criteria defined • Design mapped against user story • Acceptance criteria to be reviewed by the stakeholders • Peer reviews performed on all user stories greater than 13pt • Design checked against user story & acceptance criteria 24
- 25. |3rd Party Example: Root Cause Summary Table Description : Cause identified Paths through Root Cause Map Recommendations 1. The updates to the Hotel Booking API were changed and released and we were not aware of the changes • New deployment agreed • 3rd parties notified of change • Ops Manager controlling overnight release • 3rd party system taken offline • Service restored • API failing • All 3rd party vendors to notify of changes • Release dates agreed across all stakeholders • No upgrades without sign-off from 3rd parties • No 3rd party upgrade without sign-off from Ops 25
- 26. Summary |No longer firefighting after acceptance test or integration test. |We can identify areas for better analysis in Requirements in test preparation on data changes having identified the root cause of the problem. 26
- 27. Summary |We are nothere to blame anyone, we want to reduce the root causes for the problems we have identified. 27
- 28.