Home > Blog
Read Time — 9 minutes
Now that we can see the advantages of using a logical and systematic problem-solving approach, let’s look at a typical problem-solving format. Many problem-solving formats are in use, and nearly all of them use the basic elements of a logical pathway.
1. Identify the problem.
2. Describe and define the problem.
3. List the symptoms.
4. List the known changes.
5. Analyze the problem.
6. Hypothesize possible causes.
7. Test possible causes.
8. Take action(s) on the cause(s).
9. Test and implement the solution.
10. Implement appropriate controls.
11. Celebrate, recognize success, and document.
Let’s take a look at what each individual element is intended to accomplish.
1. Identify the problem
A problem as a deviation from an expected level of performance, with no known cause or solution, which has a negative impact on an organization. In order to identify and ultimately solve a problem, we must know exactly what the expected level of performance should be compared to the current actual performance. We must also understand the effect of the deviation on the organization and why it is considered negative.
2. Define and describe the problem
Describing and defining the problem is the foundational step in the process. The problem description builds the platform for the problem-solving activities that follow, so it must be as complete and accurate as possible.
For example, suppose you are given the task of solving a problem involving a motor that stopped functioning. Because you had solved a similar problem in the past, you assume the root cause was a burned-out armature. By limiting yourself to actions that might be related to things like a defective overload or a short in the electrical system, you may miss other potential causes of the problem. What if the real root cause was seized bearings that resulted in excessive heat build-up, which led to the motor shutting down?
When describing the problem, it helps to view it from two separate perspectives: the object and the object’s defect or fault. By asking a series of simple questions, you will develop a more complete definition of the problem as follows:
1. What is the specific object with the problem and what feature has the fault?
2. Where is the location on the object with the fault?
3. When in time and in the process cycle of the object was the problem first observed? Determining the clock and process stage times is a key to understanding the problem.
4. How many objects have the problem, and how many faults are observed on the objects?
5. What is the trend and scope of the problem? Is the problem rate increasing, decreasing, or remaining constant? Is there a distinct pattern?
It is helpful to answer these questions by contrasting the object with the fault to another like it (or a similar object) without the problem. That is, ask not only where the problem is, but also where it is not. Where would you expect to see the problem, but you do not? These comparisons help you zero in on critical distinctions in your effort to solve the problem. When this step is complete, you will have a complete definition and description, which you will distill into a succinct problem statement. This will function as a problem-solving compass for all of the next steps you will take in reaching a solution.
3. List the symptoms
Solving problems is the culmination of many different activities. Among the most important is developing a list of symptoms of the problem being solved. If you’ve ever been a patient in an emergency room, you may have observed the medical problem-solving process. Doctors know that developing a list of symptoms is paramount to a precise diagnosis. They usually check temperature, blood pressure, pulse rate, eyes, ears, abdomen, and lungs. Checking these bodily functions for symptoms reliably and consistently leads them to the root causes of patient problems.
Using your senses can also help you uncover symptoms of problems and potential problems. If you are in a typical manufacturing setting, you might detect common symptoms through smell, touch, sound, or vision. Here are some common examples of problems that you might uncover using your senses.
• Smell: If you smell the odor of burning rubber, you might look for worn or loose V-belts, an electrical problem, or a problem with overheating bearings.
• Touch: If you feel an abnormal vibration, you might look for worn bearings in a motor, loose bolts, or misalignment of shafts.
• Hearing: If you hear a grinding or scraping noise, you might look for misaligned gears.
• Vision: You can detect many things by looking at fluid levels, excessive gaps, and jerking motions.
4. List the known changes
Manufacturing problems are the direct result of changes that have occurred prior to the new, decreased performance level. Even though there is a cause and effect, the change(s) responsible for the performance drop could have occurred at any time prior to the problem arising. For this reason, all changes must be listed and investigated.
Unfortunately, process variables change quickly in many organizations, and the personnel involved often overlook the importance of documenting changes. If you are now investigating a problem without the benefit of consistent documentation, you may be forced to reconstruct the changes by interviewing the process owners. Problem solving ultimately relies on documenting all changes made in the process, including actions taken to repair or improve processes, changes in equipment settings, and variances in raw material lots. If your company does not document exhaustively, then you must insist on this process improvement.
5. Analyze the problem
After you have developed a complete problem description that details all of the symptoms and changes, you can begin to analyze the problem. Effective analysis attempts to relate the change in performance to symptoms, differences, changes, and times. In other words, your goal is to determine the differences between what the problem is and what it is not, where the problem is and is not, and when the problem occurs and does not.
With an understanding of these four puzzle pieces—symptoms, differences, changes, and times—you are ready to form hypotheses for possible causes. Approach this step with the anticipation that your problem may have one or more root causes.
6. Hypothesize possible causes
Following your analysis, the next step is to create a list of realistic potential causes. This is not a list of guesses, but a logical and systematic review of the information you have collected. If you need more data to develop this list and make it more useable, then continue to collect the information you will need. Involve as many knowledgeable contributors as possible. A logically developed list reduces the likelihood of reliance on intuition and hunches.
With your list in hand, ask your collaborators how the observed differences in what, where, and when could have caused the problem. Remember, problems represent the outcome of a series of multiple cause and effect relationships.
7. Test possible causes
Next, distill your list into a shorter rundown of the most probable causes by testing each possible cause against a pre-determined set of test criteria. Using “if-then” statements, one can develop these test criteria quite simply. For example, “If I increase the voltage, then x (x=some predictable event) should happen.” Each possible cause must be looked at individually and only the survivors will be considered among the most probable causes. Your final list will be tested using more rigorous criteria to further zero in on the root cause(s).
8. Take action on the cause(s)
Once you have hypothesized causes, distilled them into a short list of probable causes, and tested those causes using rigorous criteria, you should have a short and manageable list. At this point, the next step is to decide on an appropriate action, or actions. Your choices are as follows:
1. Take no action and decide to live with the problem.
2. Take a short-term action that will effectively buy you some time.
3. Take a long-term corrective action that will eliminate the problem.
Your first priority should be to take an action that will completely stop the negative effects of the problem. Once you have done this, you can begin to implement preventative actions by considering the controls that can be put in place to avert a recurrence of the problem. An example would be adding a check as part of the preventive maintenance on the equipment.
9. Test and implement the solution
Often, problem-solving teams engage in a complete analysis, develop solutions, implement them, and then assume they have fixed the problem. That assumption often has adverse consequences (as many assumptions do). Never implement a solution without ensuring the solution does not have a negative impact on the process in question! Always perform a first-piece inspection (possibly a more extensive inspection) to ensure that the end-product meets all performance requirements.
10. Implement appropriate controls
Once the root cause has been identified and a solution is tested, it is imperative that you implement controls to prevent the problem from recurring. These controls might include an update to the preventive maintenance (PM) checklist or a control chart of the measurable factors associated with the problem. This step is not satisfied until you have implemented preventive measures and/or controls.
11. Celebrate, recognize success, and document
When people are recognized positively for what they have done, they are incentivized to solve more problems. The final part of this step is to document what the team has accomplished. By applying the eleven steps of the logical pathway in succession, a formal report can be written and saved as a resource for future teams.
In the next post, we'll explore many of the things that should not be overlooked when trying to solve problems, but are often disregarded. This discussion will include the importance of deductive reason, good judgement, and common sense. It will also include sections on different types of problems and problem solving traps.
[1] Sproull, Robert F., Process Problem Solving – A Guide for Maintenance and Operation’s Teams, 2001, Productivity Press
[2] Kepner and Tregoe, The New Rational Manager, 1981, Kepner-Tregoe, Incorporated