Most problem-solving tools are built on PDCA (Plan-Do-Check-Act) model, and 8D is one of the popular tools in this category.

8D is a structured approach to investigate and solve various problems and provides many benefits for the users, such as identification of permanent positive solutions, increase effectiveness and efficiency of processes and provides a standardized method of addressing the problems.

The 8D acronym comes from a list of 8 Disciplines, and these are:
        D1. Use a team approach (8D team)
        D2. Problem Description
        D3. Interim Containment Actions
        D4. Identify the Root Causes
        D5. Plan Solutions/Actions
        D6. Implement Solutions/Actions
        D7. Prevent Recurrence
        D8. Team recognition

D1: Problem-Solving Team

The first characteristic of this tool is the team approach, in other words working on the problem in a team. This doesn’t mean that every situation to be addressed will require a large team, or even a team, instead, the size of the team should be commensurate with the complexity of the problem in question. Individuals may solve certain problems, even using this tool, by working alone.

When gathering a team, it is important to consider:
• Who will be part of the team? The most successful teams are cross-functional, and a variety of skills, knowledge and expertise may help solve problems faster and find better solutions.
• What is the team size? Smaller teams are generally working better and more efficiently.
• What roles will be needed in the team? Some of the most common roles in a team are Team leader, Champion, Subject Matter Expert, Sponsor, Records keeper, Timekeeper, Contributor, etc.
• What are the team boundaries? Limitations are to be defined to know the boundaries of the team.

After the team is gathered, few start-up elements need to be clearly defined:
• Assign a role for each team member
• Define the ground rules, like communication methods, meetings, conflicts resolution, decision-making process
• Communicate the team boundaries, like deadlines, budgets, team members’ time constraints, compliance to regulations, communication required, activity scope, approvals required, etc.

D2: Problem Description

This second discipline is very important as it may set the team for a successful and efficient resolution of the problem if defined properly.
The problem description should:
• state the problem to be investigated,
• provide details about how and where the problem was detected or can be detected,
• highlight the known symptoms
• provide any other known information.
In this step, the scope of the investigation needs to be clarified, what is included and what is excluded from the investigation of the problem.
Problem description focus is to provide initial background data to the problem-solving team to be able to investigate and properly address the problem and not to state any solutions in this step.

D3: Interim Containment Actions

Interim containment actions are those actions, as the name says, defined and implemented to contain the problem temporarily, or in some cases to prevent potential safety issues until root causes are found, and permanent solutions are defined and implemented. In certain situations, it may protect the customer or the organization itself while the problem-solving team works on permanent measures.
The need and complexity of the interim containment actions depend on the context of the problem. The interim containment is usually costly and does not add value to the process, but it may prevent further costs caused by the problem. Temporary activities like sorting the goods, stopping deliveries, slowing down the process, adding extra steps in the process, all constitute examples of interim containment actions.
Even if these actions are temporary, they still should be validated that they work as intended and do not cause other problems.

D4: Identify the Root Causes

The critical step in this problem-solving tool is the identification of root causes. Most recurrences happen because root causes are not properly identified, and the problems are treated only superficially by addressing the effects of the problems.
Usually, the problem we see at the surface is just an effect of the real problem (root cause). Finding the real problem, the root cause of the issue usually involves looking at the effects and identify their causes, as well as use data to dig deeper until the root cause is identified.
There is no special unique formula to identify the root cause, and depending on the nature of the problem, one or more tools may be used.
Among these tools, there are multiple categories, like:
• Process Mapping tools (e.g., Flowcharts, Workflow diagrams, Value Stream Maps, etc.)
• Data Collection tools (e.g., Brainstorming, Cause & Effect Diagram / Fishbone, Checklists, Surveys, Tallys Sheet, etc.)
• Data Analysis tools (e.g., Pie Charts, Histograms, Trend Charts, Scatter Diagrams, Pareto Charts, Five-Whys, Cost of Quality, What is – What Isn’t, etc.)
• Statistical tools (e.g., Control Charts, Anova, Process Capability, Gauge R&R Studies, Design of Experiments, etc.,)

Every problem may have or multiple causes, which can be grouped to form a Cause & Effect Diagram into categories like 6M (Method, Machine/Equipment, Medium/Environment, Material, Manpower/People, Measurement) or Affinity grouping (e.g., 8 Wastes: Motion, Inventory, Waiting, Transportation, Defects, Overproduction, Overprocessing, Underutilized skills).

Cause – Effect Diagram

In general, a cause is an effect of a deeper cause, which also is an effect of another cause, creating this way a chain of causes & effects. Going back to find the cause of each effect, may lead us to the root cause. While collecting the data helps us find answers to questions about “when”, “where”, “how”, “who” and “what” happened, understanding the “why”, can be our root cause.
To understand the “why”, investigative tools, as 5-Whys, What Is-What is Not, or Timeline Analysis can be used.
How do we know that we found the root cause? If the root cause we found explains all that we know about the problem is and what isn’t, that it is very likely that we identified it properly. However, the root cause should be verified and one method to do so is by running some simulations to see if it triggers expected failures based on the gathered data or by implementing the solutions defined and validating the outputs versus expectations.

D5: Plan Solutions/Actions

To plan the solutions to implement, first it is needed to compile a list of potential solutions which may address the root cause. A solution or multiple potential solutions will become evident once the root cause is found. Then based on pre-established criteria for evaluating these potential solutions, some solutions will be selected. These criteria may include (not exhaustive list): practicability, feasibility, cost-effectiveness, transferability, robustness, sustainability, ability to prevent the problem from recurring, etc.
Always, the preventive solutions must be favoured versus detection solutions. When prevention is not possible, the strongest detection solution needs to be chosen.
In some cases, depending on the boundaries set in the beginning, certain approvals may be needed before the solutions/actions are implemented.

D6: Implement Solutions/Actions

In this step, a formal action plan needs to be developed. Depending on the complexity of the actions, Project Management tools (e.g., Activity Plan, PERT Chart, Gantt Chart) may be used to plan and track the actions.
Every action will need to respond to three questions: “what needs to be done?”, “who will do it?” and “by when will be done?”, in other words, it needs to have along with the solution, a responsible and a deadline.
Once an action is implemented, a confirmation that it works and does what it is intended to do needs to be done. Where applicable, documentation should be changed, and job training should be done.

D7: Prevent Recurrence

With the solution in place, before anything else, it is needed to verify and validate the solution. Hard data must be collected and reviewed to ensure that the root cause was properly addressed, and no other problems surfaced. Data analysis and statistical tools may be used in this step. Internal audits may be used to check the effectiveness of the solution.
Once this is completed, the interim containment action which is still in place can be removed and any relevant documentation must be updated. Also, it is beneficial to share lessons learned with others in the organization and implement the solution to other similar processes which may be affected by the same root cause.

D8: Team recognition

The team deserves congratulations upon completing the project and eliminating the problem. Letting team members know that their work is important for the organization, is an important part of the recognition process.
They are many forms of recognition, and it should match as much as possible the personal style of the team members. This can be done through group celebrations, internal communication, one-on-one acknowledgement, bulletin boards, town halls recognition, “thank you” notes, rewards, etc.
But the most important part of the recognition is to be sincere and timely.

Saying or giving a “Thank you” note is easy, but makes a big difference.