Transcript Root Cause Analysis: Eliminate Problems for Lasting

Key Elements for Effective
Root Cause Analysis &
Problem Solving
Presented by:
Cathy Fisher
Quality Improvement Strategies
What we will discuss. . .
•
•
•
•
•
•
•
•
•
•
What are problems
How problems are communicated: CREI statement
Types of problems and problem solving methods
Process View of problems
Isolating problems to their process of origin; establishing
context for Root Cause Analysis
Levels of Root Cause investigation
Data collection/analysis tools to apply at each level of
Root Cause investigation
Confirming root causes before applying solutions
Three possible solutions to each root cause
Getting the most out of Root Cause Analysis
investigations
Visual Definition of Problem
• Gap between current
condition, (what is),
and the desired
performance level,
(what must be, should
be or could be)
• This gap can exist in a
process, product or
system
• A problem can only be
considered to be valid if
“what should be” is
specified
Where do “gaps” arise?
• Customer complaint
• Nonconforming output
of a process
• Out of control process
• Management systems
not being followed
• Safety incidents
• Environmental
“releases”
• Goals not being
achieved
• Can be actual,
potential or generated
Communication of Problems
CREI Problem Statement
A tool for communicating the gap:
• Concern: what is wrong; statement of
nonconformity
• Requirement: what should be;
documented requirement or reference to
• Evidence: data demonstrating that
something is wrong; objective evidence
observed that supports statement of
nonconformity
• (Impact): how significant is the problem
from a performance and/or cost standpoint
Concern
• What is wrong?
• What is different than
what should be?
• May be recognized as a
symptom, (effect), or as a
failure condition, (failure
mode)
• Define in terms of
requirement, (language of
organization)
Requirement
• What should be
• Must be defined and valid
• Can be found in
procedures, policies,
drawings, specifications,
etc.
• #1 reason problems are
not effectively solved is
that Requirement is not
clearly known or defined
• Reference where
Requirement can be
found
• State as defined in
Requirement document
Evidence
• Demonstrates
requirement is not being
fulfilled
• Data initially gathered
associated with problem
• Objective evidence
collected while auditing
process or system
• Must be verifiable
• Can be tangible, a
statement of admission
or observed
Impact
•
•
•
•
•
•
•
•
How big is the problem?
How much does it cost?
Is the customer affected?
Is it affecting fulfillment of
organizational goals?
Refer to effect and severity
ranking on FMEA for
performance impact
Also consider cost impact
In the case of auditing findings:
typically, auditors do not cite
Impact as this could be viewed
as subjective
Impact should be determined
by auditee upon their review of
the audit finding
Utilizing CREI Format
• Incorporate these fields on problem solving and
nonconformance report formats to prompt
complete recording of information re: problems
• May require some investigation to identify
necessary information for completing CREI
statement, especially location and actual
statement of “Requirement”
• Critical success factor to effective problem
solving is consistent and complete
communication of problem condition
Problem Categories
and Problem Solving Approaches
Types of Problems
• Simple, cause
known; “Just do it”
issues
• Complex, cause
unknown; need to
dig deeper issues
• Sometimes the
financial impact of a
problem dictates
how it will be
classified
“Just Do It” Issues
• Typically isolated, sporadic incidents
• Are easily fixed; apparent cause tends to be
known
• Often recognized during process planning
and reflected in PFMEA
• Addressed through troubleshooting,
(diagnosis and remedy) and reaction plans
on control plans, (control of nonconformity)
• Can be fixed by process owner; addressed
at process level
• Occurrence should be monitored ongoing
for cost and impact
Troubleshooting
Recognize
problem condition
Communicate
problem condition
to process owner
Diagnose problem
condition
Decide on
appropriate action
Implement remedy
Observe results of
remedy
Record condition
and remedy
Periodically review
records of
conditions for
trends
“Dig Deeper” Issues
•
•
•
•
•
•
•
•
•
•
Sometimes referred to as Chronic
Long-term and/or complex issues
Cause is not readily apparent, unknown
Require in-depth investigation to identify root cause
Addressed through root cause analysis,
disciplined problem solving and improvement
process
Source of problem typically unknown
Cross-functional participation needed to solve
Effective resolution requires both process and system
solution consideration
Require management intervention via resource
commitment
When available data re: problem is limited, may be
handled as “Just do it” based on impact and/or risk
Steps in Disciplined Problem Solving
1. Establish Team
2. Operational Problem Definition
3. Containment & Interim Actions, (if
needed)
4. Root Cause Analysis, (process &
system)
5. Plan & Implement Solutions
6. Results of Solutions
7. Verification, (including independent)
8. Closure & Congratulate the Team
Problem Type Considerations
Just Do It
• Reflects product or
process controls
established when
planning the process
• Management decision to
“live with” such conditions
based on acceptable level
of risk
• Should be routinely
evaluated for cost and
impact
• Can only be eliminated by
applying disciplined
problem solving to
understand true root
cause in order to improve
process
Dig Deeper
• Unanticipated
conditions which occur
• May also be anticipated
issues for which actual
level of risk is now
determined to be
unacceptable
• Require concentrated
investigation to
understand source of
problem and process
factors leading to
problem condition to
allow appropriate
solutions
A Note about Fire-fighting!
• Fire-fighting is essentially
un-prescribed actions taken
on a process without
understanding the relation of
causal factors and process
output
• Fire-fighting is dangerous as
these actions tend not to be
specifically focused to a
particular cause
• The resulting impact of firefighting is typically not known
ahead of time
• Therefore, chaos is
introduced into the process
• A very high-risk approach to
problem solving!
Problem Type Considerations
Problem
Type
Process of
Origin
Method
Considerations
Just do it
Known
Troubleshooting;
rework
Seen before; can
live with impact
when problem
recurs
Dig Deeper
Unknown
Root cause
analysis
Data-driven
investigation to
determine actual
factors causing
problem condition
Unknown
Fire-fighting
Taking action
possibly on wrong
process; not using
data to confirm
root cause
Prioritize Problems
• Most organizations should
only be actively working on 35 disciplined problem
solving efforts, (Dig Deeper
issues), at a time to balance
the use of resources and get
the most effective solutions;
(no one person should be
working on more than 2 Dig
Deeper teams at any given
time)
• Impact portion of CREI
statement facilitates
prioritization of problems for
allocation of problem solving
resources
• Management is responsible
for establishing the priority
Process View of Problems
The Secret to Solving
Problems
• The source of every problem is a process: typically
the gap is found in the output of the process
• The cause of every problem is one or more process
factors not behaving as they should
• Understanding the relationship between process
factors and process outputs is important to effective
problem solving
• Data about the process and the problem is required to
gain enough understanding to effectively solve any
problem
• The result of any problem solving effort is increased
knowledge about processes and their outputs
Components of Process
Environment
(space, layout, etc.)
Input
(Materials)
Evaluation
(plan, gages, etc.)
Process steps
(Methods)
Equipment
(selection,
Maintenance, etc.)
Actual Output
(Desired outcome:
targets, goals, specs)
People
(training, skills)
Management Policies & Practices
What are the Process Factors?
Processes are mainly
influenced by:
• Man
• Material
• Machine
• Methods
• Mother Nature,
(environment)
Other factors which
influence processes
include:
• Measurement
• Management System,
(policies including
SOPs, targets,
operational decisions)
• Money
• Other?
Process View
Products/Services = output of producing Processes
Producing Processes to accomplish Plans
Planning Processes apply System
to fulfill customer requirements
System Processes = Policies, Objectives & Practices
(how an organization does business)
Main Functions of Problem Solving
• Define Gap between “what
is” and “what should be”
• Identify process of origin
from which gap is
originating
• Study the process of origin
to determine which process
factor(s) are causing the
gap
• Analyze the relationship
between process causal
factors and system factors
to identify root cause
Getting to the Process of Origin
• Where was the problem found?
• Where is the first process the problem
condition could occur?
• Go to these and any processes in between
to collect data recognizing where the
problem is actually first observed; this is
the process of origin!
• Use a process flow diagram to make this
investigation visual.
Process Mapping Process
Prepared by: C. Fisher
11/1/2002
Select Process to
map
Identify output of
process
Identify last step of
process which
creates that output
Identify who
receives output and
their requirements
Identify inputs
needed for process
and who supplies
these
Sequence process
steps between first
and last process
step to reflect
current process
flow
Clarify any process
step ideas which
are unclear
Combine
brainstormed
process steps for
duplication/similar
ideas
Brainstorm process
steps which occur
between first and
last identified
process steps
Identify first
process step and
trigger input
Review flowchart
for correct structure
(use 8 point
checklist)
Review process
map with process
owners for
accuracy
Revise process
map based on
feedback from
process owners
Analyze process
map to identify
improvement
opportunities
Assess feasibility of
and establish goals
for potential
improvements
Measure impact of
implemented
improvements
Update process
map to reflect
improvements
Establish plan for
implementing
improvements
Is/Is Not Analysis
• Also known as Stratification Analysis
• Provides further detail about the problem so a
complete operational definition of the problem
can be formulated.
• Used at this stage as well as in applying
interim/containment actions and
implementing/verifying permanent actions.
• “Splitting the dictionary” or “20 questions to
the answer” demonstrates this idea of
problem convergence
Use Data to determine
• What is the problem? – define the problem condition such
that anyone could recognize it; basis for data collection
about the problem
• Where is the problem occurring? – which processes,
customers; also, where on the output is the problem
condition observed?
• Who knows about the problem? – who initially identified
the problem? Who else has seen this problem? Who is
involved in the process steps reflected in the process
flow?
• When did the problem begin? – timeline associated with
when the problem was seen; can be applied even for
ongoing problems
• How big is the problem? – how much output is affected?
• Narrows the problem focus to isolate the problem to its
process of origin
• Data is collected to demonstrate answers to these
questions
Is/Is Not Analysis Worksheet
Focus
Aspect
Data to
Collect
Where to
Collect
How to
Collect
Results –
IS
Results –
IS NOT
Comments
What?
Problem
condition
Refer to
requirement
Where?
Geographically
See process
flow
Where?
On output
When?
First seen
Concentration
diagram
Refer to
problem
condition
Refer to
timeline
Seen before?
Days, shifts,
time
Who?
How
Identified
problem
Involved in
related
processes
Customers
Interview
Quantity
Containment
Interview
Refer to
process flow
Applying Is/Is Not Analysis
• Clarify aspect – what question needs to be answered to
obtain a better understanding of the problem
• Identify what data to collect that would assist in
answering the question
• Determine where that data can be obtained
• Decide how to go about collecting the data; what
tools/methods to apply
• Go collect the data
• Review and analyze the data to draw a conclusion re:
questions being posed
• This is an important step in Root Cause Analysis as the
results of this investigation provide a context for the root
cause investigation
• By conducting Is/Is Not Analysis, it is also possible to
determine if further investigation can take place at this
time
Components of Problem’s
Operational Definition
• Basis for root cause investigation
• More detailed version of CREI statement based
on what was learned from Is/Is Not
• Indicate process from which problem
originated/generated
• Indicate direction of problem related to
requirement
• Define extent of problem
• Possibly isolates problem to a certain timeframe
• Include refined information re: impact
• Problem statement must be clear, concise and
understandable by anyone
A Root Cause is. . .
A process factor which directly defines
the reason for the problem when it is
present and is having an influence on
the process and its output.
4 Levels of Root Cause
Defect/Detection Cause = Product level
Direct Process Cause = at Process of Origin
Actual Root Cause = previous process factors
contributing to Process Root Cause, (planning)
System Root Cause = management system
policy/practice contributing to Actual Root Cause
Dig! How Deep?
• Management decides
on depth of root
cause investigation
through the
establishment of
SMART goals for
each problem solving
effort.
Problem Solving Goals
• Define problem’s
boundaries/depth of
solutions
• Identify right people to
solve problem
• Establish measures of
end results
• Develop plan of how to
accomplish the goal
• Tie problem solving
goals to organizational
objectives/targets
• Provided to team by
Management
Effective Problem Solving is
based on
SMART Goals:
• Specific
• Measurable
• Agreed upon by team as
attainable
• Relevant to organization
and results-oriented
• Timing defined
Root Cause Analysis
• Systematic investigation
of a process to identify
the root cause of the
gap, and take corrective
action to eliminate the
gap and keep it from
occurring again in the
future
• A structured investigation
that aims to identify the
true cause of a problem,
and the actions
necessary to eliminate it.
Process Cause vs. System Cause
Process Cause
• What factor of the
process of origin is
triggering the undesirable
output
• What other processes
and their factors are
causing the trigger?
• Relates product output,
(symptom), to process
parameters, (causes)
System Cause
• Addresses how the
management system
allowed the process to
become out of control
• Relates process factor
causes to “weaknesses”
in management systems
policies/practices
Process
Root Cause Analysis
Disciplined Problem
Solving
Identify process
from which
problem originated
4/8/2007
Review data from
operational
definition,
containment and
interim action
Identify potential
causes
contributing to the
problem
Develop plan to
test if potential
cause actually
leads to problem
Conduct test and
collect data
Analyze data from
test
Select other
potential causes
No
Does potential
cause directly
lead to problem
condition?
Yes
Identify possible
actions to monitor
process for
problem condition
No
Can cause be
controlled or
eliminated?
Yes
Identify possible
actions for either
controlling or
eliminating cause
System
Root Cause Analysis
Disciplined Problem
Solving
Identify
management
policies related to
process from
which problem
originated
4/8/2007
Review existing
policies for existing
controls
Identify possible
management
policy controls to
address cause
No
Do current policies
define controls to
prevent the cause of
the problem?
Yes
Investigate if these
controls are in
place
Identify how these
controls and/or
policies can be
changed
No
Controls
working?
Yes
Analyze why
controls are not
working at the
process where
problem originated
Identify other
processes affected
by these policies
Root Cause Analysis Levels
Root Cause
Consideration
Tools
Other
(Wide)
Product
Defect/Detection
cause
Condition of
controls to
detect problem
Control
Barrier
Analysis
What other
products have
similar
controls?
Process
Direct process
cause, (trigger at
process of origin
Factors at
process of
origin triggering
problem, (5Ms)
Fishbone,
(cause &
effect)
What
processes
have similar
trigger cause?
Plan
Actual root cause,
(led to trigger
cause)
Linkage to
planning
processes that
trigger cause
5 Why with
Hypothesis
testing
What other
processes
affected?
System
“weakness” in
mgt. policies or
practices
Linkage of mgt.
system to
actual cause
System
Cause
Analysis
Level
(Deep)
Other affected
mgt. policies
Control Barrier Analysis
(Defect/Detection Root Cause)
• How did the problem
escape the process
and/or organization?
• Was the problem
anticipated in advance?
• Were controls defined
to recognize and
contain the problem?
• At which process are
the planned controls
applied?
• Were the planned
controls in place?
• Were the planned
controls working?
• What is the capability
of these controls?
• Assists in identifying
appropriate interim
actions as well as
identifying the
defect/detection root
cause
Control Barrier Analysis Worksheet
Process
Condition
Other Opportunities:
Control
Status Capability
Observations
Actions
Results of Control Barrier Analysis
• May recognize missing controls or controls not working as
planned
• Interim actions represent solutions to addressing these
concerns but should not be accepted as the permanent
solution
• When the results of this analysis uncover additional
problems, refer these to the team champion for direction
on addressing
• Team’s main focus at this point is to implement some type
of control to protect downstream processes from
continuing to experience the problem
• Solutions based on this level of “root cause investigation”
mainly are reactive in nature; they only improve our ability
to detect the problem condition but don’t typically do
anything about addressing the root cause!
Direct Process Cause
• Relates one or more factors of the affected
process, (process of origin), not “behaving” as
required to obtain the desired output result at
that process
• Use Cause & Effect diagram, (fishbone
technique)
• Direct process causes, (trigger causes), are the
starting point for identifying root cause
• Some action may be required to address the
direct process/trigger cause but actions should
not be taken until actual root cause is known
Cause & Effect Diagram
• Apply to problem’s
process of origin
• Gap is head of fish
• Major cause categories
– 5M’s
• Potential causes
brainstormed are
process factors existing
at the problem’s
process of origin
• Define potential causes
specifically
• When confirmed, these
will be known as direct
process/trigger causes
Fishbone Diagram
PROCESS:
Material
Man
Gap:
Mother
Nature
Method
Machine
Fishbone Process
• Involve personnel from process of origin in
brainstorming of potential causes at the process of
origin triggering the problem
• Develop a sketch/list of the process factors, (man,
material, machines, methods, mother nature), related
to the process of origin
• After brainstorming, review each identified cause to
establish:
– If the cause is actually a factor at the process of origin
– If the cause makes sense based on the operational definition
of the problem
• Prioritize remaining causes as to their possible
contribution to the problem condition
• Develop hypothesis test to evaluate each potential
cause at the process of origin
Direct Process Root Cause
Investigation Plan & Results
Process of Origin:
Process of Origin:
Potential
Causes
Related
to
process?
Feasible
based on
operational
definition?
Priority
to
confirm
Method of
confirmation
Confirmed causes to investigate via 5 Why Analysis:
Results of confirmation
Problem Understanding Tools
(especially useful in identifying system causes)
• Task Analysis – reviews process in detail;
helpful for operator dependent process
• Change Analysis – identifies differences;
extension of Is/Is Not analysis; expands on
application of timeline
• Both these tools must be applied with a
location context, (process of origin)
Task Analysis Worksheet
Steps
Who
Required Actions
Component
Tools
Remarks/Questions
Change Analysis Worksheet
Change Factor
What (conditions,
activity, equipment)
When (occurrence,
status, schedule)
Where (physical
location,
environmental
conditions, steps of
procedure)
How (work practice,
omission, extraneous
action, out of
sequence, poor
procedure)
Who (personnel
involved, supervision)
Difference/Change
Effect
Questions to Answer
Actual Root Cause
• Explains why trigger cause/condition exists at
the process of origin of the problem
• Typically found in previous “planning” processes
• Many problems have multiple causes
• Usually only one over-riding cause that when
addressed, can significantly reduce the
problems impact on the organization
• Very complex problems may have interacting
causes but these are typically viewed as isolated
problems that only repeat infrequently, (often
managed as Just Do It), until resources allow
necessary time to discover interaction through
data collection, analysis and experimentation
5 Why Analysis
• Ask “Why does this
happen?” for each identified
process cause from Cause &
Effect diagram
• Differentiates between
process, (direct) cause and
underlying root cause
• Each level of causes
identified in 5 Why analysis
must also be confirmed via
testing in order to verify root
cause
• Deeper levels of 5 Why
Analysis which get into
Planning processes will
require interview-type data
collection
5 Why Analysis Worksheet
Process
of Origin
Cause
Plan/Data
to confirm
Results
2nd
level
Cause
Plan/Data
to confirm
Results
3rd
level
Cause
Plan/Data
to confirm
Results
4th
level
Cause
Plan/data
to confirm
Test Potential Root Causes
• Validating cause
“guesses” by
collecting and
analyzing data
• Test under controlled
conditions
• Turn the problem on
and off by
manipulating the
suspected cause
Hypothesis Testing
• Design hypothesis and select methods for testing
hypothesis - state how potential cause could result
in described problem; decide what data to collect that
would prove potential cause; establish acceptable
risk of decision outcome; determine sample size;
develop action plan for study
• Prepare to test hypothesis - organize and prepare
materials required to conduct study; collect data
during study
• Analyze results of test - analyze data using
appropriate statistical tools, (t, F, Chi-squared tests)
• Interpret results - conclusions from study; does data
establish potential cause as reason for problem?
Root Cause Analysis Plan
• Identify causes to be investigated
• What data supports each cause?
• Can cause be introduced and removed to
confirm presence/absence of problem?
• What tests will be performed to confirm root
cause?
• What is the statistical confidence of these
tests? (i.e. how much data is needed?)
• Results of tests recorded and analyzed with
conclusions drawn
System Causes
• What in the system allowed this problem/cause
to occur
• Identifies why the process root causes occurred
based on current management policies/practices
• Often not readily measurable
• Data obtained through interview
• By identifying system causes, systemic
improvement can be made in order to prevent
recurrence of problem in other similar processes
• Typically addressed once process root causes of
problem are known and confirmed
System Cause Analysis Worksheet
Operational Definition:
Process of origin cause:
Process root cause:
Which management system process is the process root cause related
to?
Who is responsible for this management system process?
What documentation/policies are available describing actions and
controls for this management system process?
Does this documentation/policy recognize the possibility for this
problem to occur?
Are there any current management system controls in place to
prevent or detect this problem?
Has this management system process been associated with previous
problems?
What other processes within the organization are driven by this
management system process?
Possible Management System Level Solutions: 1) Create new policy
2) Change existing policy 3) Reinforce/re-apply current policy
Problem Solutions
• There are always at least
3 possible solutions
related to each level of
cause
• Therefore, at least 12
possible solutions could
be identified for a
problem investigation if all
levels of cause are
investigated!
• Management provides
solution selection criteria
as basis for evaluating
possible solutions
Possible Solutions Matrix
Root
Cause(s)
Defect:
Direct:
Actual:
System:
Confirmed
Eliminate
Control
Detect Gap
3 Possible Solutions
• Eliminate root cause – preventive control; often
referred to as error-proofing; eliminates causal factor
leading to problem condition
• Control root cause – process detective control;
implement actions to monitor cause condition so
action can be taken on process factor before problem
occurs
• “Do nothing” – reactive control; continue
monitoring for problem condition; defect detection
solution; may be required when root cause can’t be
eliminated or controlled economically or technically;
this solution may include accepting interim action as
permanent solution
Solution Selection
• Allow brainstorming of possible solutions at all
levels of confirmed causes and the 3 possible
categories of solutions
• Then apply solution selection criteria provided
by management to evaluate each possible
solution as well as refine the brainstormed ideas
• Have data available re: actual costs associated
with problem, (initial impact, revised impact
based on data collection/analysis, anticipated
future impact if no action is taken)
CRITERIA MATRIX
SOLUTIONS
A
CRITERIA
1
MUSTS
2
3
4
n*
1
WANTS
2
3
4
n*
RATING TOTALS
* reflects any number of variables that are appropriate to include in the analysis.
B
C
D
E
n*
Implementing Solutions
• Actions to eliminate
and control causes
require change
• Change management
tools should be
applied when
implementing
solutions
Change Management
Tools
• FMEA
• Risk assessment
• Resource planning
• Contingency planning
• Training
• Evaluation
• Verification
Plan, Implement
& Verify Solutions
Brainstorm
possible solutions
for each confirmed
root cause
Permanent
solution
implementation
4/8/2007
Establish solution
selection criteria
Evaluate results of
permanent
solution
Evaluate possible
solutions vs.
solution criteria
Remove interim
actions
Develop action
plan to implement
selected solutions
Team verification
of solution vs.
goals
Evaluate solution
risks and impact
on other
processes
Independent
verification of
problem solving
effort
Develop
contingency plan
for solutions
Finalize problem
solving report,
lessons learned
Establish solution
effectiveness
measures
Team celebration
and disbanding of
problem solving
team
Trial plan for
solution
implementation
Evaluate trial plan
results
Revise solution
implementation
plan as necessary
Other Opportunities
• Identified typically while collecting data for Is/Is Not
Analysis, Root Cause investigation/confirmation, solution
evaluation
• Record these other problems/opportunities
• Share these problems/opportunities with team champion
to get direction on how to address: (change scope of
current problem solving effort to include; management
assigns another team to address)
• Don’t allow these other opportunities to distract from the
focus of the problem solving effort
• These Other Opportunities become the “Bonus” of an
effective problem solving effort
A Key Outcome of Every Problem
Solving/Root Cause Investigation. . .
Expansion of Knowledge
Failure Modes & Effects Analysis
(FMEA) – A Tool for Cataloging Problems
Process
Function
Requirements
Potential
Failure
Modes
Potential
Failure
Effects
Potential
Failure
Causes
Current
Product &
Process
Controls
Process of
origin
Technical
definition of
problem
Symptom
Process
factors = root
causes
Interim
actions
Management’s Role
•
•
•
•
•
System
Establish problem solving
culture
Provide problem solving
process
Ensure training of all
personnel in problem
solving process and related
tools
Prioritize/categorize
problems based on
magnitude/risk
Audit/review effectiveness
of problem solving system
•
•
•
•
•
•
Each Problem
Appoint Team Champion
Define SMART goals for
problem solving effort
Provide resources and time
to support problem solving
team
Establish solution selection
criteria
Authorize Team Plan as
contract for problem solving
effort
Periodically review progress
of problem solving teams
Problem Solving Culture
• Problem solving is a value-added
process
• Problem solving supports improvement
of every aspect of the business
• Time should be dedicated to problem
solving on a daily basis
• Everyone in the organization is involved
in problem solving
• Use problem solving survey to measure
effectiveness of problem solving system
Comments on Effective Problem Solving Culture
“Culture is the result of behavioral change over time.”
Many organizations struggle with effectively implementing problem solving
for several reasons:
1. problem solving is not viewed as a value-adding process
2. process ownership for problem solving is not defined beyond
someone to manage the administrative aspects, (i.e. tracking of
status, accounting for open issues, etc.)
3. time is not specifically nor continually allocated for problem solving;
instead, it is an activity that is done “when required”; in fact, problem
solving should be an ongoing process if an organization is committed
to continual improvement
4. expectations of the outcomes from problem solving efforts are not
clearly defined nor connected with organizational goals, (quality
objectives); in some cases, when expectations are defined, these
may be unrealistic
5. more value is placed on “tribal knowledge” rather than data driven
analysis and results, (ISO 9001:2000 quality management principle
“fact based approach to decision-making”)
6. ownership of problems are parsed out to individuals instead of
viewing each problem solving effort as an opportunity to increase
organizational knowledge and therefore involving the entire
organization in the problem solving effort with the core team being
the drivers of the effort
To effectively solve problems, organizations must recognize problem
solving as a valid process contributing significant value in terms of
continual improvement and increase in knowledge. When ISO 9001:2000
specifies “determining and managing the work environment”, this includes
establishing a culture which supports the success of the organization,
which is clearly a management responsibility. Culture by default is NOT a
“managed work environment”.
One means of understanding current problem solving culture and therefore
closing the gap in the desired culture, is the application of the AIAG
Effective Problem Solving Process Survey found in CQI-10. The
management team can use this tool to assess the current state of problem
Quality Improvement Strategies
Problem Solving Survey – Short Version
This tool can be used to evaluate your organization’s problem solving system. The survey can be
administered to any employee to gain an overall understanding of perceptions regarding this key
process within your business. Continual improvement of the problem solving process can be measured
based on conglomerate results of this survey, (can be re-administered repeatedly to evaluate progress).
Each response scored 3 or 5 should have related evidence indicated to support.
Scoring: 1 = no evidence currently exists to demonstrate this
3 = evidence exists to demonstrate this, but improvement potential
exists
5 = this aspect of our problem solving system is “world class”, (i.e.
would want others to benchmark ours)
NA = not applicable; unable to respond
Culture:
1
2
3
4
5
Question
Is problem solving viewed as a value-added
process in your organization?
Are problem solving behaviors/expectations
defined and communicated?
Are resources, (e.g. time), allocated
specifically in support of problem solving?
Is problem solving used throughout the
organization in all areas and at all levels?
Are the top 3-5 problem solving efforts known
by all employees throughout the organization?
Score
Evidence/Observations
For Further Information, you
are welcome to contact
Cathy Fisher
Quality Improvement Strategies
(704) 575-4496
[email protected]