- Purpose of the Model
- Philosophy of Problem Solving
- Problem-Solving Model
- Fun: The Bookworm
- Quick Links
This newsletter introduces the Problem Solving Model. This is a ten-step model to guide you (and your team) through a structured problem solving process. All too often, people jump from a problem to a solution. And it is often a solution that is short-lived or creates numerous other problems within the organization. The Problem Solving Model provides you a road map to continuous improvement.
Purpose of the Model
As its name implies, this model is the road map to follow to solve problems. What makes something a problem?
a) When the process isn't doing what it is supposed to and people don't know why.
b) When things keep going wrong no matter how hard everyone tries.
c) When everyone believes that there is a problem to solve.
The first step in the model is to define the problem; it does not matter if it is late shipments, stock outs, computer downtime, typos, lost messages, or an agreed upon "red bead" that everyone keeps running into. Before you can solve the problem, you must truly understand what it is. This means brainstorming about the process, using a Pareto Diagram to prioritize potential obstacles and creating a process flow diagram of what is currently going on. After you have the problem defined, the model leads you through analyzing data you gather about the process, determining the root cause of the problem, and identifying possible solutions to the problem. Solutions to the problem will either be changes to the process which eliminate special causes of variation or changes which reduce common cause variation. After the best solution is implemented, the model leads the team to monitor the impact of its revisions to make sure that the problem is truly solved.
The problem-solving model, introduced below, incorporates an effective set of skills into a step-by-step process. The model combines the use of statistical tools, such as control charts and process flow diagrams, with group problem-solving skills, such as brainstorming and consensus decision-making. The statistical tools help us make data-based decisions at various points throughout the model. The group problem-solving skills help us draw on the benefits of working as a team.
Philosophy of Problem Solving
Before we begin a discussion about the steps of the problem-solving model, we should talk a little about the philosophy that good problem solvers have about problems. Here are a number of ideas that are part of the philosophy.
Problem solving should occur at all levels of the organization. At every level, from top to bottom, problems occur. Everyone is an expert in the problems that occur in his or her own area and should address these problems. Problem solving is a part of everyone's job.
All problems should not be addressed with the same approach. There are some problems that are easily and suitably tackled alone. Not all decisions need to be made by teams nor do all problems need to be solved by groups. However, groups of people help to break mental sets (i.e., figuring out new ways of doing things). In addition, people are more committed to figuring out and implementing a solution to a problem if they are involved in the problem solving.
Problems are normal. Problems occur in every organization. In excellent companies people constantly work on solving problems as they occur. Problems are opportunities to make things better and should be viewed as such.
Be hard on the problem and soft on the people involved. When working on a problem, we should focus on solving the problem, not on whose fault the problem is. We should avoid personalizing the problem and blaming others.
People should address the problems in their own areas. Everyone has problems associated with their work area, and they should take ownership for trying to solve these problems instead of waiting for their supervisors or another team to tell them what to do.
Problem Solving Model
The Problem-Solving Model is shown here. It is used when a project team is solving a basic problem. These ten steps are effective with most of the problems the team will encounter. Each step is discussed here, and end products for step completion are specified as check points for team progress.
Step 1: Define the Problem.
Step 1 is a critical step; it determines the overall focus of the project. In this step, the team defines the problem as concretely and specifically as possible. Five SPC tools are helpful in defining the problem: brainstorming the problem's characteristics, creating an affinity diagram, using a Pareto chart, creating an initial Process Flow Diagram of the present process, and Control Chart data. The process flow diagram (PFD) will help the team identify "start to finish" how the present process normally works. Often the PFD can dramatically help define the problem. After the problem is well defined, Step 2 helps the team measure the extent of the problem.
End Product = A clear definition of the problem to be studied, including measurable evidence that the problem exists.
Step 2: Measure the Problem.
Baseline data are collected on the present process if they do not already exist. This permits measurement of the current level of performance so future gains can be subsequently measured. The team needs to make a decision on how to collect the present baseline data. In general, if data are collected daily, the time period should be a month. This way a standard control chart can be used. If data are collected weekly or once a month, baseline data will have only three or four points. Data collected less than once a month are of limited use; in such cases, historical data, if available, should be used. At this stage, the team must have measurable evidence that the problem exists. Opinions and anecdotes are a sound place to start, but eventually there needs to be concrete proof that there really is a problem.
End Product = A graph or chart with present baseline or historical data on how the process works; a collection of the present job instructions, job descriptions, and SOPs/JWIs (standard operating procedures and job work instructions).
Step 3: Set the Goal.
Goals provide vision and direction and help the team make choices and know which path to take. Be sure to state your goal(s) in terms that are measurable. This way, the team can evaluate its progress toward the goal. As the team imagines the goal, it will identify benefits of achieving the solution to the problem. This inspires a higher commitment and support from all.
End Product = A goal statement that includes the what, when, where, why, who and how of the ideal solved problem situation.
Step 4: Determine Root Causes.
In Step 4 the team studies why the process is working the way it is. If a control chart was developed in Step 2, determine whether the process is "in control" or "out of control." If the process is "out of control," the team should pinpoint the special causes and move to Step 5. If the process is "in control," the team will need to use tools such as cause and effect analysis (fishbones), scatter plots and experimental design formats to identify root causes currently in the system producing common cause variation.
End Product = A list of most probable root causes of the problem (common and special cause variation); selection by team of the primary root cause of the problem to be eliminated.
Step 5: Select Best Strategy.
The purpose of Step 5 is to select the strategy that best solves the problem. From the list of causes generated in Step 4, the team should brainstorm and strategically plan solution strategies. Fishbone diagrams and benchmarking can be helpful for this step. Then the team must reach consensus on the best possible strategy to solve the problem. This strategy should have the highest likelihood of success.
End Product = A well defined strategy to solve the problem is selected.
Step 6: Implement Strategy.
An Action Plan is developed by team. This includes who will do what by when to implement the solution. The team sees to it that the Action Plan developed is carried out and documented.
End Product = The Action Plan is implemented.
Step 7: Evaluate Results.
In Step 7 the team evaluates how effective the solution has been. Data must be collected to determine if the implemented strategy did, in fact, improve the process being studied. Performance must be clearly measured and evaluated. The team needs to monitor control chart data where appropriate and assess improvement; the process flow diagram should be checked for appropriate SOPs and JWIs. Additional feedback strategies such as histograms, process FMEAs, customer surveys and informal polls may also prove useful. What are the "customer" reactions (internal customer feedback)? What has produced measurable results? What hard data are available? Do people perceive an improvement? How have results matched customer needs? If the process did not improve, the team needs to discover if the wrong root cause(s) was identified or if the wrong solution was utilized. In either case, return to the steps above, beginning with Step 4. If the process improves, but the results are disappointing, there may be other root causes affecting the process. Again, return to Step 4 to further examine additional root causes. When the problem is solved (i.e. the "loop closed"), the team proceeds to Step 8.
End Product = The problem is solved; results of the improvement are measured.
Step 8: Implement Appropriate Changes in the Process.
Step 8 develops an ongoing process to assure that the gains stay in place for the long term. Sometimes a problem is solved and then later resurfaces. This happens when a solution is determined, but a system or process to keep the problem solved has not been successfully adopted. Permanent changes need to be implemented. This means revising the existing procedures. The new improved process will need to be tracked over time; the process must be checked frequently to maintain improvement. This also helps everyone to stay aware of opportunities to continuously improve the process where the problem occurred.
End Product = A permanent change in the process, Quality Improvement, and people "closest to the job" monitoring the change.
Step 9: Continuous Improvement.
This step is staying committed to continuous improvement in terms of this model - to remain actively alert to the ways the improved process can be made even better. This step is a conscious decision to allow others to innovate and to point out "red beads" in the process which the team has worked hard to improve. All involved, particularly those closest to the job, need to be encouraged to give constructive feedback and adjustments. Internal audits will monitor some processes to ensure effectiveness.
End Product = Commitment to continuous improvement.
Step 10: Celebrate.
This last step includes a recognition celebration and the disbanding of the team. Always take time for this maintenance function; people have achieved an important goal. They have earned this moment of recognition and closure.
End Product = Closure for the team members; disbanding of the team.
Fun: The Bookworm
Creativity is also the ability to look at the same thing as everyone else, but to see something different.
Let's take the challenge of the "life of a bookworm."
Each of the four volumes in the picture has the same number of pages and the width from the first to the last page of each volume is two inches. Each volume has two covers and each cover is one-sixth of an inch thick.
Our microscopic bookworm was hatched on page one of volume one. During his life he ate a straight hole across the bottom of the volumes. He ate all the way to the last page of volume four. The bookworm ate in a straight line, without zigzagging. The volumes are in English and are right-side up on a bookcase shelf.
Challenge: how many inches did the bookworm travel during his lifetime? ____________
We will give the answer in next month's newsletter.
Thanks so much for reading our publication. We hope you find it informative and useful. Happy charting and may the data always support your position.
Dr. Bill McNeese
BPI Consulting, LLC
Connect with Us
- << Return to Categories
- Affinity Diagrams
- Balancing People and Process
- But You Can't Measure What I Do!
- Data Collection
- Dr. Ishikawa’s Seven Quality Tools
- Just Plot the Data - It is So Simple!
- Kaizen and SPC
- Problem Solving Tools and M&M's
- Problem-Solving Model
- Process Analysis
- Process Flow Diagrams
- Process Management Model
- The Theory of Constraints
- Time and Muda
- When an Average Isn’t the Average
SPC Knowledge Base Sign-up
Click here to sign up for our FREE monthly publication, featuring SPC and other statistical topics, case studies and more!
SPC Around the World
SPC for Excel is used in over 60 countries internationally. Click here for a list of those countries.