A Guide To Fact Based Problem Solving

Shell Global Solutions
A Guide to the
FACT BASED
PROBLEM SOLVING
PROCESS
A guide to the
FACT BASED
PROBLEM SOLVING
PROCESS
Confidential
This document is made available subject to the condition that the recipient will neither use or disclose the contents except as agreed in writing
with the copyright owner.
Copyright is vested in Shell Global Solutions International B.V., The Hague.
© Shell Global Solutions International B.V., 2001. All rights reserved.
Neither the whole nor any part of this document may be reproduced or distributed in any form or by any means (electronic, mechanical,
reprographic, recording or otherwise) without the prior written consent of the copyright owner.
Shell Global Solutions

Shell Global Solutions is a trading style used by a network of technology companies of the Royal Dutch/Shell Group.
Process Overview The various steps of the Problem Solving process are grouped into the
four phases described in the table below.
Phases Description Steps

I. The capture (recording) of an
Incident Capture incident along with relevant
information AND the decision as to
whether an RCA must be carried
out AND if so, at what level the
investigation will be conducted.
1. Incident Reporting
2. Incident Ranking
II. The breaking apart of a complex
Problem Analysis situation into manageable pieces.
Answers "what is the problem?"
3. Problem Identification
4. Problem Definition
III. The systematic search for cause(s)
Root Cause of a problem. Answers "why?”
Analysis
5. Possible Cause Analysis
6. Data Validation
7. Cause Verification
IV. A systematic technique to select
Solution best balanced choice (one that
Development eliminates cause without creating
new / worse problems).
8. Decision Identification
9. Criteria Selection
10. Alternative Solutions
11. Decision Analysis
Table of Contents This guide is divided into 5 sections.
Section Page
INTRODUCTION 0
INCIDENT CAPTURE 3
PROBLEM ANALYSIS 9
ROOT CAUSE ANALYSIS 21
SOLUTION DEVELOPMENT 35
GENERAL REFERENCE 45
® Shell Global Solutions International 2001 Confidential

OP 01.30472
Introduction

OP 01.30472
A GUIDE TO THE FACT BASED PROBLEM SOLVING PROCESS PAGE 1
INTRODUCTION
Purpose This document describes a rigorous fact based approach to Problem

Solving (often called Root Cause Analysis). It provides details of how to
solve problems through Cause Elimination. The purpose of this pocket
guide is to provide:
- a Structured Process and

- a Common set of Terms and Tools
all in one reference document.
Why a structured A structured process is needed because ……

process?
* Causes and Solutions to complex problems are rarely obvious,
* Adherence to the process ensures that Causes and Solutions are

fact based,
* Adherence to the process ensures that Solutions address Cause.
Root Cause Analysis IS NOT:

a group of people sitting around a table saying to themselves “what are we going to do
about this problem”
OK, we all
know what operators
no screwed up
the root
procedures again
cause is, you
the cheap poor
right? parts
contractor communications
Root Cause Analysis IS :

OP 01.30472
A GUIDE TO THE FACT BASED PROBLEM SOLVING PROCESS PAGE 2
a STRUCTURED process that looks in detail at the chain of events and conditions (causes
and effects) that resulted in the “Primary Effect” (the problem).
Root cause analysis is the heart of any “defect (or bad actor) elimination” program.
Effective defect elimination is one of the key success parameters of a reliability
management process.
The importance of Root Cause Analysis and Defect Elimination
Modern maintenance management consists of systems to address 4 major areas, those

being:
 Defect Elimination
 Work volume optimisation
 Efficiency of execution
 Reliability and integrity management
These major areas are interrelated and improvements in one area typically impact on one
or more of the other areas. Of the four, only “Defect Elimination” has an impact on each of
the other three as indicated in the diagram below. Consequently, with limited resources and
therefore the ability to only address one of these four areas, the most benefit is derived
from addressing Defect Elimination which requires a sound fact based problem solving
(root cause analysis) capability.
Defect
Elimination
Most leverage
from this point
ns
w Re
do
Reduces reactive work
k du
ea ce
br s
r of hi
gh
be pr
m io
nu rit
s y
uce w
d or
Re k
Reliability and Work Volume Efficiency of

Integrity optimisation Execution
Enables more
Reduces reactive work effective planning
Predictable work load
It is not the root causes we seek, it is effective solutions

OP 01.30472
PAGE 3
Incident
Capture
Phase I

OP 01.30472
INCIDENT CAPTURE PAGE 4
OVERVIEW INCIDENT CAPTURE
In this Phase The critical phase in any process is the kick-off or start. If you do not
start out with the correct ingredients, you will not get the desired result.
Likewise in the Problem Solving Process, the first phases, Incident
Capture and Problem Analysis, are essential to the success of
problem elimination. The first phase, Incident Capture, focuses on
capturing the information related to the problem, establishing the
consequences and deciding whether an RCA is required and if so at
what level.
Process Steps The process steps included in the Incident Capture phase of Problem
Solving are shown below and described in the pages that follow.
STEP 1: INCIDENT REPORTING
STEP 2: INCIDENT RANKING
STEP 1: INCIDENT REPORTING
Purpose (why) Similar to a good HSE Management System, a good Asset

Management System will have in place a mechanism for reporting
incidents. In the context of an Asset Management System, an “incident”
is typically defined as any event forcing a site away from their
production plan or causing a significant deviation off the budget or a
significant “near miss”. The threshold levels (investigate?: yes or no) for
various incidents must be defined by management. The purpose of this
step is to capture (immediately) the circumstances surrounding the
incident by those that were closely involved.
Process (how?) The Incident Reporting process sub-steps are as follows.
SUB-STEP TOOL(s)
Incident reporting Incident report (page
7)
Tips for Success 1. Stick to the facts in the Incident Report - avoid “storytelling”, avoid
categorisation of the incident or elements of it and avoid “who” or
“why”.
2. Don’t try to propose solutions.

OP 01.30472
STEP 2: INCIDENT RANKING
Purpose (why) In order to identify the most critical incidents so that the incidents that
can have (or have had) the most impact on the business are
addressed first with the limited resources that are available.
Process (how?) The Incident Ranking process sub-steps are as follows.
SUB-STEP TOOL(s)
Incident ranking RCA Risk Matrix
(page 8)
Tips for Success 1. Focus on the “first order” consequences or the consequences that
are the immediate effect of the incident, not “…after the incident,
“XYZ” might also have happened, etc…”
2. Be as specific as possible with the consequence scenario.

OP 01.30472
TOOLS: OVERVIEW
In this section: The following tools are described in this section:
TOOL PAGE
Incident Report 7
RCA Risk Matrix 8
These tools will be used in the first phase (Incident Capture) to describe and rank the
incident as soon after the incident as possible.
TOOLS: INCIDENT REPORT
What An Incident Report is the start point for any Problem Solving process.
An improperly configured or improperly completed Incident Report
almost guarantees the failure of any Problem Solving Process. The
improper definition of a problem usually starts with the Incident Report
especially one that is focused on solutions. The three most common
reasons for the failure of a Problem Solving process are:
1. Incomplete Problem Definition
2. Unknown causal relationships
3. A focus on solutions
When An Incident Report should be raised for incidents with a seriousness or

criticality above some threshold (trigger) established by the site
management. Some examples:
 safety incidents more serious than a First Aid Case
 equipment failure resulting in a deviation from the production plan
 equipment failures with consequences over $XX
Why To provide an initial record of an incident while data and memories are
still fresh and to provide the start point for a Problem Solving process.
How The Incident Report should include the following:

1. WHAT is the problem (the effect of the consequence) ?
2. WHEN did it happen ?
3. WHERE did it happen
4. What is the SIGNIFICANCE of the problem ?
Tips for Success Avoid “who” or “why”. Avoid a form with boxes to check (which may
improperly categorise the facts). Don’t jump to conclusions. Don’t try to
suggest solutions (that comes later). The Incident Report becomes part
of the final report on the incident. The example on the next page
indicates the minimum information required for an Incident Report.
Each site should configure their Incident Report Form to meet their
local requirements, the following example is just that - an example.

OP 01.30472
TOOLS: INCIDENT REPORT (cont)
This section to be INCIDENT REPORT FORM

completed at the
time of the 1. PROBLEM DEFINITION
incident. WHAT:
 WHEN:
WHERE:
SIGNIFICANCE
Safety:
Environmental: Risk Matrix
Production: Ranking:
Maintenance:
Frequency:
Sections 2 and 3 2. CAUSE & EFFECT SUMMARY

to be complete
See attached Cause & Effect Diagram
following the RCA
exercise

3. SOLUTIONS
CAUSES CORRECTIVE ACTIONS NAME DUE DATE
CONTACT:

OP 01.30472
TOOLS: RCA Risk Matrix
What The RCA Risk Matrix is a tool for ranking the criticality of incidents so
that low criticality events can be handled with the usual quality
management processes and the more critical incidents can be
addressed at an appropriate level.
When After an incident report is raised, the incident should be ranked on the
matrix. This information could be included on the incident report (it may
be challenged and changed later)
Why So that incidents are addressed at the appropriate level in the

organisation (or not at all) based on the seriousness of the incident.
Resources for carrying out RCAs are limited and the matrix helps
determine what will be investigated and at what level.
How First, establish the first order consequences (direct consequences) of

the incident, whether it be to People, Assets, Production, Environment
or Reputation (or some combination of these). Second, estimate the
probability of the incident occurring again. Locate the corresponding
box in the matrix where the incident falls and then take action
according to the guidelines below the matrix. Example, an equipment
failure that cost $50,000 to repair and resulted in $400,000 in
production loss AND that is likely to occur again in 1 - 2 years would be
ranked as a D3 incident.
Tips for Success Stick to “first order consequences” only.
CONSEQUENCE PROBABILITY
Likely in Likely in Several
Assets or
People Environment Reputation A Improbable B Possible C next 10 D next 1-2 E times per
Production
yrs years year
Firt Aid/ Slight Slight

<$10k 1
MTC Effect impact
Lost time $10k - Minor Limited

accident effect impact 2
100k
Perm. $100k- Localised Considerab

3
Disability 500k Effect le impact
Single $500k- Major Major

4
Fatality 10m Effect National
Multiple Massive Major

>10m 5
Fatality Effect Intern’al
Full Analysis required with Management Involvement
Full Analysis with Multi-discipline team - Leader and basic composition determined by Management
Analysis by relevant department using simple RCA tools - calling upon others where required
Analysis by relevant department e.g. discipline, offshore operations
No analysis required - Manage via normal Quality Procedures

OP 01.30472
PAGE 9
Problem
Analysis
Phase II

OP 01.30472
PROBLEM ANALYSIS PAGE 10
OVERVIEW PROBLEM ANALYSIS
In this Section Problem Analysis is essential to the success of problem elimination.

This phase focuses on identifying and defining the problem. All too
many times … in our eagerness to fix problems … we march off into
solving problems that are not well defined and thus do not eliminate the
cause. Close adherence (which takes discipline and practice) to the
process outlined in this section will help eliminate "working on the
wrong thing".
Process Steps The process steps included in the Problem Analysis phase of Problem
Solving are shown below and described in the pages that follow.
STEP 3: PROBLEM IDENTIFICATION
STEP 4: PROBLEM DESCRIPTION
STEP 3: PROBLEM IDENTIFICATION
Purpose (why) This first step is aimed at identifying the problem(s)at hand.
Many times the problem is unclear or there are several problems. This
can make it difficult to know just where to start. The process outlined in
this step and the tools referenced are used to help us determine where
to start. The final product of this step is the Problem Statement, which
provides a clear starting point and level of expectation.
Process (how?) The Problem Identification process sub-steps are as follows:
SUB-STEP TOOL(s)
Review the incident history, list Relation Diagram
the problems and concerns. (Inventory/cluster)
For each concern define the Timeline
issue, what was the trigger? (Sequence of
events)
Group issues into problem Change Model
areas.
Prioritise problems based on Pareto diagram
impact (identifying most
important)
Develop Problem Statement in Problem Statement
terms of expected vs. actual
performance
Tips for Success 1. Stick to the facts in the Incident Report.

2. Define boundaries of the problem during this first step.
Avoid being too broad or too narrow.
3. Review both current and historical records. Avoid treating a problem
as an isolated case. Remember "bad things don't simply just
happen”…. they are caused.
4. Keep it simple.
5. Be willing to look at the problem from more than one angle.

OP 01.30472
STEP 4: PROBLEM DESCRIPTION
Purpose (why?) This step of Problem Analysis answers the question:
“What facts do we have that indicate there is a problem?”
In this step there is much time spent on data collection. The more
accurately the problem can be defined in terms of what, where "it is”
and "is not”, the better final product in the Cause Analysis phase.
Process (how?) The Problem Description process sub-steps are as follows.
SUB-STEP TOOL(s)
Construct / develop Is/Is Not Is/Is Not Model
Model (Differentiation)
If the model has several empty Pin Point Analysis
boxes, use Pin Point Analysis Data Collection
determine additional data needs
As needed, review tools and Timeline
information from earlier step. Change Model
Tips for Success 1. Be sure of data quality, ... "just the facts!" is the motto.
2. Seek out data from various sources: Incident Report, data logs,
equipment history, operations, maintenance, engineering, other
locations, manufacturer and purchasing.
3. Utilise various methods to collect data: interviews, written reports,
strip charts, process computer, walk-through and observation.
4. Stay with the process. Do not short circuit the steps and jump into
cause analysis or solution development.
5. Answer the question WHAT and not why.

OP 01.30472
TOOLS: OVERVIEW
In this Section The following tools are described in this section.
TOOL PAGE
Data Collection 13
Relation Diagram 14
Time Line 15
Change Model 16
Pareto Diagram 17
Problem Statement 18
Is / Is Not (Differentiation) 19
Pin Point Analysis 20
When to use These tools will be used throughout the Problem Solving Process.
Recommended uses are listed along with each process step. However,
it is not expected that each tool will be used every time. Use them as
you see fit.
NOTE: The more you use the different tools the more familiar they
become. Selecting the best tool gets easier with practice.

OP 01.30472
TOOLS: DATA COLLECTION
Illustration
Data Quality:
Facts - verifiable, measurable, accurate
Inference - logical deduction based on facts
Assumption - logical hypothesis that could explain the facts
Opinion - gut feel, experience
Beliefs - others opinions
Hearsay - 2nd, 3rd & 4th hand information
Guess - educated, wild
Fantasy - no basis, distortion
What The means to justify the end … Data collection is the process of
gathering information from various sources, in various forms and of
various quality. Data quality by far is most important to the success of
this process (success = cause elimination).
When Initially and throughout the process.
Why To ensure that the process is fact based versus opinion, gut feel or
best guess..
How 1. Strive for highest quality data = FACTS.

2. Utilise several sources:
- books, process computer, field walk through, equipment
history, strip charts, log write up, interviews (operations,
maintenance, engineering, equipment manufacturers, "experts")
and tests.
Tips for Success 1. Make a list of data needs ahead of time to help reduce rechecks.
2. Use interviewing to get an understanding of beliefs and opinions
and then verify with higher quality data.
3. Target for FACTS.

OP 01.30472
TOOLS: RELATION DIAGRAM (Inventory / Cluster)
Illustration Initiating events

and
circumstances
Problem
(primary effect)
What A Relation Diagram or Inventory/Cluster technique is a visualisation of

the overall problem and the initiating events or circumstances and how
they are related.
When Relation diagram is used when trying to break a big problem into
manageable pieces.
Why The relation diagram helps to prioritise …the size of the clusters give a
sense of magnitude.
How 1. Place problem (effect) on the centre of the page.

2. Begin writing various initiating events or circumstances which
led to the problem.
3. Group by enclosing like / similar issues into the same cluster.
Tips for Success 1. You may want to try different criteria for grouping clusters.
2. Use logic in determining relationships.
3. Understanding the process or how the piece of equipment operates
may help in determining interrelationships. Ask for a review by an
"expert" or review documentation.

OP 01.30472
TOOLS: TIME LINE (Sequence of events)
Illustration Events
Jan-99 Mar May Jul Sep
What A graphic or list indicating the order in which events took place.
When Very useful when data sources are separate (2 interviews …) or when
several events happen in close time proximity. Also when looking at a
long term problem & reviewing history.
Why "A picture paints 1000 words"…it presents the situation in a single
glance.
How While reviewing records / data sources, jot information down on

horizontal time line (oldest date to the left). If written descriptions
are long or if the time frame is short, you may choose to write the
sequence of events in a list form. One column indicating date/time
and another column describing the event.
Tips for Success 1. Stick with the facts … if something is all assumption or is hearsay,
note that next to the item and then go try to find data to validate.
2. If the sequence is very long, it may be helpful to put only key events
on the chart and leave the details for the list.

OP 01.30472
TOOLS: CHANGE MODEL
Illustration Flow
Plan:
Actual:
Date / Time
What This type of chart is used to display performance over time. It shows
how output varies with time or how several outputs vary with time.
When Good way to display history of computer stored data. Especially when
comparing against a plan / target or related variables
Why Helps to pin point timing dimension of a problem. Also may point to
areas where more data may be needed in determining sequence of
events.
How Plot xy graph with time as the x (bottom/horizontal) axis.
Tips for Success 1. It is helpful to note significant events ( both planned and unplanned)
right on the chart. This helps eliminate confusion as to which
"changes" / blips are actual problems.
2. Maximum of 2-3 lines per graph to avoid busy and confusing charts.
3. Be careful when using "averaged" data. It may hide / mask the
problem. Before saying the chart indicates "no problem" check to
see what better resolution data shows.

OP 01.30472
TOOLS: PARETO DIAGRAM (Bar Chart)
Illustration EFFECT
(impact)
Greatest impact
Leak Trip Cleaning Unknown

CAUSE (initiating event)
What A Pareto diagram is a special form of bar graph used for ranking or
prioritising data.
When It can be used to determine what problem(s) to work on first, determine

which is most frequent and / or results in greatest impact.
Why To ensure you are working on item of greatest consequence. Fact

based versus "gut feel".
How 1. Gather data about the situation by cause category or initiating

event (refer to Relation Diagram).
2. Rank data largest impact / # incidents to smallest.
Draw bar chart showing large to small, left to right.
3. Develop Problem Statement for the largest bar.
Tips for Success 1. Sort and plot data using various measure for impact, y axis: i.e.
duration,
# of times, cost, impact to operations, safety.
2. Analyse different groupings of data: i.e. by product, by equipment
number, by shift … use your imagination. This may help to bring out
different distinctions or patterns.

OP 01.30472
TOOLS: PROBLEM STATEMENT
Illustration
Problem
Statement = Expected - Actual + Impact
Example:
Expected - Pump xyz is expected to have flowrate of 1000 M3/hr.
Actual - Since July 7 pump xyz has a max. flowrate of 800 M3/hr.
Impact - This lower flowrate results in a $5,000/day production loss.
What Statement of the problem in terms of an object, it's defect, and the
impact of the defect.
When Each and Every Time.
Why To ensure common agreement on what the problem is and what the
expected performance is.
How Simply write the three headings: Expected, Actual and Impact and
then write a sentence or two describing each. Combined, the
sentences must contain the following:
an object: the specific process, equipment or

activity that does not perform as
expected.
a defect: the difference between the expected

performance and the actual
performance /output.
so what: the measurable extent of the

difference or .... why should I care?
Tips for Success 1. Keep Problem Statement posted to help maintain focus.
2. Multiple Problem Statements may be required.
3. Multiple Impacts are also possible and likely.

OP 01.30472
TOOLS: IS / IS NOT (Differentiation)
Illustration IS NOT DISTINCT CHANGE
(what) Identity
(where) Location
(when) Timing
(how much) Extent
What Is / Is Not Model provides a detailed description of where the problem

exists and where it does not exist. It also uses the technique of
differentiation (comparison to like situations) to help identify possible
causes of the problem.
When Each and every time complete "Is". When a comparison exists
complete both the "Is" and “Is Not” column.
Why Defining the dimensions of the problem will enable you to have a
comparison for separating Possible Causes and Root Causes.
How Answer the following questions and fill In the chart.
IS Identity: What item specifically has trouble? What is wrong with it?
Location: Where on item did it happen? Where was item located?
Timing: When did it happen - time, before /after, point in cycle?
Extent: When it happens how much is affected? Any pattern?
IS Identity: Are there similar items? How are they affected?

NOT Location: What parts are unaffected? Are others having trouble?
Timing: What are other likely times? Is it happening then too?
Extent: Is some portion consistently not involved? ... is this usual?
Tips for Success 1. Refer to Time Line or Change Model for Timing information.
2. Put facts only on chart, else Pin Point Analysis to determine data
needs.
3. Use several data sources to help pin down all 4 dimensions.

OP 01.30472
TOOLS: PIN POINT ANALYSIS (Simplified Is /Is Not)
Illustration
IT IT IT is
Definitely Might NOT...
is... be...
What Process that encourages divergent thought. It is a simpler form of Is / Is

Not analysis.
When In developing Is / Is not … provides a good means of capturing ideas

that need verification before putting into Is / Is Not.
Why Sometimes initial data collection is insufficient to complete the Is / Is

Not. The “might be chart” of pin point analysis provides a list of what
data is needed for verification and the other charts show where you
already have sufficient evidence.
How 1. Prepare three flip charts, one heading a piece:

- “It Definitely Is”
- “It Might Be”
- “It Is Not”
2. As a team, list possibilities on the appropriate chart. Ask and
answer the questions When ? and Where?
3. Use the might be chart as the worklist for data collection. As a
team determine where / how to get data.
Tips for Success 1. Don't ask "Why?" yet, you will short circuit the process.
2. Note sources of supporting fact references next to each item.

OP 01.30472
PAGE 21
ROOT CAUSE
ANALYSIS
Phase III

OP 01.30472
ROOT CAUSE ANALYSIS PAGE 22
OVERVIEW ROOT CAUSE ANALYSIS
In this Section The third phase of the Problem Solving Process is Root Cause
Analysis, RCA. RCA focuses on determining the causes of the
problem as identified in the Problem Statement and as defined by the
Problem Description. As in the previous phase, the success of RCA is
impacted by the level of adherence to the process and the quality of
the data used in the process. During Root Cause Analysis you must be
careful no to fall into the traditional pattern of jumping to conclusion.
Again, adherence (which takes discipline and practice) to the process
outlined in this section will eliminate unfounded causes and will provide
details of how the root causes identified explain the effects.
Process Steps The process steps included in the Root Cause Analysis phase of
Problem Solving are listed and illustrated below. Descriptions of each
step and each tool are provided in the remainder of this section.
STEP 5: Possible Cause Analysis
STEP 6: Data Validation (logic check)
STEP 7: Cause Verification

OP 01.30472
SOME USEFUL TIPS:
 “Going far enough or too far”
pump failed
bolt loose
mechanic error
tired
didn’t sleep how far do we go?
child sick
ate bad food
dirty restaurant
cook didn’t wash hands
root cause??
“In general, failure modes (root causes ) should be identified in enough detail for it to be
possible to identify an appropriate failure management policy.”
John Moubray, “father” of classical RCM
In simple terms, this means we must “drill down” far enough to find a root cause that can be
managed. In the example above, it is not possible to manage the cleanliness of the
restaurant, but it is much more likely that we can put systems in place to prevent the
mechanic’s error.
 “We tend to concentrate on technical causes”
We like technical solutions (we are technical people), but there is plenty of evidence that at
least 50% of failures have human related causes... often because people are doing what
they think is correct (training or operating philosophy) or because they are following
instructions that are wrong or because the instructions are inaccurate or unclear.

OP 01.30472
STEP 5: POSSIBLE CAUSE ANALYSIS
Purpose (why) The purpose of this step is to determine as many possible causes of
the problem. In this step we are finally ready to ask and begin
answering the questions:
“Why did it happen?"

“What could cause that to happen?"
The final product of this step is a list of Possible Causes: causes that
could result in an effect equal to the problem.
Process (how?) The Possible Cause Analysis process sub-steps and tools are as
follows. Note: you may find it necessary to recycle through the sub-
steps and or tools several times.
SUB-STEP TOOL(s)
Determine the Proximate Causes of the Stair Step
Problem: closest/lowest known factual Fault Tree Analysis
causes of the Problem before going to Change Analysis
assumptions.
Ask: “Why did it happen?”
Determine / Brainstorm Possible Causes of Fishbone Diagram
each Proximate Cause. Human / System
Ask: “What could cause that?" Checklist Review
Tips for Success 1. Be aware of problems that appear to have 1 easy straight forward
answer. You may have a tendency to jump to conclusions and short
circuit the process. There are likely other causes that need to be
addressed.
2. If you find yourself listing "it is a piece of junk", "bad things happen"
or "it is just old" make sure you go back and repeat the step one
more time ... ask someone else for input.
Remember: "bad things don't just happen, they’re caused.”

OP 01.30472
STEP 6: DATA VALIDATION (and Logic Check)
Purpose (why?) The purpose of Validation is to determine which of the Possible Causes
determined in Step 5 have supporting facts. This step is focused on:
eliminating poor logic and unverifiable data. This is done to ensure the
Problem Solving Process remains fact based so that the follow-up
recommendations will address cause.
Process (how?) The following chart illustrates the validation process sub-steps.
Process SUB-STEP / Question If “YES” If “NO”

1. Review each Possible Cause Then it Go on to
and ask “do I have facts to becomes a question 2.
support this cause?” Probable
Cause.
2. Next ask "do I have facts to Then remove it Go on to
eliminate this cause?” from the list question 3.
3. Then ask "is more data Then go in Keep it on
available to confirm or deny search of the Cause
this cause?" additional data / List
facts.
Tips for Success 1. Maintain the process rigor, remember a traditional belief is not a fact
unless you have supporting evidence.
2. Although there are no specific tools for this step, the following tools
may be of help:
a) Pin Point Analysis = help determine data needs
b) Data Collection = provide ideas for data sources and a

reminder about data quality.

OP 01.30472
STEP 7: CAUSE VERIFICATION
Purpose (why?) The final step of RCA is to verify and identify which of the Probable
Causes and remaining Possible Causes match each dimension of the
Problem Description including:
Identity Location Timing Extent
The purpose for verification is to maintain a fact based focus and to

ensure that the causes remaining are linked to the problem. Those
causes matching the Problem Description and verifying the problem
become Root Causes. Causes that match the 4 dimensions yet can not
be verified remain as Probable Causes.
Process (how?) The process sub-steps of Cause Verification are provided below.
Process SUB-STEP / Question If “YES” If “NO”

1. Take each validated cause Go on to step Remove
and compare to Is /Is Not, 2. from cause
ask “does it meet all 4 list.
dimensions?”
2. Next ask "do I know for a It is a Probable Go on to
fact it can cause the Root Cause step 3.
problem?”
3. Then ask "is the problem It becomes a Go on to
repeatable by initiating Root Cause step 4.
cause?”
4. Finally ask "will reversing It becomes a Remains a
cause eliminate the Root Cause Probable
problems?" Cause.
Tips for Success 1. If the cause doesn't fit the all 4 dimensions … it is not a viable cause
for the problem.
2. Be careful of diluting list of Root Causes with "other problems that
are non-fact based", see tip 1.
3. Don't short circuit this stop with "Expert Opinion".
4. 100% Verification is not always possible. Some items may require
shutdown for internal inspection.

OP 01.30472
TOOLS: OVERVIEW
TOOL PAGE
Cause and Effect Diagram 28
Stair Step 30
Fault Tree Analysis 31
Change Analysis 32
Fishbone Diagram 33
Human / Systems Checklist 34
When to use These tools will be used throughout the Problem Solving process.
Recommended uses are listed along with each process step. However,
it is not expected that each tool will be used every time. Use them as
you see fit.
become. Selecting the best tool gets easier with practice.

OP 01.30472
TOOLS: CAUSE AND EFFECT DIAGRAM
Illustration
ACTION
Cause
Caused Evidence
Primary By
Effect CONDITION
Evidence
Cause
Evidence
What The Cause and Effect Diagram developed by Apollo Associates (RCA
consultancy) is probably the most useful and frequently used RCA tool.
It is a technique that is easy to learn and can be used in virtually every
situation.
When As a first step in Root Cause Analysis. After the Problem Statement
and Problem Description are completed.
Why Simple and effective
How 1. Start with Primary Effect and ask: this was “caused by” ?
2. Answer with facts supported by evidence, not opinions and take
small steps - the cause of the Primary Effect is also an effect of
another cause and so the sequence continues.
3. Then ask: “.. and this effect was caused by?”
4. Again, answer with facts, not opinions.
Tips for Success 1. Stick with the facts supported by evidence.

2. Be diligent, continue to ask “caused by?”, “caused by?”, “caused
by?” .…

OP 01.30472
Example 1 Cause and Effect Diagrams
An effect is the result of a cause (action or

condition).
BUT….causes are also effects
Primary Effect Effect Effect
Effect
CB CB CB CB
Pipe Acid
Corrosion etc etc
failed present
Cause Cause Cause
Note: CB = “caused by”
Example 2
By working
backwards from
the Primary Problem
Effect, the
objective is to
establish a cause
and effect chain
of events until a
manageable root
cause is
Cause & Effect
identified
Relationships
Solutions

OP 01.30472
TOOLS: STAIR STEP (5 Whys?)
Illustration Problem
WHY Problem ?
Because 1
WHY Because 1 ?
Because 2
WHY Because 2 ? CAUSE
Because 3
WHY Because 3 ?
Because 4
Proximate Causes WHY Because 4 ?

?????
What Stair Step is a convergent questioning discipline to assist in discovering

the Proximate Causes of a problem (closest known factual cause
before guessing).
When As a first step in Root Cause Analysis. After the Problem Statement
and Problem Description are completed.
Why By asking "why" 5 times … you often get to the level of Proximate
Cause versus a "superficial" cause.
How 1. Start with Problem Statement, ask: "Why did it happen?

2. Answer with facts, not opinions.
3. Then ask: “.. and why did that happen”?.
4. Again, answer with facts, not opinions.
5. Continue with this process until the answer is not a fact. At this
point you may either: go collect more data to see if you can find
factual data to support the answer (if data is found to support
then resume asking the question "why?"), or go back one step
and take the last known fact, this is the Proximate Cause
Tips for Success 1. Stick with the facts.

2. Be diligent, continue to ask why?, why?, why?, why …

OP 01.30472
TOOLS: FAULT TREE ANALYSIS
Illustration
PROBLEM
and
Cause 1
or
Cause 2 Cause 3
No facts
to support Cause 4
What A deductive technique that focuses on one system failure or accident.

The Fault Tree is a graphical model that displays a combination of
equipment failure and human/systems failure that together form a
system failure.
When Single failure or single accident that has multiple causes.
Why "A picture paints 1000 words" … at one glance shows the
interrelationship and complexity of cause.
How Use Boolean logic gates to describe possible events or causes.
AND both events or conditions must he satisfied.
OR either condition can cause the problem.
1. Construct a diagram of all the possible causes.

2. Eliminate causes that you have data to disprove.
3. Remaining items are fact based Proximate Causes.
Tips for Success 1. Consult all expert to help determine possible causes.
2. Note, causes can be of two types:
- Temporary (fault): will heal itself thus no "smoking gun", facts are
difficult to find.
- Permanent (failure): needs to be repaired before it will work
again, facts tend to be more obvious.

OP 01.30472
TOOLS: CHANGE ANALYSIS
Illustration
What What What

happened happened changed
this time? last time? ?
What Change Analysis is another method of differentiation used to help

identify Proximate Causes and Possible Causes.
When comparison data is available (i.e. similar piece of equipment or

process).
Why Putting it down on paper for the whole team to see is helpful. Also,
comparison helps to highlight differences … these differences may be
cause related.
How 1. Analyse / List significant facts about current situation.

2. Analyse / List significant facts about a previous time when the
problem did not occur.
3. Compare Lists 1 and 2: a) list all know differences (fact based) =
Proximate Causes and b) list all possible differences = Possible
Causes.
4. Analyse each cause to see if it could cause the problem. If yes,
keep as a Probable Cause. If no, cross off list.
Tips for Success 1. Using this technique to ask questions in interviews may be helpful.
2. Remember, not all differences or changes are causes.

OP 01.30472
TOOLS: FISHBONE DIAGRAM (Cause and Effect)
Illustration
“EFFECT” “CAUSES”
Human /
Process Systems
Proximate
causes
Equipment Procedures
& materials
What A Fishbone diagram is a structured process for visualising and

identifying all possible causes of a problem.
When After Proximate Causes (fact based) are determined.
Why Completing a Fishbone encourages divergent thought. This helps to

keep an open focus and not miss any possible causes.
How 1. Draw a Fishbone as Illustrated above, placing the Proximate

Cause at the "head" of the fish.
2. Fill in the Fishbone by answering the question "what could
possibly cause the problem?”
3. Look at causes in each of the areas listed: Process, Human /
Systems Interface, Equipment & Materials, and Procedures.
Tips for Success 1. Be exhaustive, don't settle on one easy or obvious answer, (usually
this is too easy and you may miss some important issues that need
to be addressed).
2. You may want to use this tool in conjunction with the Human /
Systems Interface Checklist.

OP 01.30472
TOOLS: HUMAN / SYSTEMS INTERFACE CHECKLIST
Checklists Lack of Knowledge or Execution Blockage

Skill (external stressor)
(internal stressor)
 Insufficient Knowledge  Inadequate Instruments

 Deficient Procedure  Conflicting Priorities
 Inadequate Feedback  Poor Layout (mirror
image)
 Inadequate Tools  Excessive Mental
Tasks
 Inadequate Practice  Disabled Equipment
with back-up systems and alarms
 Insufficient Initial  Violation of
Training Populational
Stereotypes
 Insufficient Follow-up /  Policy / Practice
Refresher Training Discrepancies
What These Human / Systems Interface Checklists are based on the belief
that: humans do not intentionally commit stupid or irrational acts.
When Use whenever there is human involvement.
Why To ensure focus on Cause versus Blame.
How Utilise the checksheet above in developing list of Possible Causes.

It can be used alone or with the Fishbone Diagram.
Tips for Success 1. Try to put yourself "in the other person's shoes".
2. Review interview notes with this list in hand, may help highlight an
issue or potential cause.
3. If you find that a procedure is not followed, ask why?
4. During a site visit or field walk through look for the error prone
situations (mirror Image controls, poor equipment / instrument
labelling, poor housekeeping, pencilled instrument positions).
5. Unless facts prove otherwise, assume no one makes mistakes
on purpose, .. search until you find the reason.

OP 01.30472
PAGE 35
Solution
Development
Phase IV

OP 01.30472
SOLUTION DEVELOPMENT PAGE 36
OVERVIEW SOLUTION DEVELOPMENT
In this Section The final phase in the Problem Solving Process is Solution
Development. The task of Solution Development is to determine:
“What do we do to eliminate cause, …

... the root causes uncovered in RCA?
The Solution Development process described in this section provides a

method for: specifying what is to be accomplished; specifying minimum
solution requirements; evaluating and comparing solutions; and
understanding the benefits and risks associated with each solution.
Adherence to this process will not only ensure that solutions address
cause. It will also ensure that solutions will not be the cause of future
problems.
Process Steps The process steps included in Solution Development are listed below
and are described in the pages that follow.
STEP 8: DECISION IDENTIFICATION
STEP 9: CRITERIA SELECTION
STEP 10: ALTERNATIVE SOLUTIONS
STEP 11: DECISION ANALYSIS

OP 01.30472
STEP 8: DECISION STATEMENT
Purpose (why?) The Decision Statement provides the focus for everything that follows.
The purpose of the Decision Statement is to ensure a common
understanding of what is to be accomplished. Agreement on the
Decision Statement will prevent working on the wrong problem. Most
importantly, the Decision Statement is the critical link between RCA and
Solution Development. The Decision Statement must be linked to
cause in order for the solution to eliminate cause.
Process (how?) 1. Write and review the root cause and ask:
a. What is the object / subject?
b. What is the desired action?
c. What is the intended outcome of the action?
(in terms of: how much, which, what purpose)
2. Take the answers to the questions above and develop

a 1 - 2 sentence Decision statement which includes the object,
an action and the desired result. Use the object to define the
boundary of the solution.
example
Root Cause: Debris in Instrument Air plugged the positioner of the trip
valve which in turn shutdown the unit.
1. a. debris in Instrument air; b. eliminate or prevent;

c. false trip and unit shutdown
2. GOOD: Prevent debris in Instrument Air System from causing false

trips which result in unit shutdown
BAD: There is a need to improve Instrument Air quality, especially

to unit trip valves.
Tips for Success 1 Make sure the Decision Statement addresses cause.
2. Avoid making the statement too broad or too narrow.
Note: the BAD example provided above is too narrow.

OP 01.30472
STEP 9: CRITERIA SELECTION
Purpose (why?) The purpose of Criteria Selection is to define the specific factors to be
satisfied by the solution. It provides a common definition and
agreement on what we want to achieve and what is acceptable. This in
turn enables us to compare different solution options objectively since
we have already defined the needs and wants of the desired outcome.
(remember, a moving target is harder to hit ... the first few tries might
be misses!)
Process (how?) The process of developing Criteria Selection is a matter of:

defining Required Ends (Musts) and Desired Ends (Wants):
1. Define the Required Ends by asking:

a. "What must the solution achieve?"
b. "What must the solution avoid?"
c. “What must the solution maintain?”
2. Define the Desired Ends by asking:

a. "What would the ideal solution achieve?"
b. "What would the ideal solution avoid?"
c. "What would the ideal solution maintain?"
3. Fill in the Selection Grid (see page 42) with the "Musts"
determined in 1 and the "Wants" determined in 2. For each
"Want" assign a weight of relative importance on a scale of 0 -
10 (10 being the most important).
Tips for Success 1. Needs - set limits for an acceptable choice, they are both mandatory
and measurable.
2. Wants - help determine relative performance.
3. Make sure you set up criteria before generating alternate solutions.
Otherwise you will short circuit the process and may skew the
criteria towards a preferred alternate.

OP 01.30472
STEP 10: ALTERNATIVE SOLUTIONS
Purpose (why?) The purpose of generating Alternative Solutions is to ensure a broad

look is taken. For example, sometimes the "ideal"(meets all our needs
and wants) solution is beyond financial reach. However, a solution that
meets our minimum requirements (needs) may be cost justified. Also,
there are several ways to resolve problems. This step focuses on
looking for solutions in other places besides "hardware upgrade",
or "new and improved “equipment. Sometimes it is not the
mousetrap that needs replacement... it may just need a different
location or a revised set-up procedure.
Process (how?) A number of Alternative Solutions should be developed at the concept

level. At a minimum, try to develop one or more alternatives for each of
the following categories.
1. Capital Project
2. Non-capital Project
3. Procedure Change / Documentation
4. Training: Skills / Knowledge
5. Status Quo (No Change)
6. Combination of the above
If the team is having difficulty thinking of alternatives, try using the

Solution Thought Gallery tool described on page 43.
Tips for Success 1. Do not start this step until after completing Criteria Selection.
2. Be innovative, think of solutions "outside the box".
3. This is another good time to talk to the "experts" to find out what
they would recommend. Find out what works and what hasn't
worked.
4. Review the Fishbone Diagrams for improvement opportunities. The
categories of Human / Systems and Procedures should help
generate non-hardware related solution alternatives.

OP 01.30472
STEP 11: DECISION ANALYSIS
Purpose (why?) The purpose of Decision Analysis is to provide a means for determining
the "Best Balanced Choice" That is the choice that meets all of the
minimum requirements and imposes the least risk for creating other
problems. Using the tools described in this section will enable you or
your team to make a decision based on agreed upon requirements and
facts versus opinion.
Process (how?) The two primary tools used in Decision Analysis are referenced in the
process sub-steps listed below.
SUB-STEP TOOL
Compare benefits of each Selection Grid
Alternative Solution versus
the Selection Criteria. Delete
alternatives that do no meet
all the "Musts".
Take the 2 -3 alternatives with Prevention Planning
the highest weighted score (Risk Matrix)
and evaluate the risk
associated with
implementation.
Using the weighted score and Selection Grid
the risk matrix, select the Prevention Planning
Best Balanced Choice. That (Risk Matrix)
is the alternative with the
Highest
Benefit at the Lowest Risk.
Tips for Success 1. The prevention planning step is critical to ensuring long success of
cause elimination since it focuses oil preventing new causes of the
same or related problem.
2. Just because an alternative has the highest weighted score doesn't
mean it is the best choice if it poses a high risk.

OP 01.30472
TOOLS: OVERVIEW
TOOL PAGE
Selection Grid 42
Solution Thought Gallery 43
Prevention Planning 44
When to use Recommended uses are listed along with each process step.
become.

OP 01.30472
TOOLS: SELECTION GRID
Illustration
Solution Criteria ALTERNATIVES
MUSTS Alt A Alt B Alt C Alt D
Must Achieve
Must Maintain
Must Avoid
raw wgt. raw wgt. raw wgt. raw wgt.
WANTS weight scor scor scor scor scor scor scor score
e e e e e e e
Want 1
Want 2
Want 3
Want 4
Total Weighted Score
What Tool for combining and comparing various Solution Alternatives with the
agreed upon solution Selection Criteria.
When During the Solution Development phase.
Why Provides an Objective means to compare different types of Solutions

versus Subjective. Quantitative comparison.
How 1. Compare each Alternative Solution to the MUST Criteria. If any

of the MUSTS are not met, then that Alternative is crossed off
the list.
2. Compare each Alternative Solution to the WANT Criteria giving a
Raw Score of 0 - 10 (10 is best) / or use -5 to +5 with 0 = no
effect.
3. Calculate the Weighted Score of each criteria by multiplying the
Raw Score times the Weight. Write the result in the Wgt. Score
column.
4. Calculate the Total Weighted Score of each Alternative by
adding the Wgt. score column.
Tips for Success 1. Try to be consistent with the raw scores.

2. Remain as fact based as possible.

OP 01.30472
TOOLS: SOLUTION THOUGHT GALLERY
Illustration
Rules Methods Hardware /
Req’ments Procedures Facilities:
Expectations Action steps
What Modified version of Brain Storming.
When Use when generating Solution Alternatives. Especially when in a team

with differing levels of authority and/or experience.
Why To aid in generating a variety of Solution Alternatives. To help break out

of the mode of "replace with new is the only answer".
How 1. Set up flip charts with the following headings/ topics:

a. Rules / Requirements / Expectations
b. Methods / Procedures / Action Steps
c. Hardware / Facilities : Add / Revise / Replace
d. Standards: Design / Repair
e. Communication
f. Other …
2. In pairs of two or alone, go from chart to chart and think of
possible solutions (much like looking at art in an Art Gallery)
and write them on the chart.
3. Review the charts: combine like ideas where possible, clarify
ideas is needed, and decide on several as Solution Alternatives.
Tips for Success 1. Follow the rules for Brain Storming. Don't criticise ideas. Build off of
other ideas. Be creative. Everyone participates.
2. Feel free to add to the categories listed above.

OP 01.30472
TOOLS: PREVENTION PLANNING
Illustration Likelihood
High
Safe to Implement ?
Medium
Yes, with or without mitigation
Low
OK, with mitigation
Low Medium High

Avoid this situation
Consequence
What A process of planning ahead to prevent future problems that could

result from solution implementation. Provides a way to assess the risk
of implementation from both a SUCCESS aspect and a SAFETY
aspect.
When After completing the Selection Grid.
Why The prevention Planning step is necessary because the alternative with
the highest weighted score is not always the best in terms of SAFETY
or SUCCESS.
How 1. Assess the relative SUCCESS and SAFETY factors of each

alternative meeting all of the must Criteria.
2. To assess the SUCCESS factor, answer the following:
WHAT COULD GO WRONG?
a.What requirements for success have we missed?

b.What factors in the organisation could hinder
implementation?
c.What new regulations might affect the long term success?
If any of these issues can not be resolved, the alternative should

he removed from the list.
3. To assess the SAFETY factor, answer the following:
WHAT NEW PROBLEMS COULD THIS CAUSE?

SHOULD I BE CONCERNED?
Use the Risk Matrix illustrated above to answer the second

question. Be sure to include required mitigation plans.

OP 01.30472
PAGE 45
General
Reference

OP 01.30472
PROBLEM SOLVING PROCESS - GENERAL REFERENCE PAGE 46
OVERVIEW GENERAL REFERENCE
In this Section The following reference topics are provided in this section.
REFERENCE TOPIC PAGE

Problem Solving Process Map 47
Index to Tools 48
Glossary 49
Abbreviations 50
Bibliography 51

OP 01.30472
PROBLEM SOLVING PROCESS MAP
Purpose The purpose of the Problem Solving Process Map is to provide you
with an overview of the whole process. Once you become familiar with
the tools and the steps this may be all you need for a reference.
Process Map The Problem Solving Process Map is provided below.
PHASE STEP END PRODUCT

Incident 1.Incident Reporting Record of incident
Capture 2.Incident Ranking Criticality of incident
Problem 3.Problem Identification Problem Statement
Analysis 4.Problem Description Is / Is Not Model
Root Cause 5.Possible Cause Possible Causes
Analysis Analysis Probable Causes
6.Data Validation Root Causes
7.Cause Verification
Solution 8.Decision Statement Decision Statement
Development 9.Criteria Selection Solution Criteria
10. Alternative Possible Solutions
Solutions Best Balanced Choice
11. Decision
Analysis
Tips for Success 1. Work on one phase at a time, one step at a time to prevent short
circuiting the process.
2. Be sure of data quality, keep to the FACTS.
3. Keep the Problem Statement posted to maintain focus.
4. Keep all work and post on the wall so that you always know where
you are in the process.
5. Use multiple types of data front multiple sources.
6. Remember the importance of defining all 4 dimensions of the
problem: Identity, Location, Timing and Extent.
7. "Bad things" don't just happen .... they are caused.
8. Stick with the Process, stick with the process ........

OP 01.30472
INDEX TO TOOLS X Tool used every time for this step.

 Common tool used for this step.
TOOL NAME PROCESS STEP NUMBER PAGE

#
1 2 3 4 5 6 7 8 9 10 11
Incident Report X
RCA Risk Matrix X
Relation Diagram 
Time Line 
Change Model  
Pareto Diagram  
Problem Statement X
Is / Is Not X X
Pin Point Analysis  
Data Collection X  X 
Cause and Effect Diagram 
Stair Step 
Fault Tree Analysis   
Change Analysis 
Fishbone Diagram   
Human / Systems Checklist 
Selection Grid  X
Solution Thought Gallery 
Prevention Planning X

OP 01.30472
GLOSSARY OF TERMS
Brainstorming A group problem solving technique that involves spontaneous

contribution of ideas from all members.
Cause Initiating event that brings about a problem or effect.
Convergent Tending to move toward one point, down one path. Closed
focus.
Corrective Action Addresses root cause in order to eliminate recurrence of the

problem.
Deductive Inferred or traced conclusion by the course of reasoning,
Differentiation The process of identifying differences that distinguish.

Recognising distinctions.
Divergent Leading away from in different directions. Open focus.
Effect Consequence, result, impact.
Hypothesis Tentative assumption that must be tested in order to validate.
Interim Action Addresses Proximate and Probable Causes or effects as a

short term fix until Corrective Action can be implemented.
Populational Stereotype Common mode of operation, expected action: i.e. light switch
up = on and down = off, valve turn clockwise = shut and
counter-clockwise = open.
Possible Cause Cause that could result in an effect equal to the problem.
Probable Cause When a Possible Cause is validated to exist presently or

during the time of the problem.
Pin Point Analysis Process used to differentiate between facts and likely
possibilities or ideas. Helps determine where additional data
needs exist.
Proximate Cause Closest or lowest known factual cause of the problem before
guessing and going to assumptions.
Trigger Initiating event that brings about a problem or effect.
Validation Logically correct and supported by facts.
Verification To establish accuracy or reality.

OP 01.30472
ABBREVIATIONS
CA Corrective Action
FTA Fault Tree Analysis
RCA Root Cause Analysis

OP 01.30472
BIBLIOGRAPHY: Works Used as Reference
The following works served as reference material for this booklet.
Ishikawa, Dr. Kaoru, "Guide To Quality Control", Asian Productivity Organisation, Minato,
Tokyo Japan, 1982.
"Guidelines for Hazard Evaluation Procedure " 2nd Edition, Center for Chemical Process
Safety of the AIChE, New York, New York, 1992.
Kepner, C. H. & Tregoe, B., ”The New Rational Manager”, Princeton Research Press,
Princeton, New Jersey, 1981.
Lorenzo, D. K., "A Managers Guide to Reducing Human Error", Chemical Manufacturers
Association Inc., 1990.
"Meeting Power", The Herrington Group, Houston, Texas, 1993 - 1994.
“Problem Solving & Decision Making (A logical approach to common sense )", TJ Hansen
Company, Dallas, Texas, 1982.
"Multiple Root Cause Analysis Fundamentals for Performance Improvement”, G. W.

Stockholm / Shell Oil Company, March 1994.
Gano, Dean L., “Apollo Root Cause Analysis”, Apollonian Publications, 1999
Gano, Dean L., “Root Cause Analysis for Managers”, Apollo Associated Services, Inc.,
January, 1999 version

OP 01.30472
Distribution
Report number : OP.01.30472
Title : A Guide to the Fact Based Problem Solving Process
Subtitle : Rev. 3
Date of issue : June 19, 2001
Author(s) : M. Oliver OGCR
Owner / custodian : M. H. Oliver OGCR

(responsible for approving contents and
distribution of report)
Activity code : 63106338
Sponsor/customer :
Keywords : Root Cause Analysis, MERIT, reliability, maintenance
Electronic file :
Issuing Library : Shell Global Solutions, The Hague OGF/3 (Reports Library)
Distribution : Shell Global Solutions, The Hague OGF/3 (Reports Library) (number
of copies)
M. Oliver (OGCR) 1
J. Kemp (OGCR) 1
J.Redman (OGCR) 1
K. Dawood (OGCR) 1
J. Totty (OGCR) 1
T. Magowan (OGCR) 1
T. Gerber (OGCR) 1
C. Mitchell (OGCR) 1
M. Das (OGCR) 1
E. Ringstead (OGCR) 1
A. Kruijer 1
Restrictions on : No distribution of copies without consent of M. Oliver (OGCR) or J. Kemp (OGCR))

distribution
Additional : Any additional distribution (outside the above mentioned distribution list) can only
distribution be effected with special permission of owner/custodian (see above).

OP 01.30472

A Guide To Fact Based Problem Solving

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Guide To Fact Based Problem Solving

Hochgeladen von

Copyright:

Verfügbare Formate

Shell Global Solutions

© Shell Global Solutions International B.V., 2001. All rights reserved.

Shell Global Solutions

Phases Description Steps

Table of Contents This guide is divided into 5 sections.

® Shell Global Solutions International 2001 Confidential

® Shell Global Solutions International 2001 Confidential

Purpose This document describes a rigorous fact based approach to Problem

- a Structured Process and

all in one reference document.

Why a structured A structured process is needed because ……

* Adherence to the process ensures that Causes and Solutions are

* Adherence to the process ensures that Solutions address Cause.

Root Cause Analysis IS NOT:

Root Cause Analysis IS :

® Shell Global Solutions International 2001 Confidential

The importance of Root Cause Analysis and Defect Elimination

Modern maintenance management consists of systems to address 4 major areas, those

Reliability and Work Volume Efficiency of

Predictable work load

It is not the root causes we seek, it is effective solutions

® Shell Global Solutions International 2001 Confidential

® Shell Global Solutions International 2001 Confidential

OVERVIEW INCIDENT CAPTURE

STEP 1: INCIDENT REPORTING

STEP 2: INCIDENT RANKING

STEP 1: INCIDENT REPORTING

Purpose (why) Similar to a good HSE Management System, a good Asset

Process (how?) The Incident Reporting process sub-steps are as follows.

® Shell Global Solutions International 2001 Confidential

STEP 2: INCIDENT RANKING

Process (how?) The Incident Ranking process sub-steps are as follows.

® Shell Global Solutions International 2001 Confidential

In this section: The following tools are described in this section:

TOOLS: INCIDENT REPORT

When An Incident Report should be raised for incidents with a seriousness or

How The Incident Report should include the following:

® Shell Global Solutions International 2001 Confidential

TOOLS: INCIDENT REPORT (cont)

This section to be INCIDENT REPORT FORM

Sections 2 and 3 2. CAUSE & EFFECT SUMMARY

® Shell Global Solutions International 2001 Confidential

TOOLS: RCA Risk Matrix

Why So that incidents are addressed at the appropriate level in the

How First, establish the first order consequences (direct consequences) of

Tips for Success Stick to “first order consequences” only.

Firt Aid/ Slight Slight

Lost time $10k - Minor Limited

Perm. $100k- Localised Considerab

Single $500k- Major Major

Multiple Massive Major

Full Analysis required with Management Involvement

Analysis by relevant department e.g. discipline, offshore operations

No analysis required - Manage via normal Quality Procedures

® Shell Global Solutions International 2001 Confidential

® Shell Global Solutions International 2001 Confidential

OVERVIEW PROBLEM ANALYSIS

In this Section Problem Analysis is essential to the success of problem elimination.

STEP 3: PROBLEM IDENTIFICATION

STEP 4: PROBLEM DESCRIPTION

STEP 3: PROBLEM IDENTIFICATION

Process (how?) The Problem Identification process sub-steps are as follows:

Tips for Success 1. Stick to the facts in the Incident Report.