6 Problem Solving Pitfalls and Countermeasures

Everyone has problems. We all have things that go wrong, both in our personal and professional lives. We even use the word “opportunity” instead of “problem” sometimes to add some levity or sarcasm. By its definition, a problem is an undesirable condition. We want to fix it and make it go away. It certainly makes us feel better when we solve the problem and are the conquering hero that saved the day.

People that are viewed as good problem solvers are valued. We know they can help. They just seem to have a knack for figuring things out. In truth, we all have different abilities and skills, and some people ARE better at getting to the crux of the problem. But, how do they do it? Is problem solving a learned or innate skill?

There are pitfalls or mistakes that many people make when attacking problems. If we can recognize and avoid these mistakes and follow a clear process approach, all of us can become better problem solvers. Using the terminology of problem solving, we can deploy strategies to avoid these mistakes.

Pitfall #1 – We all think we know what the problem is. Many times, a problem solving team is assembled and they immediately discuss possible causes or solutions. Team members may have different information or a different understanding of the problem. Discussions are confusing, disjointed and inefficient. We do not have a common purpose.

Strategy #1 – Create a clear problem statement devoid of an unnecessary or distracting description. A clear problem statement contains an OBJECT (the thing which has the problem) and the DEFECT (undesirable condition or defect). The famous inventor, Charles Kettering, stated, “A problem well stated is a problem half solved.” Once we have this statement, we can start asking “why” questions to dig deeper into the causes, and all team members have a common focus and understanding.

Pitfall #2 – We ask, “How could this have happened?” The word “could” leads to conjecture and opinion. We rely on experts and the history of what we “think” we know without collecting the facts around the specific event in question.

Strategy #2 – Ask, “Why DID this happen?” Gather the evidence and collect facts. Think of the event as a crime scene and you are the investigator. Focus your actions on extracting any possible evidence starting with the most minute or microscopic detail so that nothing is overlooked. Dorian Shainin, a famed industrial problem solver and college professor, encouraged problem solvers to “talk to the parts.” The evidence or clues tell a story, which will lead to identification of the causes.

Create a structure from a microscopic to macroscopic view. Assemble your facts against this structure looking for signals or contrast. Where contrast or differences are observed, something is causing that difference. Continuing to ask WHY the contrast exists can lead you to the fundamental or root cause(s).

Pitfall #3 – We try to solve multiple problems simultaneously. Asking WHY questions and gathering evidence to answer them with confidence is essential. This approach is called the “5 Why” method. A why question is asked and is answered with a BECAUSE statement. We can ask another why for the new statement and so on. The number five implies that if we ask why five times, we will probably arrive at a fundamental or root level which, if addressed effectively, will eradicate the problem. It sounds very simple, but teams can become confused because they don’t follow a clear line of questions. Since the BECAUSE answer depends on the WHY question, teams can follow different paths of logic and arrive at different conclusions.

Strategy #3 – Separate the problem into three lines of questions. Once the team has created a problem statement, and collected the initial evidence about the problem, they should decide what questions make sense for the given problem. The initial questions originate from:

• Why did the problem OCCUR?
• Why did we not DETECT and CONTAIN the problem?
• Why did we not PREDICT and PREVENT the problem?

As an example, we may have a customer that received a part from one of our processes. This process could be highly capable with very few defects ever occurring. It might be very costly to improve this process further to increase the capability, and it would not make good business or economic sense for us. Of course, the customer doesn’t want any defects, and shouldn’t have to pay for them. Therefore, it makes sense that we should focus on why we did not detect and contain the defect, and not expend any resources on why the defect occurred. We might also wish to review our quality planning or prevention (predict and prevent) to determine if we could improve our ability to avoid future detection problems.

Pitfall #4 – We spend a lot of time and resources and dig too deep. Not all problems are created equal! Some are big and some are small. Some are simple and some are complex. We may not need 5 why questions to arrive at the root. We might need seven or eight! We might need three. The problem and its severity should dictate our level of response. We want to use facts to explain the BECAUSE statement, and we can check the logic chain of our statements by starting with the final statement and adding the word THEREFORE after it, to lead us to the previous BECAUSE statement until we reach the original problem statement. But where do we stop? We don’t need to “cure world hunger” on every problem. We don’t have time to dig that deeply.

Strategy #4 – Decide how deep to question once you select which lines (Strategy #3) should be addressed. The WHY questions take us into deeper levels of complexity. We can define these levels as direct, process, and systemic, moving from basic to complex. Once we select a line of questioning (occurrence, detection or prevention), we will certainly need to answer a WHY question to identify a cause. We will typically need to focus on the process involved and identify what went wrong with perhaps a few more WHY’s. BUT, we may NOT need to delve into the system that created the process.

For example, we may have created a defect because a component on a machine failed to perform properly (direct cause). The component may have failed because there was no preventive maintenance performed on it (process). If we stop at this level, a reasonable corrective action would be to establish an appropriate preventive maintenance plan for this component. The systemic level question would focus on why our preventive maintenance management system failed to create an effective plan for this component. Obviously, that is a deep question and could lead to significant consumption of time and resources to address effectively. Maybe we “shouldn’t go there” for now.

It might also be helpful to think of YES/NO type questions, particularly at the process level, to help focus our WHY thinking:

• Is there a defined process involved in this problem? This could be the occurrence, detection or prevention process depending on which line of questions we are pursuing. If there is not a defined process, we can focus our solutions on defining it.
• If a process DOES exist, was it followed?
  • If it was NOT followed, we need to ask why, and consider some mistake proofing.
  • If the process WAS followed, obviously, we need to improve the process so that the problem is reduced or eliminated.

Pitfall #5 – We assume we are right. We answer the why questions and identify our root causes, but we don’t perform any tests to confirm our conclusions. Did we miss something? Yes, the facts seem clear, but how do we know for sure?

Strategy #5 – Confirm the cause(s) where possible by performing trials/experiments. This is not always feasible, but should be performed whenever possible.

Pitfall #6 – Our actions are ineffective. All our best efforts to identify cause(s) can be for nothing if we don’t ensure we take appropriate, effective actions.

Strategy #6 – Align actions to specific cause(s) and verify they are effective. We may want to even take multiple actions against a specific cause, and we certainly need to test or monitor to ensure our actions work. Otherwise, we need to revisit these actions. If we’ve done a good job of confirming the cause(s), we don’t need to backtrack any further than our actions.

The following table summarizes the above discussion.