Problem Solving 101

In the last column, I introduced a simple way to identify the areas of concern that will get everyone excited about making changes. The next step involves formulating a plan of attack to resolve the problems. Lean Six Sigma (LSS) offers a bevy of structured problem-solving tools. Here I will share with you one I learned many years ago and still practice with teams in different forms to this day―the Seven-Step team problem-solving process. For your next problem-solving effort, try these steps and see what happens:

Step #1: Select a team of the right people and define a problem statement.

Ideally, your team members are individuals who are knowledgeable and/or are directly involved with the problem in some way. After assembling the team, create a clear description of the problem with their participation. Problem statements are very important, as they frame the issue in clear terms so the team does not waste a lot of time zeroing in on the wrong things. Here are some tips for creating a good problem statement:

• The problem should be internal or external, customer-satisfaction focused and/or related company goal(s).
• The problem should be measurable and action-oriented and one from which we can expect success in a relatively short time.
• Prioritize problems where data are available for action if possible.

Step #2: Gather and analyze data to assist in analysis and problem solving.

• Gather and review all data available, relevant facts and anecdotal observations by the team about the process.
• Collect only as much data as you need. Often, sample data will be enough for the process.
• Break the data into a top-down ranking of frequency or impact―also called a Pareto chart or "80/20 rule chart."

Step #3: Determine the root cause(s) of the problem.

Related LSS tools I will not explain here are the 5-why, fishbone diagrams, brainstorming, and affinity diagramming techniques.

• Don’t assume you know the cause until you have all the facts. Try asking why until you reach a true cause. This may involve 3-8 repeated "whys" to get there.
• Interview as many people as possible in the time available to get as many viewpoints
  as possible.
• Use brainstorming. Remember, the quantity of ideas is more important than quality.
• Only after all ideas are understood, organize them and narrow the list to the most likely causes.

Step #4: Determine the best corrective and preventative actions to take that will both correct the problem and prevent recurrence.

• Make sure there is a written action plan with tasks, assignments and due dates.
• Prioritize actions that have high impact, are easy to implement and inexpensive.
• Ideas should lead to solutions that prevent recurrence of the problem.
• Get knowledgeable and affected people involved with the action selection process.
• Set a timeline and make sure there is clear accountability for each action.
• Verify top management support to proceed if the countermeasure is not clearly "in bounds"
  for the team.

Step #5: Determine actions required to prevent defect escapes.

• This step does not always apply–the need for containment until a solution is found. For example, if a mistake on an insurance form triggers the action, there may need to be a temporary inspection step added until a solution is found.

Step #6: Determine if other processes may be affected by the common causes for this problem and if the solutions should be standardized over multiple processes. 

• If the root cause for the problem is likely to affect other processes/services, then consider expanding containment and the scope of the interventions accordingly.

Step #7: Make sure the solution sticks. 

A major shortcoming of many problem-solving efforts is the failure to verify that the countermeasures remain effective over time. Document changes and ensures compliance with the new processes going forward. This may take the form of standardized visual work, standard operating procedures, new work instructions incorporating error proofing measures or other easy-to-understand guidelines for executing the process to prevent this problem from resurfacing. Set a date to verify if the problem has been permanently resolved. Finally, communicate the results of the solutions to the rest of the organization for "lessons learned" purposes and make sure the team is credited for results accomplished.

I would love to hear how things turn out if you try this process. For a copy of the full instruction and a sample form to use for problem-solving teams, or for a free web-based LSS leadership learning workshop, please e-mail me at rcrabtree@MetaOps.com.