Key Elements for Effective Root Cause Analysis & Problem Solving Presented by: Cathy Fisher Quality Improvement Strategies
Jan 11, 2016
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 StatementA 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 Categoriesand 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
TroubleshootingRecognize
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 Team2. Operational Problem Definition3. Containment & Interim Actions, (if
needed)4. Root Cause Analysis, (process &
system)5. Plan & Implement Solutions6. Results of Solutions7. Verification, (including independent)8. Closure & Congratulate the Team
Problem Type ConsiderationsJust 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 fire-fighting is typically not known ahead of time
• Therefore, chaos is introduced into the process
• A very high-risk approach to problem solving!
Problem Type ConsiderationsProblem
TypeProcess of
OriginMethod Considera-
tions
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 3-5 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
Process steps(Methods)
Input
(Materials)
Actual Output
(Desired outcome:targets, goals, specs)
Equipment(selection,
Maintenance, etc.)
People(training, skills)
Environment(space, layout, etc.)
Evaluation(plan, gages, etc.)
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
System Processes = Policies, Objectives & Practices (how an organization does business)
Planning Processes apply System to fulfill customer requirements
Producing Processes to accomplish Plans
Products/Services = output of producing Processes
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.
Select Process tomap
Identify output ofprocess
Identify whoreceives output andtheir requirements
Identify inputsneeded for processand who supplies
these
Identify last step ofprocess which
creates that output
Identify firstprocess step and
trigger input
Brainstorm processsteps which occurbetween first and
last identifiedprocess steps
Combinebrainstormed
process steps forduplication/similar
ideas
Clarify any processstep ideas which
are unclear
Sequence processsteps between firstand last process
step to reflectcurrent process
flow
Review flowchartfor correct structure
(use 8 pointchecklist)
Review processmap with process
owners foraccuracy
Revise processmap based onfeedback from
process owners
Analyze processmap to identifyimprovementopportunities
Assess feasibility ofand establish goals
for potentialimprovements
Establish plan forimplementingimprovements
Update processmap to reflectimprovements
Measure impact ofimplementedimprovements
11/1/2002Prepared by: C. Fisher
Process Mapping Process
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 Concentration
diagram Refer to
problem condition
When? First seen Refer to
timeline Seen before? Days, shifts,
time
Who? Identified
problem Interview
Involved in related processes
Interview Refer to process flow
Customers How Quantity Containment
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
System Root Cause = management systempolicy/practice contributing to Actual Root Cause
Actual Root Cause = previous process factorscontributing to Process Root Cause, (planning)
Direct Process Cause = at Process of Origin
Defect/Detection Cause = Product level
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 CauseProcess 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
4/8/2007Disciplined Problem
Solving
ProcessRoot Cause Analysis Identify process
from which problem originated
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
Does potential cause directly
lead to problem condition?
Select other potential causes
Can cause be controlled or eliminated?
Identify possible actions to monitor
process for problem condition
Identify possible actions for either
controlling or eliminating cause
No
Yes
No
Yes
Identify management
policies related to process from
which problem originated4/8/2007
Disciplined Problem Solving
SystemRoot Cause Analysis
Review existing policies for existing
controls
Do current policies define controls to
prevent the cause of the problem?
Identify possible management
policy controls to address cause
Investigate if these controls are in
place
Identify other processes affected by these policies
Controls working?
Identify how these controls and/or policies can be
changed
Analyze why controls are not working at the process where
problem originated
No
Yes
No
Yes
Root Cause Analysis LevelsLevel(Deep)
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
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
Process Condition Control Status Capability Observations Actions
Other Opportunities:
Control Barrier Analysis Worksheet
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
Gap:
Material Man
Method MachineMother Nature
PROCESS:
Fishbone Diagram
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
Process of Origin: Potential Causes
Related to
process?
Feasible based on
operational definition?
Priority to
confirm
Method of confirmation
Results of confirmation
Confirmed causes to investigate via 5 Why Analysis:
Direct Process Root Cause Investigation Plan & Results
Process of Origin:
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)
Steps Who Required Actions Component Tools Remarks/Questions
Task Analysis Worksheet
Change Factor Difference/Change Effect Questions to AnswerWhat (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)
Change Analysis Worksheet
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)
Confirmed Eliminate Control Detect Gap
Defect: Direct: Actual: System:
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 B C D E n* 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.
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
Brainstorm possible solutions for each confirmed
root cause
Establish solution selection criteria
Evaluate possible solutions vs.
solution criteria
Develop action plan to implement selected solutions
Evaluate solution risks and impact
on other processes
Develop contingency plan
for solutions
Establish solution effectiveness
measures
Trial plan for solution
implementation
Evaluate trial plan results
Revise solution implementation
plan as necessary
Permanent solution
implementation
Evaluate results of permanent
solution
Remove interim actions
Team verification of solution vs.
goals
Independent verification of
problem solving effort
Finalize problem solving report,
lessons learned
Team celebration and disbanding of problem solving
team
4/8/2007
Plan, Implement & Verify Solutions
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 RoleSystem
• 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: Question Score Evidence/Observations
1 Is problem solving viewed as a value-added process in your organization?
2 Are problem solving behaviors/expectations defined and communicated?
3 Are resources, (e.g. time), allocated specifically in support of problem solving?
4 Is problem solving used throughout the organization in all areas and at all levels?
5 Are the top 3-5 problem solving efforts known by all employees throughout the organization?
For Further Information, you are welcome to contact
Cathy Fisher
Quality Improvement Strategies
(704) 575-4496