4. Some
questions
to 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
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 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
10
•Decision not to train
•Training requirements not identified
11. Root causes
are those
over which
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 those for
which effective
recommendations
can be generated
12
|Recommendations should directly address
the root causes identified during the
investigation.
13. 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
13
14. 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
14
15. 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
15
16. Step 3
Root cause
identification
|After all the causal factors have been
identified, the investigators begin root cause
identification.
Symptom
Root Cause
16
17. 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
17
•Decision not to train
•Training requirements not identified
18. 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 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
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
19
•Zone Config agreed
•Zone Config applied
Design Fault
Software
Training
Cause
21. |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
22. RCA for Defects
|The next step is the generation of recommendations, having
identified the root cause of the problem.
22
23. 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
24. |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
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 fire fighting 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 not here to blame anyone,
we want to reduce the root causes for the
problems we have identified.
27