Root Cause Analysis | QualiTest Group
-
Upload
qualitest-group -
Category
Technology
-
view
226 -
download
0
Transcript of Root Cause Analysis | QualiTest Group
Root Cause AnalysisKevin Wilkes & Richard Morgan
November 2016
Presenters:
Richard MorganUK Delivery Manager
Kevin WilkesSenior Consultant
2
AboutQualiTest
3
Outcome
(OBT)
Some questionsto answer
|Where did the 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
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
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
Definition of Root Cause
|Root causes are those for which effective recommendations for preventing recurrences can be generated.
7
The Symptom
The Cause
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 eventoccurred, the easier it will beto arrive at recommendationsthat will prevent recurrence.
8
Root causes are thosethat can reasonably beidentified
|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
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 FaultInstallation
Fault
Training
Handset Problem
Procedure
Tariff Problem
Design FaultEquipment
Misuse
10
•Decision not to train
•Training requirements not identified
Root causes are thoseover which managementhas 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
Root causesare those forwhich effective recommendations can be generated
12
|Recommendations should directly address the root causes identified during the investigation.
Fourmajorsteps
|The RCA is a four-step processinvolving the following:
1.Data collection 2.Causal factor
charting
3.Root cause identification
4.Recommendation generation and implementation
13
Step 1Data 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
14
Step 2Causal 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
ErrorOther
Other
15
Step 3Root cause identification
|After all the causal factors have been identified, the investigators begin root cause identification.
Symptom
Root Cause
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 FaultInstallation
Fault
Training
Handset Problem
Procedure
Tariff Problem
Design FaultEquipment
Misuse
17
•Decision not to train
•Training requirements not identified
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
Reliability FaultInstallation
Fault
Handset Problem
Procedure
Tariff Problem
Equipment Misuse
18
•Decision not to train
•Training requirements not identified
Design Fault
Software
Training
Cause
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 FaultEquipment
Misuse
19
•Zone Config agreed
•Zone Config applied
Design Fault
Software
Training
Cause
Step 4 Recommendation generation andimplementation
|The next step is thegeneration of recommendations.
20
|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
21
RCA for Defects
|The next step is the generation of recommendations, having identified the root cause of the problem.
22
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! 23
|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 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
|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
Summary
|No longer fire fighting after acceptance test orintegration 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
Summary
|We are not here to blame anyone,we want to reduce the root causes for the
problems we have identified.
27
www.QualiTestGroup.com
Thank You