“Here it comes, another lean tool that could not possibly work in the field.”

Whenever I try to introduce A-3 root cause problem solving to the field this is normally the response I get, right after some cursing and eye rolling. The thought of using a methodical approach to getting to the root cause of a problem while using a single sheet of paper to track a problem-solving event seems like way too much time and effort. But if I can get my teams to really evaluate the issues that occur on their job sites, they are normally dealing with the same problems over and over again. This is because our field is a hectic and fast paced environment, and the established culture lends itself to quick action decisions in order to deal with the next problem that is coming in the next few minutes. Field leadership is forced to firefight symptoms as they see them each day rather than spend time analyzing the problem and attacking the root cause, so the problem does not return.

Can we have a culture shift when it comes to dealing with problems in the field? We can if we introduce and practice an easy-to-follow problem solving methodology that can work on small or large problems in a relatively short period of time. If you search “A-3 Problem Solving Methodology” in Google, your search will yield hundreds of options. Most will have some common principles that I will explain below which I hope will help your organization develop a culture of root cause problem solvers.

Problem Statement

Any problem-solving event needs to start with a good problem statement. This may sound easy, but it trips up team after team because it requires reflection and succinct thinking. A problem statement should start out as a hypothesis that can be proven with data and not simply be a statement that already declares a solution. Start with terms like “It seems like…” or “It feels like…” or “I think we…” then come back and change the wording after proving your guess to be true.

Normally a team will declare something like “We need to choose another vendor for our material” as a good problem statement. This is a solution rather than a problem statement. What they should be declaring is “It feels like our vendor consistently delivers material late to this jobsite”. Now that is a hypothesis that can be proven with data. The team should analyze how often their vendor is late and what material is being delivered late, but this is where our teams in the field usually fail. If the team is not currently tracking the needed data to prove their hypothesis, they will want to skip to a knee jerk solution that may not solve the root cause of the problem because it is easier and quicker. After analyzing the data, they may see that the vendor is not late delivering all material, but only custom-made items. If so, the team can go back and change their problem statement to something like, “Our vendor has missed their due date on custom items by an average of 3.5 days over the past 6 months”. Now we have a problem statement that can be attacked with some direct countermeasures that will lead to improved performance.

Determine Root Cause

I cannot stress this enough; you cannot solve a process problem from your desk. Take your problem-solving team and go out and watch the process without influencing it or fixing it on the spot. Go see how the process is currently being performed even if it is painful to witness. Allow all the bad habits and incorrect execution to happen in front of your eyes as if you were not in front of the team. This will be especially hard if you are the process owner, and you trained the team. You will want to guide them and remind them of all that great training you did with them. Stop and let the mistakes happen. This is the only way to see the truth. Once your problem-solving team is done observing the current process, conduct a brainstorming event to determine the root cause of the problem.

You can use a cause-and-effect diagram, like a fish bone, or you can use a process map to find non-value steps, or you can use the collective experience of the group. However you get there, determine the one or two root causes of your problem. The team should focus on the one or two things that have the highest impact on the problem. If you try to fix too many things at once it will lead to dealing with only symptoms and not the root cause. This is usually why the same problems in the field keep occurring on a jobsite because they only deal with symptoms and not the root cause.

Develop Countermeasures…AND ACTUALLY DO THEM!

Now that your team has one or two root causes for your problem, what are you going to do about it? Countermeasures should be targeted directly at the root cause so the team can focus resources on directly solving the problem. Too often I see teams develop countermeasures that attack symptoms rather than the root cause. This leads to wasted effort and frustration because the problem will certainly come back if the root cause is not properly addressed. For example, if your team determines the root cause of a vendor delivering items late is because the job schedule keeps shifting, the countermeasures should be focused on preventing shifts in the schedule. But normally a team will try to get the vendor to make improvements to deliver material on time. This will lead to frustration because no matter how many changes the vendor makes, they will continue to fail if the job schedule is a moving target.

However, the most critical piece in developing countermeasures is where I see a majority of problem-solving events fail. Most teams do a great job of identifying what needs to be done to address the problem, but where they fail is actually taking the action. The teams will identify a countermeasure, assign a responsible person, and give a reasonable due date for the countermeasure to be completed. But normally most countermeasures never actually get completed and the team is unable to make progress at resolving the issue. The single most critical part of problem-solving is actually doing the countermeasures that have been assigned.

Don’t Forget to “Check”

Problem-solving events do not stop after countermeasures are in place. It is very common to see an initial spike in performance right after a problem-solving event. This is because of the “Hawthorne Effect''. People perform better when they are watched. Teams need to set an appropriate period where the problem will be checked to get a true sense of how well the countermeasures hold over time. Perhaps your team will check the process at 30 days, 60 days, and 90 days. You can expect a spike in performance in 30 days but do not be fooled by this. You may be experiencing a false sense of success. Check it again at 60 days and 90 days, that is when you will see the true lasting impact of your countermeasures. If you see the problem still lingering, make an adjustment and come back to check it again.

Do Not Be Afraid of the A3

An A3 is just a single sheet of paper that is used to track the steps of the problem-solving event. It forces the team to be methodical in their approach while focusing on the critical few countermeasures that will have the most impact on the root cause of the problem. Most A3s I see try to cover too much information. Here are my 5 basic questions that should be answered on every A3:

1. What problem are you trying to solve?

2. How do you know it is a problem?

3. So what? What is the problem costing you or what is the cost to fix it?

4. How will you measure success?

5. What are you going to do to fix the problem?

If your team cannot answer all of these questions, you probably do not need to conduct a problem-solving event. If you can answer all of these questions, follow a succinct problem-solving methodology and attack the root cause of your problem. With practice and a good facilitator, you can create a culture of problem solvers in the field.