Documente Academic
Documente Profesional
Documente Cultură
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.
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.
Section Page
INTRODUCTION 0
INCIDENT CAPTURE 3
PROBLEM ANALYSIS 9
ROOT CAUSE ANALYSIS 21
SOLUTION DEVELOPMENT 35
GENERAL REFERENCE 45
INTRODUCTION
OK, we all
know what operators
no screwed up
the root
procedures again
cause is, you
the cheap poor
right? parts
contractor communications
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.
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
Enables more
Reduces reactive work effective planning
Incident
Capture
Phase I
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.
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.
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.
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.
TOOLS: OVERVIEW
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.
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
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.
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.
3. SOLUTIONS
CAUSES CORRECTIVE ACTIONS NAME DUE DATE
CONTACT:
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)
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
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
Problem
Analysis
Phase II
Process Steps The process steps included in the Problem Analysis phase of Problem
Solving are shown below and described in the pages that follow.
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.
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
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.
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.
TOOLS: OVERVIEW
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
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.
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).
Why To ensure that the process is fact based versus opinion, gut feel or
best guess..
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.
Problem
(primary effect)
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.
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.
Illustration Events
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.
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.
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.
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.
Illustration EFFECT
(impact)
Greatest impact
What A Pareto diagram is a special form of bar graph used for ranking or
prioritising data.
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.
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.
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:
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.
(what) Identity
(where) Location
(when) Timing
(how much) Extent
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.
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?
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.
Illustration
IT IT IT is
Definitely Might NOT...
is... be...
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.
ROOT CAUSE
ANALYSIS
Phase III
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.
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.”
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 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.
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:
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.
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.
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:
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:
Process (how?) The process sub-steps of Cause Verification are provided below.
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.
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.
NOTE: The more you use the different tools the more familiar they
become. Selecting the best tool gets easier with practice.
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.
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.
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
Illustration Problem
WHY Problem ?
Because 1
WHY Because 1 ?
Because 2
WHY Because 2 ? CAUSE
Because 3
WHY Because 3 ?
Because 4
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.
Illustration
PROBLEM
and
Cause 1
or
Cause 2 Cause 3
No facts
to support Cause 4
Why "A picture paints 1000 words" … at one glance shows the
interrelationship and complexity of cause.
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.
Illustration
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.
Tips for Success 1. Using this technique to ask questions in interviews may be helpful.
2. Remember, not all differences or changes are causes.
Illustration
“EFFECT” “CAUSES”
Human /
Process Systems
Proximate
causes
Equipment Procedures
& materials
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.
What These Human / Systems Interface Checklists are based on the belief
that: humans do not intentionally commit stupid or irrational acts.
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.
Solution
Development
Phase IV
In this Section The final phase in the Problem Solving Process is Solution
Development. The task of Solution Development is to determine:
Process Steps The process steps included in Solution Development are listed below
and are described in the pages that follow.
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)
example
Root Cause: Debris in Instrument Air plugged the positioner of the trip
valve which in turn shutdown the unit.
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.
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!)
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.
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
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.
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.
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.
NOTE: The more you use the different tools the more familiar they
become.
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.
Illustration
Rules Methods Hardware /
Req’ments Procedures Facilities:
Expectations Action steps
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.
Illustration Likelihood
High
Safe to Implement ?
Medium
Yes, with or without mitigation
Low
OK, with mitigation
Consequence
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.
General
Reference
In this Section The following reference topics are provided in this section.
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.
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 ........
GLOSSARY OF TERMS
Convergent Tending to move toward one point, down one path. Closed
focus.
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.
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.
ABBREVIATIONS
CA Corrective Action
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.
“Problem Solving & Decision Making (A logical approach to common sense )", TJ Hansen
Company, Dallas, Texas, 1982.
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
Distribution
Report number : OP.01.30472
Subtitle : Rev. 3
Sponsor/customer :
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
Additional : Any additional distribution (outside the above mentioned distribution list) can only
distribution be effected with special permission of owner/custodian (see above).