8D The 8 Disciplines Problem Solving Methodology

The 8-Disciplines
Problem Solving
Methodology
Michael Carter, Ph.D.

Contents
Introduction........................................................................................................... 1
Problem Solving Methods...................................................................................... 6
8D Overview .......................................................................................................... 8
D0 – Gather Preliminary Data .............................................................................. 10
D1 – Team Selection ............................................................................................ 13
D2 – Problem Definition....................................................................................... 16
D3 – Containment................................................................................................ 23
D4 – Identify Root Cause...................................................................................... 27
D5 – Identify Corrective Action ............................................................................ 42
D6 – Implement (and verify) ................................................................................ 44
D7 – Prevent Recurrence ..................................................................................... 48
D8 – Congratulate Team ...................................................................................... 53
Summary Report.................................................................................................. 54
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/8d-the-8-disciplines-problem-solving-methodology-1127

3
Before we begin, let’s look at all of the reasons why a structured methodology
should not be used in problem solving.
Here are a few:
“I don’t know any structured methods”
“they aren’t any better than ad hoc processes”
“that method was not invented here”
“they are too slow”
“I’m paid to solve problems . . . as I see fit”
“I had a bad experience using a structured approach”
“ad hoc allows for flexibility and creativity”
“experience is the only teacher”
“every problem is unique – no 2 alike”
“what we manufacture is unlike anything else and so those methods
don’t apply here”
Do these sound familiar? I’m convinced of the following . . .
Brains will consistently win over Brawn
Someone has suggested that it takes about 10,000 hours or 7 years to master a
given field. For some, that may seem like an eternity, for others, a challenge.
And part of the challenge is where to start on this journey? I advocate starting
with a structured problem solving methodology. Why? There are several
reasons.

6
Problem Solving Methods
There are numerous structured methods in use today. 8 Disciplines, GROW
(Goal, Reality, Obstacles/Opinions, Way Forward), How to Solve It, Kepner –
Tregoe, PDCA, Rapid Problem Resolution, DMAIC, DMADV, TRIZ (Theory of
Inventive Problem Solving), Lean and more.
GROW: Goal – the desired future state. Reality – this is the gap between
current state and future state. Obstacles – the challenges that must be
overcome to achieve the future state. Options – the activities that must be
accomplished to remove the obstacles. Way Forward - the actions that will be
required to implement the options.
How to Solve It: developed for solving math problems. The steps are:
understand the problem by reframing it in your own words, select a method
for solving it from a list of possibilities, execute the plan, reflect on the results.
Kepner-Tregoe: a well known and respected problem solving methodology
that consists of 4 steps: Appraisal - used to understand the situation, outline
challenges and select a path forward. Analysis – used to define the problem
and find its Root Cause. Decision – alternative solutions are identified and a
risk analysis is undertaken. Opportunity analysis - the best alternatives are
reviewed for negative consequences and then actions are proposed to
minimize.
PDCA: Plan – identify the problem and plan a solution. Do – test the solution.
Check – the effectiveness of the solution. Act – correct as necessary and
repeat the cycle.
Rapid Problem Resolution: primarily used in IT. Discover – gather
information about the problem. Investigate – create a diagnostic plan. Fix –
implement the fix.
DMAIC: Define - the problem. Measure - the magnitude of the problem.
Analyze – find the Root Cause. Improve – identify corrective action. Control –
control the process.

9
The steps of 8D:
D0 – Gather preliminary data
D1 – Select the problem solving team
D2 – Define the problem
D3 - Containment
D4 - Identifying Root Cause
D5 - Identify Corrective Action
D6 – Implement Corrective Action
D7 - Prevent Recurrence of the problem
D8 - Congratulate team
The detailed discussions to follow about each of the 8 Disciplines will refer to
the 6ixSigma.org 8D template located at 6ixsigma.org , called ‘8D.xlsx’.
A few notes about the 8D.xlsx template:
1. All fields in the 8D Report (the last tab in the Excel file) will be
automatically populated as you complete each discipline. The only item
that will need to be added manually to the report is a picture of the
failure.
2. There are several tabs in the workbook, with at least 1 tab dedicated to
each discipline.
3. The tab for Discipline 1 is D1, Discipline 2 is D2, etc.
4. When more than 1 tab is used for a given discipline, a D4-1, D4-2 . . .
format is used.
5. Each tab contains the instructions, templates and decision tools
appropriate for that discipline.

12
Product or Process Manager: usually the production manager or supervisor
responsible for the production of the part.
Value stream Manager: the person in the organization who is responsible for
the end to end delivery of the part to the customer. It could be a Director of
Operations.
Cost or Lost Sales: an estimate is fine and also important. This will be used in
the risk assessment.
The D0 Discipline is straight forward but often expedited. There will be
pressure from management and/or the customer to ‘fix the problem’;
intelligently resist the temptation to speed through this step. Once D0 is
complete, the information will be used to preliminarily assess who, what,
where . . . etc. and to make the decision to use 8D or not.
A leader is one who knows the way, goes the way,
and shows the way.
John C. Maxwell

15
QA: a representative from the quality organization who is familiar with Root
Cause Analysis and can ensure that the tools are used correctly and Root
Cause is verified.
Other: any other individual who the team may need. IT, HR, Customer or
Technical Service are common.
Be sure to identify the department each member represents.
Once the team has been formed, the team lead should put together a Team
Charter and complete a GRPI Assessment.
Team Charter:
The Team Charter is a simple but powerful tool to help get the team oriented
and in agreement on:
1. Project objective
2. The expected deliverables
3. Key milestones and estimated completion dates
4. The scope of the project. What is in scope and what is out of scope
5. The roles and responsibilities of each member
6. Meeting frequency
GRPI
The GRPI assesses each team members understanding of the team Goals,
individuals Roles & Responsibilities, the Process that will be used & the
Interpersonal relationships expected. It is usually done as a survey, where
each team member is asked to rank their knowledge of, or agreement with, a
series of statements. Based on the responses, the team lead is better equipped
to manage the team and address individual concerns about the task at hand.
Templates for both of these are located in 6ixSigma.org’s ‘Change
Management Tools.xlsx’

18
What: is the product that is affected. What products are not affected but
should be? This could be similar parts in the family, produced on similar
machines, use similar raw materials, are made with similar processes, etc.
What: is the defect? Describe it. For example, chipped heads were found on a
portion of a production lot of ¾ inch screws. What is not the defect, but by
association, should be the defect? Describe that as well. The balance of the
lot was not chipped – for example.
“What” identifies the event, condition or state of the problem
Where: does the problem occur? This could be “where in the factory does the
problem occur?” or “where in the field does the problem occur?”, or “where in
the heat treat furnace does the problem occur?”, or . . .
Similarly, where is it not occurring but could? “Bent components are coming
out of the heat treat furnace on Tuesdays and Fridays but not Mondays,
Wednesdays, Thursdays or Saturdays”, or . . .
Where: was the problem first observed? This could be “where in the factory
was the problem first observed?” or “where in the field”, or . . .
Where: else might the problem have occurred but didn’t? Are there like
products with equal probability of having the problem occur?
“Where” answers the question of location
When: was the problem first reported? Time is an important consideration of
Root Cause analysis so be diligent in finding the time of failure. Time can
point to a specific production shift, Lot number, machine, etc.
When: was the problem not reported? After Tuesday? After first shift? Etc.
When: was the problem last reported? This question helps isolate the time
frame within which the failure was occurring.

21
Other: information that may be relevant to isolating Root Cause should be
recorded here. What else is known that might be relevant? Can the problem
be isolated to a lot, batch, work order number, control number, product line or
family of parts?
Can the problem be replicated at will or on demand? It is not important that
this be possible now but it is important in D6.
Have trends been observed. Don’t over analyze at this point, simply answer
the question based on observations.
Scope: a key to defining a problem is to define the scope of the problem. What
is the start of the process or product [pro(cess/duct)] under investigation?
Define where the problem process starts. Everything preceding this will be
outside the scope of this 8D investigation. Define where the problem process
stops. Everything after this will be outside the scope of this 8D investigation.
All other information for ‘Scope’ is taken from the ‘Preliminary Data’.
Misc: here, record other relevant information, unanswered questions, facts to
verify, or anything else that may be pertinent to the 8D.
Problem Description: now, based on the above analysis, define the problem or
describe the opportunity to improve. Use the verb-noun format. Make sure it
is free of opinions (speculative interpretation of the facts), judgments
(assigning the problem to a person, department, etc.), assumptions (things
taken for granted), presumed causes (causes not supported by facts,
engineering judgment), solutions (leave that until later), blame or compound
problems.
Example:
Bad: customer is experiencing installation problems with the 1ER-509B3
ratchet which seems to be improperly forged and case hardened resulting in
material toughness and premature notch failure. Heat treat line 2 needs to be
audited again.

24
Occ: a value between 1 and 10. 1: low frequency, 10: high frequency
Det: a value between 1 and 10. 1: high detectability, 10: low detectability
Based on the problem definition, describe the failure. Using a measure of
subjectivity and available data, assess Sev, Occ & Det and enter these in the
template. Note the resultant RPN. Although it is not directly interpreted, the
higher the RPN, the higher the risk and the more “aggressive” or
“conservative” the containment.
In order to recommend the containment action, you have to:
1. Know where to look for defective product
2. Know how to find the defective product
3. Know how to stop the defective product
To accomplish this, the containment should be coordinated with Quality,
Production & the Customer. This will require a communication plan.
In a 2008 Survey of 1000+ organizations, the #1 response to the question
“What is the most important skill of a team leader?” the answer was
“Communication”
The Communication Plan should consider “Who you need to communicate
with?”, “What the message to be communicated will be?”, “What is needed

27
D4 – Identify Root Cause
All 8 Disciplines of the 8D are important. However, there are two Disciplines
that require special attention, D2 – Problem Definition and D4 – Identify Root
Cause.
Identifying Root Cause is the least understood and most difficult part of 8D.
The 8D practioner needs many Root Cause tools at their disposal. But to get
good at finding Root Cause, practioners need to practice . . . . . . . . . . a lot.
One challenge with finding Root Cause is knowing what it looks like. There
are 4 levels of a problem and each can be mistaken for the Root Cause:
Observations ⇒ Symptoms ⇒ Possible Causes ⇒ Root Causes
Observations: can be direct, indirect, conscious or unconscious experiences or
events. It is the ‘noise’ of daily life that largely goes unnoticed or is considered
so trivial that more than a fraction of time thinking about it, is too much.
Examples:
v My watch seems to be running slow
v The steering in my car feels different
v The microwave doesn’t heat water as quickly
Symptoms: directly observed departures from normal operation. These are
the events that have us consider that something is awry. Examples:
v I’m late for a meeting but my watch says I’m on time
v I’m clearly having trouble navigating corners
v The microwave is seemingly putting out less power
Possible Causes: also know as potential Root Causes. These are plausible
reasons for the unconformity. Unverified Root Causes. Examples:
v Bad battery, failing clock mechanism
v Low tire pressure, low power steering fluid
v Failing microwave magnetrons
Root Causes: see definition below. Examples:

30
tool can process. Notice each is assigned H(high), M(medium) or L(low). For
example, the Pareto Chart is low on the complexity scale, requires a low time
requirement, has a low ability to find root cause, has a low level of
subjectivity, is highly intuitive, doesn’t require a cross functional team for it to
be effective (therefore low), and can handle a high number of factors.
No one tool is a panacea and not all of the tools will be reviewed. The
IS/ISNOT, 5 Why’s, Fishbone and Inter-Relationship Diagram will be
discussed in detail next. Proficiency in these four tools will permit the
practioner to solve many Root Cause problems. However, every serious
problem solver should be proficient with all of these.
IS/ISNOT
The IS/ISNOT leverages the D2 - Problem Definition. Using the completed D2,
a series of questions follow. The purpose of the questions is to get the
practioner to consider the undesirable behavior from a number of
perspectives.
Take a moment to describe what you see here . . .
Ask, “what perspective does this represent?” Is it a view from the top?
Bottom? From the inside looking out?

33
Step 3. Evaluate Possible Causes
For each possible Root Cause, use “+” when IS and ISNOT is explained and use
“-“when only the IS or the ISNOT is explained. This is done for each “possible
Root Cause” and “Difference” pair.

36
Each set of statements logically connect to each other using the ‘therefore’
technique and so it is reasonable to assume that the potential Root Cause has
been discovered.
Occasionally there will be more than one answer to ‘why’. In these cases,
simply create a branch for each answer and continue with the process.
Frequently, the answers given to successive ‘why’s’ will converge to the same
potential Root Cause. When they don’t, and each passes the ‘therefore’ test,
treat both as a potential Root Cause.
Notice it is the potential Root Cause that has been found. Until the Root Cause
is verified in D6 – Implement and verify, it is only a potential Root Cause.
Cautions using the 5 Why’s methodology:
1. Teams may stop at symptoms believing Root Cause has been found.
2. Effectiveness is limited to the collective team knowledge, and is
therefore very subjective.
3. 5 Why’s doesn’t guide the team to ask the right "why" questions.
4. Different people using 5 Whys may come up with different causes for
the same problem – the results are not repeatable.
Fishbone Diagram
The Fishbone Diagram, more formally known as the Ishikawa Diagram, is an
easy to understand Root Cause tool. Its other name is the Cause & Effect
Diagram. Primarily used as a structured brainstorming tool, the Fishbone
Diagram helps identify the possible inputs (X’s – Root Causes) that are causing
the problem (Big Y). The Big Y is the process defect that is the focus of the
improvement effort.
The basic layout of the Fishbone Diagram is below:

39
Items labeled ‘X’ are now studied for their impact on the Big Y.
STEP 6: If further "screening" is necessary, assess the likely Root Causes using
the "Impact" and "Implement" matrix. Ask, “how difficult would it be to
eliminate “X” and what impact would this have on eliminating the defect.
Score each based on the matrix below. Then . . .
select items marked 1, then 2 . . . 4 as priorities.

42
D5 – Identify Corrective Action
Based on what is learned from one or more Root Cause tools, decide on the
top 3 most likely Root Cause(s). For each Root Cause, identify the corrective
action . . .
Corrective Action: an action to eliminate the cause of a detected
nonconformity or other undesirable situation.
Don’t confuse Corrective Action with Preventive Action.
Corrective Action is an action taken to eliminate the cause of the defect
(undesirable situation). According to ISO 9000:2000 the definition of
corrective action is: "Action to eliminate the cause of a detected nonconformity
or other undesirable situation."
Preventive Action is an action taken to prevent the defect (undesirable
situation). According to ISO 9000:2000 the definition of preventive action is:
"Action to eliminate the cause of a potential nonconformity or other
undesirable potential situation".
There are a number of creativity tools available to help formulate corrective
actions. They include:
1. Quality Function Deployment
(QFD)
2. Developing Design Concepts
3. TRIZ (Ideal Final Result)
4. Technology Roadmaps
5. Patent searches
6. Competitive benchmarking
7. Nature – How has nature
solved the problem?
8. Existing systems
9. Reverse engineering
10. Old designs
11. Similar systems
12. Modeling
13. Experimentation
14. Intuition / inspiration
15. Brainstorming
16. Creative Sketching
17. Analogies
18. Design catalogues
19. Lessons learned
20. Weak link analysis

45
Tukey Quick Test
1. Once a problem has been detected, collect 8 consecutive samples from
the process, and using the parameter of interest, record whether the
samples are “bad” or “good”. These are samples 1 – 8.
2. After the corrective action is implemented, collect an additional 8
samples from the process again and using the parameter of interest,
record whether the samples are “bad” or “good”. These are samples 9 –
16.
3. Beginning at sample 1, and ending with sample 8, count the number of
consecutive “bad” samples and record this. This is the first end count.
4. Beginning at sample 16 and moving to 15 then 14, etc., and ending at
sample 9, count the number of consecutive “good” samples and record
this. This is the second end count.
5. Add the two end counts together.
6. Interpret results.

48
D7 – Prevent Recurrence
The key to preventing a recurring event is to understand two things:
1. The Control Continuum
2. 3 P’s
The Control Continuum:
At one end of the continuum is low effort, low control. When little effort is put
into a control mechanism, it should be expected to provide little control. For
example, verbal instructions . . . they are easy to prepare and deliver. As such,
limited effectiveness should be expected. Do they serve a purpose?
Absolutely! However, in some cases, verbal instructions should be combined
with other control mechanisms.
At the other end of the continuum, is high effort, high control. This might
include, Mistake Proofing or even redesigning the process . . . high effort with
the resulting high control (usually).
The 3 P’s:
1. People
2. Process
3. Product (or technology)

51
Product Errors:
Product launches and releases to market are happening at an unprecedented
rate. Each year in the USA there is approximately 112,000 new products
launched. The commercial pressure to get to market is so intense that many
products are released with defects. It is the job of the improvement
professional to uncover the defect Root Cause and prevent their recurrence.
The list below are common product problems and preventive actions.

54
Summary Report
The 8D report is a summary of the work done between D0 and D8. Many of
the details are not contained in the report – likely, the report reader is not that
interested. They are however, interested in a summary of what was done at
each phase, and the report is designed to capture these.
From each phase, the essential and relevant information is captured that will
memorialize the problem, its origin, affected customer, affected product, the
scope of the problem, containment action taken, root cause, corrective and
preventive actions, etc.
In addition to these, include pictures or a sketch of the problem. Pictures
generally are a better communication tool than words, so be sure and include
them when available. Additionally, don’t assume the report reader is familiar
with the problem; annotate the pictures where appropriate.
As time passes, the Final Report will likely be the only record of the problem
and corrective action. Be sure it is written so that it is self explaining –
containing the relevant elements necessary to reconstruct the problem
experienced by the customer and the actions taken to correct and prevent it
from recurring. Remember, the report writer is responsible for ensuring the
reader can understand it.
And finally, the Summary Report must be signed. Surprisingly, this too gets
overlooked. Letting the report reader know that it was reviewed and
approved by the Quality Manager, Production Manager, VP, etc. lends it
credibility. It tells the reader that at a minimum, someone in a senior position
is aware of the issue and acknowledges, and takes responsibility for, the work
the team did to correct the problem and that the organization is committed to
(some level of) process improvement.

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

8D The 8 Disciplines Problem Solving Methodology

Recomendados

Recomendados

Más contenido relacionado

Más de Flevy.com Best Practices

Más de Flevy.com Best Practices (20)

Último

Último (20)

8D The 8 Disciplines Problem Solving Methodology