Problem solving is critical for any business

Does your company have a problem solving process, like PDCA or 8-D?

If so, do people use it? How do you know?

Simple, ask for documentation. If an employee or improvement team is really working on a problem, and they aren't writing down or documenting what you're doing, then how well are they following the process? If the process is "in their head" then it's either a really simple problem, or they're probably missing some steps.

Example A3 Report

Here are some simple questions you can ask people in your company, to see if they are following the process and structure, if they can't provide documentation to prove it. 

What is the problem you are trying to solve?


Many teams cannot clearly articulate the problem, so they will struggle solving the problem if it is not well defined. This step can take a long time to complete, depending on the complexity of the problem. Teams often skip through this step quickly, so they can get to root cause right away and have some answers from management. Encourage them to take their time and make sure the problem statement is clear before moving on.

What step of the problem solving process are you in?


This will help you understand whether your employees are following the process or not, and help you understand how far along they are with this problem/issue. If they struggle answering the question, they may not be very knowledgeable about the process, or jumping around steps and working out of order. 

What data did you use to determine the root cause?


This will help you understand how well the root cause was investigated. If little to no data was used, then the solution will have much less chance of being successful, so the odds that they are actually addressing the right cause is slim to none. I find that teams that give up on collecting data and skip ahead to solutions are also less likely to adhere to the problem solving process.

Is your solution addressing the long term?


Many solutions address the immediate need, or contain the problem in the short term only, but they do not complete the entire 8-step process to prevent the problem from recurring. This happens often because after containment is in place, management stops asking about the issue, so the teams get pulled into the next "fire" instead of completing the problem solving process on the issue. This will be evident when you ask about different problems they've worked on, but they can't explain what actions were taken to prevent the problem from coming back. If the problem hasn't recurred, but no improvements were made, then don't be surprised when it does come back as next month's "fire".

There are many other questions you can ask, but these will give you a pretty good indication.

Finally, don't just ask the quality organization about problem solving around product failures. These departments may have contractual reasons to follow the process, as it probably gets submitted to the customer. Instead, talk to your HR department, your shipping department, Invoicing department, and even your Lean/Six Sigma organization (yes, we don't even follow our own recommendations all the time for our own issues). Problem solving is a company-wide process that everyone should be using on their top problems.

Prevention not as tough as it seems

Often times, we ask our clients what their proactive or preventative activity is. Most of the time, we get a blank stare. Others provide a list of risks, but no real activity geared towards mitigating those risks.

In the past, we would push the use of Process Failure Modes and Effects Analysis (PFMEA) as a method to achieve a prevention or risk mitigation plan. PFMEA is an excellent tool for doing just that, in addition to tying those risks in with the current issues, to figure out what is most important to be worked on. You can learn more about PFMEA's through our training material.

However, we are taking a step back, instead of jumping right into an FMEA approach. There are easier steps that should be taken first.

First, gather up the stakeholders, customers, and process experts, and facilitate a group discussion on what things could potentially cause problems in the near future. This is essentially a brainstorming exercise. If you get stuck, you could look to the Cause and Effect Diagram approach, and talk about the People, Machines, Processes, Environment, and Materials, and how they can bring about new problems. Once a list of risks are generated, the team should try and informally rank them, and develop an action plan for the top 1-3 issues only. Any more than 3, and you shouldn't be surprised when nothing gets done. Another rule of thumb we like to hold to: no more than one action per person at a time. Again, any more than that, and your asking for those items to be deprioritized, so that nothing gets completed.

After the list of risks are identified, the group should look at the list, and decide if they covered most of the risks or not. If they feel they did, and the list is manageable, then setting up a regular cadence to review these items is probably sufficient. If the team feels that there are other risks out there, then it may require additional sessions. Here is where the FMEA approach can help. It is an effective tool because it walks systematically through the process under evaluation, and forces the team to review the ways each process can fail to meet its intended output. This makes it less likely that an issue will "slip through the cracks". Again, after the list is expanded to include these additional risks, the list can be re-prioritized (this time more formally using Nominal Group Techniques, multi-voting, etc).

Finally, if the list identifies many additional issues, and the team is having a hard time prioritizing the top risks, a formal PFMEA may be needed, to iron out the details, and provide a more objective assessment of which risks are the highest ones needing an action. This is also useful if the team feels the risks are not fully captured, and the formal FMEA approach would bring these risks to the surface.

Again, the key to all of this is to align the complexity of the process to the complexity of your risk assessment. If you have a simple process, a simple approach may be sufficient. If your process is complicated and risks are high, then a more formal risk assessment may be needed. We recommend starting small, and expanding as the list of risks expands and gets more complicated.

When you jump right into a formal FMEA event, and want to spend hours of a team's time and energy, it's often difficult to justify the need to go through that much detail of a process. However, when you start small, it's easier to later justify the need to dig deeper, and get more formal with your risk analysis, once the team sees how much risk is out there that is not being managed.

The key to success is that the risks are added into a regular review or cadence process, preferably the same place where the regular activities are being reviewed. For example, if you have a staff meeting, devote 5 minutes to risk actions. If you have a program review, add 2 slides to discuss risks and actions taken on those items. Maybe start by looking at your personal life. Do you own a house? What actions do you need to complete to prevent a major issue at home? Are you keeping up with your vehicle maintenance? Are you anticipating and planning for upcoming or suprise bills?

The only way you can move away from a "firefighting" mentality is to allocate some of your time working on actions that are proactive or preventative in nature, otherwise you will continue to react to everything that comes along. Discussing the risks, assigning actions, and reviewing those actions are the key steps to make that transition happen. Just get started doing something, then worry about whether it is the biggest risk later on...