About the Author
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.
Let’s take a look at what each individual element is intended to accomplish.
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.
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:
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.
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.
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.
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.
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.
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).
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:
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.
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.
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.
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 Part 3 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.
 Sproull, Robert F., Process Problem Solving – A Guide for Maintenance and Operation’s Teams, 2001, Productivity Press
 Kepner and Tregoe, The New Rational Manager, 1981, Kepner-Tregoe, Incorporated
Stay on top of industry trends and insights.
Subscribe to the Big Ideas for SMBs blog.
About the Author