//
you're reading...
business, culture, deming, improvement, leadership, lean, lean thinking, management, tps, transformation, Uncategorized

Where Problem-Solving Goes Wrong: Helping People Better Understand A3 Thinking

In a previous post, I presented the idea that problem-solving, although critically important to an organization’s success, is not given the focus it deserves.  As a result of this, few problems are addressed effectively, leading organizations to face the same issues again and again.

Just like learning tennis or golf, improving the ability to solve problems requires three basic elements: (1) the desire to learn; (2) an effective coach; and (3) a lot of practice. This post will focus on the second element, coaching, and how to identify areas in a problem-solving effort where coaching is needed.

Before digging in to specifics of how to identify the gaps in a problem-solving effort, it is important to note that I use the term “solve” for convenience only because one can never be certain that a problem is truly solved. The best anyone can do is develop and implement countermeasures that appear to address the current situation in a structured and fact-based way.

Toyota TBP

The Red Flags

The red flags of a problem-solving exercise are based on the Toyota Business Practice (TBP) 8-step problem-solving process (shown above) and uses the A3 to identify the coaching opportunities. Detailed explanation of the 8-steps is readily available on the internet and in numerous books on lean thinking, so I am going to focus more on helping a person or team understand where the effort could be improved.

Whenever someone asks for input on a problem-solving A3, I tend to look for the red flags or areas in each section where help is most commonly needed. The key is to help people understand that the process is about investigating, reflecting, and learning, not filling in the form. It is far too common, especially early in a person’s development, to force fit information into the boxes just to appease someone else and show that the process was followed. The coaching effort must help people realize that following each of the steps as intended will lead to learning and developing countermeasures that have a high likelihood of success. I also keep in mind that, although there is no “right” answer to addressing a problem, there are definitely wrong answers, i.e., those not based on facts and gemba visits. An effective A3 is easy to follow and clearly demonstrates that learning occurred between each step as the team zeroed in on the cause and countermeasures.

The figure below is a problem-solving A3 template with the red flags noted in each section. For additional descriptions of the potential problems listed, refer to the summaries of each step below the A3.

A3-Red Flags

Step One: Clarify the Problem

It is difficult to argue that one step in the process is more important than the others but, since each step builds on the previous step to develop the story, any problems with the first box greatly interfere with the rest of the effort. One of the most common issues that shows up in box one includes failure to show the importance of the problem by ignoring the connection with higher-level objectives. Another common problem is using a lot of text to define the problem rather than a simple description or numbers. There is generally an inverse relationship between the amount of text on an A3 and the quality of the effort.

Many people also tend to confuse a root cause with a problem statement. The problem is the basic issue that initiated the effort and is usually stated in terms of a lagging indicator, which must be clearly understood to get to the root cause.

Step Two: Breakdown the Problem

The breakdown of the problem is where the issue is dissected in order to better understand what happened and focus on the most important element to address. This is difficult for many people because of the desire to solve the entire problem rather than a smaller, more focused issue. It is important here to understand all the issues related to the problem so the highest priority can be addressed first. After the most important issue is solved, the team can return to the next most important issue, thereby chipping away at the problem.

Step Three: Set the Target

Since the information in each step builds on the previous one, there should be a logical connection between the breakdown and setting the target. It needs to be clear why the team selected the problem and target and it must be based on the information and analysis in step 2.

Step Four: Determine Root Cause

In this step, it is critical that the team starts with the problem exactly as written in box 3 to maintain the logical thread between steps and that the effort is based on facts and the knowledge of those closest to the relevant process.

Step Five: Select Countermeasure

The biggest problem in step 5 is listing a single versus multiple proposed countermeasures – often a clue that the team had the answer in mind when they started the effort. Truly following the process requires the team to reflect on the root cause when determining possible countermeasures. When this happens correctly, there are usually a couple alternatives from which to choose.

Also, the action plan should be related to implementing/testing the selected countermeasure. Often, the action plan hints at collecting more information to verify or determine the root cause rather than specific steps to address the root cause. If this is the case, the team needs to return to step 4 to better define the root cause.

Step Six: See Implement Countermeasure

There is often a lot of activity going on in most organizations, and people lose focus and interest in implementing the plan they developed. The team should have a metric somewhere showing the status of the countermeasure implementation. If they do not have a metric, it is very easy for other priorities to interfere with the implementation and the prior work done on the problem will be lost.

Step Seven: Monitor Results

The biggest issue with this step is a blank box on the A3, showing that the team lost interest in the effort.

Step Eight: Standardize Successful Processes

As with step 7, the team needs to find a way to standardize the countermeasures that successfully address the root cause. If they don’t do this, then the improvement has no chance of being sustained.

Advertisements

About Gregg Stocker

Gregg Stocker is a lean advisor for Hess Corporation. He possesses over 20 years experience in a variety of disciplines including operations, manufacturing, human resources, quality, and strategic planning, and has worked in manufacturing, service, and oil & gas industries. He has extensive international experience, including successfully leading an $65 million business in The Netherlands. He authored the book, “Avoiding the Corporate Death Spiral: Recognizing & Eliminating the Signs of Decline,” (Quality Press, 2006) and was a contributing author to "The Lean Handbook," (Quality Press, 2012). Gregg is a frequent speaker and recognized expert in business and performance improvement having been interviewed on television, radio, and in a number of newspaper and magazine articles including The New York Times, Washington Post, BusinessWeek, and InformationWeek. Gregg has implemented change in organizations ranging in size from $10 million to more than $100 billion. He is a team-oriented leader who achieves results by improving teamwork, focus, and communication throughout the organization.

Discussion

3 thoughts on “Where Problem-Solving Goes Wrong: Helping People Better Understand A3 Thinking

  1. I’ve been moving towards using this thinking outside of a “formal” A3.

    A number of lessons learned over the past year have moved me towards this.

    At my current employer, documentation of problem solving efforts are sorely lacking. This is a counterintuitive statement from saying that I’m moving towards A3 thinking without the structured form.

    I use the A3 to document a successful problem solving effort, or even an unsuccessful one. Sometimes priorities change and the problem isn’t worth working on…the A3 is great to help pick things back up and view the problem in light of current state.

    I’ve been approaching problems from a system view. This has been just shy of a revelation at my current employer. It seems to greatly enhance buy in to a problem and its potential causes and potential countermeasures.

    I start with a target condition we want to achieve. This usually gets me deer in headlights look. This question has never been asked apparently. When there is no consensus I can fall back on either industry specific data for something like machine run time; or we can usually derive a realistic target from management’s expectations; and sometimes the problem is so bad if we can just go a week, day, or shift without experiencing the problem it is a win.

    I later will document the target condition and current condition on the A3.

    I make simple documentation tasks that highlight where the problems are and where they are not. And also include technical evidence of such. This is the thinking behind breaking down the problem. This can take several cycles in this business. Sometimes months.

    The hard part starts—multiple observable problems. Which one do we pick? This is a real battle in a continuous processing atmosphere. The answer is usually “all of them”.

    Sometimes I win this battle, sometimes I don’t. Sometimes although there are multiple problems causing the missed target, one is contributing much more than the other. If you’ve broken the problem down good enough then this is usually apparent.

    I can usually get folks to limit the problems to no more than 2-3. I can get buy in by indicating spending a bunch of company cash on all 3 problems when 2 of them may not be contributing is a career limiting endeavor. I usually explain that we are confounded.

    Then the in depth RCA process starts. Why is the gearbox failing? We get the issue down to a technical root cause.

    We develop an array of potential countermeasures based on cost and probability of success.

    By this point I have documented the A3 “behind the scenes”.

    We present findings to management and I will either parse the A3 into a powerpoint or simply do handouts.

    We then get a direction and move on implementation and an agreed update schedule.

    I then insist that the update isn’t about just completion of a countermeasure but results. This usually gets a great response from management.

    In the early stages of developing other’s thinking, I find it easier to walk them through the process and document things in the background.

    Management likes the A3 because 1) it isn’t powerpoint 2) it shows a concerted effort in solving the problem and not what “such and such” said the problem is. 3) easy to follow along 4) has follow up results as part of the process. 5) shows discipline 6) cost effective way of understanding problems and solving them instead of throwing money at it.

    My lesson learned is that in starting out in using this thinking, keeping the A3 in your back pocket is helpful. You can’t walk into a room and say “we are gonna fill out this form, and the problem will be solved”.

    You have to first be a good practioner of this method. You also have to approach problems from a systems perspective. Lastly, approach problem solving as an experiment.

    When folks see the good results the buy in will be automatic.

    Like

    Posted by Kyle | January 20, 2019, 11:27 am
    • Hi Kyle,

      Thanks for the response – it’s been awhile. You make a lot of good points. If the company is not using A3s or it’s not clearly supported by management, it’s best to attempt to drive A3 thinking without specifically referring to the form.

      I also believe that 8-step problem-solving is very difficult to learn to do well, but leads to much better thinking, learning, and countermeasures than other popular methods.

      Like

      Posted by Gregg Stocker | January 21, 2019, 6:08 pm

Trackbacks/Pingbacks

  1. Pingback: Where Problem-Solving Goes Wrong | Gregg Stocker | Lessons in Lean - Michel Baudin's Blog - November 7, 2018

Leave a Reply to Kyle Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 89 other followers

Advertisements
%d bloggers like this: