root cause analysis | qualitest group

Post on 22-Jan-2018

226 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

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

top related