Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

8D The 8 Disciplines Problem Solving Methodology


Published on

This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here:


1. Find Root Cause

2. Prevent Recurring Problems

3. Structure your problem solving methodology


This book describes the 8 Disciplines process as it is used to solve problems where Root Cause is unknown. It is to be used in conjunction with the 8D template, ? from The methods in this book conform to the de facto 8D standard used throughout industry and expected by customers and from suppliers.

8D is not a magic bullet. Improper use will lead to erroneous results. Patience and many hours of practice are required to obtain a level of proficiency. However, for newcomers to 8D, this book and the accompanying template will guide you through the process. It is possible, even expected, that Root Cause will be found and preventive measures implemented the first time the process is followed.

D0 ? Preliminary Data is a conventional form used to capture high level data relevant or potentially relevant to the defect.

D1 ? Team Selection is premised on the belief that correct team formation is critical to finding Root Cause and that mistakes made here will permeate throughout the entire process.

D2 ? Problem Definition uses the IS/ISNOT format to define the problem.

D3 ? Containment is a process that involves multiple parties, varying commercial commitments and multidisciplinary collaboration. It is facilitated by a Risk Assessment, Communication Plan, Containment Recommendation & Containment Action Plan.

D4 ? Root Cause is expanded well beyond the traditional 8D tool set of 5 Why?s and Fishbone Diagram by introducing 18 Root Cause tools. This expansive set equips the practioner for every conceivable defect scenario.

D5 ? Corrective Action. 35 different techniques for identifying the appropriate Corrective Action are covered.

D6 ? Implementation also includes Root Cause verification. Learn the 9 methods for validating Root Cause.

D7 ? Problem Prevention includes a look at the Control Continuum and 36 specific actions that can be taken to prevent problem recurrence.

D8 ? Congratulating the team is often overlooked. Learn how to meaningfully reward the team for their efforts.

This book of nearly 60 pages is one of the most comprehensive reviews of 8D available. It is excellent for independent study or classroom training.

Published in: Business
  • Sex in your area is here: ❤❤❤ ❤❤❤
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ❤❤❤ ❤❤❤
    Are you sure you want to  Yes  No
    Your message goes here
  • There are a huge number of presentations on 8D technique. But it would be very benificial to have good case studies through which this can be explained. May be after making them general to maintain confidentiality, i appeal to ll those who feel so, to do something on this front. Thanks. M V Mohan
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi everyone, You can download the full document here:
    Are you sure you want to  Yes  No
    Your message goes here

8D The 8 Disciplines Problem Solving Methodology

  1. 1. The 8-Disciplines Problem Solving Methodology Michael Carter, Ph.D.
  2. 2. 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:
  3. 3. 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. This document is a partial preview. Full document download can be found on Flevy:
  4. 4. 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. This document is a partial preview. Full document download can be found on Flevy:
  5. 5. 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 8D template located at , 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. This document is a partial preview. Full document download can be found on Flevy:
  6. 6. 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 This document is a partial preview. Full document download can be found on Flevy:
  7. 7. 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’s ‘Change Management Tools.xlsx’ This document is a partial preview. Full document download can be found on Flevy:
  8. 8. 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. This document is a partial preview. Full document download can be found on Flevy:
  9. 9. 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. This document is a partial preview. Full document download can be found on Flevy:
  10. 10. 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 This document is a partial preview. Full document download can be found on Flevy:
  11. 11. 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: This document is a partial preview. Full document download can be found on Flevy:
  12. 12. 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? This document is a partial preview. Full document download can be found on Flevy:
  13. 13. 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. This document is a partial preview. Full document download can be found on Flevy:
  14. 14. 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: This document is a partial preview. Full document download can be found on Flevy:
  15. 15. 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. This document is a partial preview. Full document download can be found on Flevy:
  16. 16. 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 This document is a partial preview. Full document download can be found on Flevy:
  17. 17. 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. This document is a partial preview. Full document download can be found on Flevy:
  18. 18. 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) This document is a partial preview. Full document download can be found on Flevy:
  19. 19. 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. This document is a partial preview. Full document download can be found on Flevy:
  20. 20. 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. This document is a partial preview. Full document download can be found on Flevy:
  21. 21. 1 Flevy ( 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 • Media/PR • Billing