Test beyond the obvious- Root Cause Analysis
1 like1,160 views
The document presents a root cause analysis (RCA) framework aimed at investigating and categorizing the underlying causes of events affecting safety, quality, and reliability. The RCA process involves four main steps: data collection, causal factor charting, root cause identification, and recommendation generation. It emphasizes the need for specific, actionable recommendations to prevent recurrence of identified issues across various organizational processes.
Test beyond the obvious- Root Cause Analysis
- 1. Root Cause Analysis Kevin Wilkes & Richard Morgan November 2016
- 2. Presenters: Richard Morgan UK Delivery Manager Kevin Wilkes Senior Consultant 2
- 4. Some questions to answer |Where did the event arise? |What was the source of the problem? |What is a Root Cause Map? |When do I stop looking? |What can I do so this does not happen again? 4
- 5. What is RCA? |Root Cause Analysis (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 an event? |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 |Root causes 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’s goal 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 that can 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 causes are those over which management has control |Analysts should avoid using general cause classifications such as operator error, equ failure or external factor. Such causes are specific enough to allow management to effective changes. 10
- 11. Root causes are those for which effective recommendations can be generated 11 |Recommendations should directly address the root causes identified during the investigation.
- 12. Four major steps |The RCA is a four-step process involving the following: 1.Data collection 2.Causal factor charting 3.Root cause identification 4.Recommendation generation and implementation 12
- 13. Step 1 Data collection |The first step 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 13
- 14. Step 2 Causal factor charting |Causal factor charting 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 14
- 15. Step 3 Root cause identification |After all the causal factors have been identified, the investigators begin root cause identification. Symptom Root Cause 15
- 16. Root Cause Category Near Root 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 16 •Decision not to train •Training requirements not identified
- 17. Root Cause Category Near Root Cause Category Primary Source Root Cause Problem Category Zones 1-5 Infrastructure Charging Installation Fault Handset Problem Procedure Tariff Problem Reliability Fault Equipment Misuse 17 •Zone Config agreed •Zone Config applied Design Fault Software Training Cause
- 18. Step 4 Recommendation generation and implementation |The next step is the generation of recommendations. 18
- 19. |Example table: Root Cause Summary 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 19
- 20. RCA for Defects |The next step is the generation of recommendations, having identified the root cause of the problem. 20
- 21. RCA Examples |RCA can be used 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! 21
- 22. |Agile Example : Root Cause Summary Table Description : Cause identified Paths through Root Cause Map Recommendations 1. Missing acceptance criteria for new feature for the user story add 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 22
- 23. |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 an 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 23
- 24. Summary |No longer fire fighting after acceptance test or integration test. |Can we identify areas for better analysis in Requirements, in test preparation or data changes, to help identify the root cause of a problem. 24
- 25. Summary |We are not here to blame anyone, we want to reduce the root causes for the problems we have identified. 25