Monthly beauty: Porsche 911 Carrera S
Source: - the quality management portal launched! Check out our Knowledge Base, News, Company Database and more...
Everything about quality management, quality products and quality companies.
Events / News
Quality knowledge base - article QA-0051
Updated on 04-03-2021

Problem Solving

Problems always existed, and will surely come up in the future. It can be a technical defect, an organizational issue, or anything that holds a barrier between us and the desired state. The question will always be the same: how can we prevent problems before their occurrence, and if they occur, how can we solve them with the highest efficiency. Problem solving needs analytical thinking and creativity. Often thinking "out of the box" leads to success. As we solve the problems of the organization, we can both directly and indirectly improve business results.
Having an ordinary mindset, we might think, that the problem is solved when we only resolve a given issue. In this case, we do not take any effort to prevent its further recurrence, so besides correcting an undesired state, a major part of problem solving is the prevention of the failure in the future.
Problems can have many entities (technical defects, failure of a process, etc.) and different chronology (sudden, constant, repeating time-to-time, deteriorative over time, etc.). Depending on the consequences, the problem holds risk, and must be eliminated.
Generally in any industrial field, problems mean technical or organizational defects, that can diffuse to financial and prestige issues. During the history of quality management, several key techniques and methodologies were developed to foster and motivate analytical problem solving, thus creating direct and indirect value for the organization. Such examples are the Global 8D methodology, set into frame by Ford, or the PDCA (Plan-Do-Check-Act) Deming cycle, but we can also mention the 6 Sigma methodology, which also aims to resolve issues, leading to the improvement of business performance.
ISO 9001 standard requires to determine the root cause of nonconformities, to implement corrective and preventive actions and to review the effectiveness of all actions. The automotive specific IATF 16949:2016 goes further by requesting the application of a defined problem solving process, error-proofing and the spreading of counter-measures to similar products and processes.
TEST ADVERTISEMENT (for temporary testing purposes, source:
Key Features
Irrespectively of the affected field (technology, finance, etc.), the problem solving process has a general structure. All problem solving procedures and quality improvement methodologies (e.g. 8D, PDCA, 6 Sigma, Kepner-Tregoe, Shainin, etc.) have a logic sequence of basic tasks that rely on common sense. Problem solving always aims to understand the problem, identify and understand its cause(s), and eliminate the cause(s) by implementing and verifying effective corrective and preventive measures.
Based on the aforementioned sequence, the different methodologies can be put into a uniform grid (see chart).
Quality Management
Problem solving methods (Source:
In this section we will focus on the "8 Disciplines" method, which is most current problem solving procedure (methodology) in the automotive industry, however is can be used in every field, thanks to its logic sequence. 8D is a team based method, and a major part of continuous improvement. There are plenty of other methodologies as well, such as 6 Sigma, PDCA.
Many questions come up that we need to answer before and during solving a problem:
  • Who will need to work on the issue, who can solve it (problem solving team)?
  • What is the problem, and what is not (problem description)?
  • How can we contain the failure before it spreads further (containment actions)?
  • What has caused the problem (root cause)?
  • What possible solutions do we have that eliminate the cause (corrective actions)?
  • What actions we select from the possibilities, and which of them will be finally implemented (implemented corrective actions)?
  • How will we prevent the recurrence of the failure on other lines / in other plants / in other projects (preventive actions)?
We will use best practices and effective tools to be able to answer these questions, going through the 8D steps, which are:
  • D1 – Establishment of Problem Solving Team
  • D2 – Problem Description
  • D3 – Immediate Containment Actions
  • D4 – Root Cause Analysis (Cause – Effect analysis)
  • D5 – Definition of Possible Corrective Actions
  • D6 – Implementation of Corrective Actions
  • D7 – Preventive Actions
  • D8 – Congratulations, Wrap-up
Quality Management
The 8D sequence (Source:
In the following part, we will go through the Eight Disciplines of Problem Solving.
D1 – Establishment of Problem Solving Team
Problem solving is never a one man show, but a teamwork. This is not just an empty sentence, but the reality. There are no complex problems that affect only one person, one group or one department. Establishing an effective team is necessary with the knowledge and expertise of relevant technology, processes, supporting quality methods, etc. In addition, having an 8D team provides dedicated resources and a sponsor. Of course there are problems, that shouldn’t be pumped up, and can be resolved by oneself (see table below), but these are usually not the complex issues.
The "weight" of the issue
Problem To be involved / informed
"There is a big mess on my desk" No one, I should set it in order by myself…
"The customer just informed us of 25 defective units that failed on its line. We have to start collecting data, while the parts are on the way..." Complete team, including:
Customer Quality Engineer (supplier later if necessary)
Product Engineer
Process Engineer
Testing Specialist
Management, etc.
D2 – Problem Description
Describing the real problem is the key for understanding the root cause(s) and for proper decision making. Fundamental understanding of the problem is the first step to be able to find its cause, and to eliminate it. Proper description must contain the following problem features and problem related questions:
  • Collection of information is fact-based and structured (all facts are collected systematically: data, numbers, photos, drawings, flow-charts, etc.).
  • No root cause hypothesis yet!
  • Instead of listing the possible causes, concentrating on the failure and the claimed symptom (at this stage the cause is unknown).
  • Unambiguous description of the problem (What the problem IS, and what IS NOT)
  • What is the deviation between the desired state and the current state?
  • Where was the failure detected in the supply chain?
  • When and how often was the failure observed?
  • What are the affected objects (how many, what part numbers, what product families, etc.)?
  • Question: are all information confirmed? What is missing?
By having the right questions and describing the problem / failure leads us to be able to provide usable information for the team (e.g. depicting failure patterns). This information will be crucial during step 4 (D4 – Root Cause Analysis).
In practice, customers usually see only the symptom, and only give these symptoms when communicating the defect, so understanding the fundamental problem that leads to the symptom can be difficult. Do not forget: at this phase of the problem solving, we do not know the root cause yet (see chart about the "cause – problem – symptom" interaction).
Important! The proper understanding and definition of the real problem (not symptom!) is crucial, otherwise the D4 (root cause analysis) will be everlasting. Hint: already start your convergent thinking and strategy creation how you want to solve the given failure (useful tools: IS/IS-NOT, Shainin Red X (R) tools and structure, e.g. solution tree, component search, etc.)
Quality Management
The "Symptom-Problem-Cause" interaction (Source:
As it was written above, the detection point of the failure is an important information. The automotive industry has created the following failure types, depending on detection point of the failure in the supply chain:
  • Customer (0km) – failure is detected at the customer’s site.
  • Customer (field) – failure is detected by the end customer / dealership.
  • Internal (plant) – failure is detected in the manufacturing plant, the department, which detected the failure raises the claim toward the causing department.
  • Internal (plant to plant / inter-company) - failure is detected in the manufacturing plant, the production plant, which detected the failure raises the claim toward the causing plant.
D3 – Immediate Containment Action
It is the first physical action we take, however it’s a reactive one, used for mitigating the failure effect in the supply chain, instead of focusing on the elimination of the cause. We need to apply 100% effective containment until we implement a proven corrective action, which will be eliminating the root cause of the problem. After implementing a containment action, we have to maintain it by continuous monitoring and frequently review (it’s not enough if we verify it before its implementation, since what works on small scale, doesn’t surely function on large scale). Besides that, the information provided by the containment action can be helpful for investigating the root cause, by gathering valuable information about:
  • Which products, part numbers are affected.
  • In what time-frame we produced the affected parts.
  • The defect distribution seems sporadic (random), systematic (repeating pattern), etc.
Quality Management
Link of containment and corrective actions (Source:
If preventive action is the "vitamin and healthy food" and corrective action is the "surgery", then containment action is the "first aid bandage".
Examples for immediate containment actions:
  • 100% visual inspection and sorting.
  • 100% measurement of a given characteristic.
  • 100% extended test for the affected technical defect (e.g. In-circuit test, electrical function test).
  • Blocking of stock in the supply chain, or recall action (line, warehouse, customer’s warehouse, etc.) for inspection.
  • CSL (Controlled Shipping Level), firewall.
D4 – Root Cause Analysis (Cause – Effect analysis)
The fourth section of the 8D is aiming to find the real causes that lead to the problem and the symptom. Root cause analysis is one of the most difficult part of problem solving, as we have to investigate the complex aspects of the failure mechanism, we have to search for patterns, what has changed, what has caused the "variation". Luckily, there are several methods and tools available, which support us during this task.
The importance of effective root-cause analysis is crucial, as we cannot define and implement actions to eliminate the cause without finding it. Also, it might happen, that incorrectly performed root-cause analysis misleads us, and we define actions that are ineffective against the real cause. It is very important to do our analysis procedure unbiased. Prejudiced root cause analysis guides us to improper decisions. On top of that, we have to emphasize proper failure description (D2), as it is the basis of efficient root cause analysis.
We distinguish two layers of the root cause. The first, direct one is the technical root cause, while the deeper one is the management or managerial root cause (also called system root cause). Technical root causes mean the more direct causes that are near to the technical problem. To find the management root cause, we have to drill deeper into the system, organization, etc.
Quality Management
Managerial (system) and technical root cause (Source:
Generally, during investigating the cause effect relationships, we try to:
  • Identify all possible causes and cause interactions.
  • Determine and verify the real causes, which must be eliminated to finally extinguish the problem.
By analysing the root cause(s), we have to focus not only on the occurrence of the defect, but also on the non-detection:
  • Non-conformance / Occurrence (How could the failure happen?).
  • Non-detection (How could the failure slip through? Why haven’t we detected it?).
Finding all root causes and all cause effect relations is a complex task, and it’s rarely an easy job, however during the 20th century many logical and transparent root cause analysis methods have been developed, such as:
  • 5 Whys (one of the most simple, and commonly used).
  • Ishikawa diagram (alias fish-bone). Important: not advised for complex technical issues, as fish-bone promotes divergent thinking, yet convergent methods are mush more efficient and effective.
  • Failure Tree Analysis (quite common in the automotive and electronics business field).
  • Convergent methods and tools: Shainin Red X, TNSFT toolset
  • Design of Experiment (DOE), correlation, regression analysis. Important: use DoE in the sense of really designing your tests (target, effort, etc.), and try to avoid full factorial DoE (it's brute force and against convergent thinking.
  • Systematic review of process flow, failure mapping.
  • Analysis of historical data (searching for patterns).
In industrial environment, the origin of technical (and management) root cause can be originated from various sources. That is why having an 8D team is crucial to find these causes. In particular cases, the defect itself may be originated from the customer, due to misuse or mishandling, thus the involvement of the customer into the root cause analysis is important. The source of the technical cause (causing process) can be:
  • Supplier (defective raw material / sub-assembly).
  • Customer (misuse, mishandling).
  • Production.
  • Development.
  • Logistics.
D5 – Definition of Possible Corrective Actions
Depending on the identified root cause, finding the best solution in the form of corrective actions can happen in the frame of brainstorming by involving the concerned experts. During this phase, it is advised to note all possible solutions without immediately shooting down any of them. Gut rejection may lead to inefficient or completely wrong decisions.
Important points for defining effective corrective actions:
  • Define corrective actions against both non-conformance and non-detection root causes.
  • Define corrective actions to eliminate not only the technical, but also the management root causes.
  • Before implementing any action, verify its effectiveness on small scale with a pilot program.
  • During a pilot, test your action by analysing the fact-based results, and search for possible side effects with risk analysis, FMEA, etc.
  • The results of the pilot must be documented!
  • Always try to implement error proof, poka-yoke solutions.
  • You have to reach the total elimination of the failures with your actions.
  • If possible, propose multiple solutions for the management, especially in case of actions that require high capital or operating expenditure.
D6 – Implementation of Corrective Actions
After defining possible corrective actions, the 8D team has to select the ones to be implemented, by setting up an action plan with deadlines and responsible team members.
Beside physical implementation, the actions must be documented in the relevant living documents (FMEA, CP, Work instructions, etc.).
Though the planned corrective actions were probably analysed up-front (before their implementation), the verification after the serial implementation is still a must. Again, the verification has two major purposes: verification of the effectiveness and getting to be assured, that no side effects came up. Corrective action is in close conjunction with possible preventive actions, they are quite often named together, such as CAPA (Corrective Actions and Preventive Actions).
It is strongly important to note, that the containment actions implemented in step three (D3) can only be stopped when the relevant corrective actions surely eliminated the root cause.
D7 – Preventive Actions
The intent of preventing failure occurrence is a systematic preventive approach. By using the tools of risk analysis, FMEA, manufacturing capability test, etc., we take up-front measures to eliminate the chance of a failure. Now the logic question comes up: why do we have a preventive actions block in our problem solving process, if the problem has already occurred?
The answer is simple: even if the problem has occurred, we don’t want it to happen again on other manufacturing lines, in other facilities, in other divisions. So the "preventive actions" block in the 8D process is focusing on the solutions against failure recurrence. The widely used tool to spread the knowledge of the failure and the solution is the Lessons Learned methodology.
Preventive actions
Action Useful Tools Aim
Preventive actions (during the APQP) Risk analysis, FMEA, CP, Capability studies, Feasibility studies, Lessons Learned (similar projects, potential failures) To eliminate the chance of a potential failure, that has not yet occurred with the actual product (but may be occurred in connection to similar products / projects)
Preventive actions (8D) FMEA, CP, Lessons Learned (occurred failure) To eliminate the chance of a previous failure to reoccur in the organization
D8 – Congratulations to the Team
The last point of the 8D report is the section for giving thanks to the team, and to summarize additional information that the team leader wants to emphasize.
Problem solving and root cause analysis needs analytical thinking, fact based proofs, filtering out irrelevant information, seeing coherences and correlations, avoiding bias in group works.
Containment actions are immediate and interim, but their importance is not negligible, and need planning and verification. It mustn’t be forgotten: the efficiency of visual inspection is only 80-90%.
Before starting the analysis of the root cause, we have to make sure of getting trustworthy information. Written and verbal information may also contain error, not only our measurement system. Such as we verify our measurement system with MSA, so we should validate the received information with plausibility checks.
By finding the technical root cause(s), do not stop there, but try to find any eliminate the management root cause(s) as well.
You can be firm about the root cause with theory, but you can only be completely assured after being able to reproduce the failure (one of the most basic principles of 8D and 6 Sigma methodology).
The importance of Lessons Learned is high to avoid failure recurrence. The best LL systems are ergonomically developed systems, providing prompt, fact based information. If we share only the failure mode and the root cause, it’s not a Lesson Learned. Good LL brief information always contains the solution as well.
To give a comprehensive hint list regarding problem solving, the following list contains some most important points you should consider:
Quality Management
Hints to consider for problem solving (Source:
  • Problem solving always aims to understand the problem, identify and understand its cause(s), and eliminate the cause(s) by implementing and verifying effective corrective and preventive measures.
  • Irrespectively of the affected field (technology, finance, etc.), the problem solving process has a general structure. All problem solving procedures and methodologies have a logic sequence of basic tasks that rely on common sense.
  • ISO 9001 standard requires to determine the root cause of nonconformities, to implement corrective and preventive actions and to review the effectiveness of all actions.
  • Several key techniques and methodologies were developed to foster and motivate analytical problem solving and process improvement, such as 8D, 6 Sigma, Kepner-Tregoe, Shainin Red-X.
Relevant Topics
Process Improvement and Problem Solving
Plan Do Check Act (PDCA)
Process Improvement and Problem Solving
6 Sigma / DMAIC
Process Improvement and Problem Solving
Global 8D
Process Improvement and Problem Solving
Quality Claim Management
Process Improvement and Problem Solving
Root Cause
Process Improvement and Problem Solving
5 Whys
Process Improvement and Problem Solving
Failure Tree Analysis (FTA)
Process Improvement and Problem Solving
Fish-Bone Diagram (Ishikawa)
Process Improvement and Problem Solving
Pareto Analysis
Process Improvement and Problem Solving
Containment Action
Process Improvement and Problem Solving
Corrective And Preventive Action (CAPA)
Process Improvement and Problem Solving
Poka-Yoke (Error Proofing)
Process Improvement and Problem Solving
Failure Statistics
Fact sheet
Information about systematic problem solving in quality management.

Topic / Article: Problem Solving
Term Category: Process Improvement and Problem Solving
Business Sector: All
Timing: Both in project and series phase
Files, Attachments: None
Term Up-to-date
Scroll to Top