A3 thinking: understand problems before trying to solve them

August 28, 2013February 8, 2021 by John Borwick In IT management, Process improvement 3 Comments

Seth Meyers: “How do we go about fixing it, specifically?”
Financial consultant: “Take it one step at a time: identify the problem, FIX IT, [and] repeat as necessary until it’s all fixed!”
-Saturday Night Live Weekend Update “Fix It” skit

The above “two-step problem solving process” is probably my favorite process. It’s so simple! (1) Identify the problem, and then (2) fix it! And yet very few people do step #1.

The next time you’re in a meeting to address a problem, pay attention to how much time is spent discussing or understanding the problem vs. how much time is spent on solutions. If your experience is typical, perhaps 30 seconds of an hour-long meeting about the problem will be spent understanding the problem.

When I started paying attention, I realized meeting after meeting that the problem would be briefly summarized–“our development environment doesn’t work with Macs” or “this intake process is too slow”–and then people would spend a huge amount of energy brainstorming or fleshing out solutions.

So what happens when we don’t understand the problem?

When the problem is not well-understood, any “solutions” only create new problems. In fact there’s no guarantee the solutions will address the problem at all!

Conversely, the more we understand the problem, the more likely we understand the root cause and can create countermeasures so the problem won’t recur. Understanding the current situation before implementing solutions is a pillar of Lean thinking. A tool called an “A3” is often supports this approach, which is why understanding the current situation before implementing solutions is often called “A3 thinking.”

One of my favorite management books is “Managing to Learn.” Its unusual format has two columns: the left column is what the employee is thinking, and the right column is what the manager is thinking. The manager is trying to get their employee to start thinking about problems more scientifically.

In fact, the manager’s primary goal is not to solve the problem but to teach their employee how to think about solving problems.

The employee starts out by jumping to conclusions–and then their manager asks them why the problem exists. This leads to several interactions where the employee slowly becomes the expert in the problem and understands there’s much more going on. The final set of countermeasures reflect input from the people in the process and the employee’s knowledge of the system.

Managing to Learn shows the employee’s draft A3 as they go. So what’s an A3?

The A3

Take a sheet of 11″x17″ paper. Fold it in half and then unfold it.

The left side is where you describe the problem. The right side is where you talk about what to do about it.

I introduce A3’s this way to underscore that there is not one correct A3 format. Depending on your situation, you may need to describe the problem or identify solutions in very different ways.

That said, it’s common for the “problem” side to include:

• Summary and Background (briefly, what’s going on?)
• “Current state” (what is known today? factual)
• Goal (specific goal/reason for the A3)
• Analysis (understanding of the root causes)

…and for the “what to do about it” side to include:

• Possible countermeasures
• Gantt chart
• Follow-up (when will we verify the problem has been addressed? how will we know?)

A3’s can be handwritten, or they can be written on a computer. They normally have titles, version numbers, the initials of the author, and the initials of the manager once the A3 has been finalized. They often include illustrations.

You shouldn’t reduce the font size on your A3: the goal is to communicate the problem and what to do about it quickly. The more you know, the harder this is–but as you learn you become the expert, and you know best how to distill the problem to its essence. When an A3 is done well, your CIO can understand the issue and your recommendation in about five minutes.

Please see the Lean Enterprise Institute’s “A3 Dojo” for templates and further information about A3’s.

When to use A3’s

Building an A3 can be quite time-intensive.

However, with A3 thinking you don’t build solutions until you understand the problem and can test your solutions. This can save a huge amount of energy that would otherwise have been spent guessing at solutions.

Also, the time spent on A3’s not only addresses the problem but builds a problem-solving capability. Employees working on A3’s are also getting better at analytical problem-solving.

A3’s should support departmental and organizational goals. The best book I’ve read on how to align A3’s with organizational goals is Toyota Kata.

A3’s need to be built and improved quickly. They are often used to focus a kaizen/process improvement event.

That said, A3 thinking can be used all the time. What’s the current situation? What’s the goal? How can we test solutions to know whether they actually address the problem?

A3 advice for IT staff

I am still relatively inexperienced myself in building A3’s.

I will say that I do not accept any A3 solution being the creation of a report. Reports take time to build and maintain. If your solution is to create a report, there is probably a bigger issue. Why is that report needed? What’s not happening that should be happening?

Also, A3’s will force technical people, who are used to black-and-white technical solutions, into more nuanced and perhaps uncomfortable non-technical issues. For example, here’s an example train of thought:

• the database server crashed because it had not been updated.
• It had not been updated because the project did not include applying the updates.
• The project didn’t include applying the updates because the project manager asked the project team how to minimize the time to implement.
• The project manager wanted to minimize the time to implement because they were told they would be fired if the project wasn’t delivered on time.

In this case, there may be a departmental incentive (on-time delivery) that is at odds with a larger goal (minimized total cost of ownership). Or, you could continue and ask why the schedule was set the way it was. Either way, you’re getting away from the technical issue (updates had not been applied) and into bigger, more challenging (but more fundamental) issues.

So, as you go, consider your organization’s problem-solving culture. You may need to set the scope of an investigation to what your team can control, for example, so you don’t get people spun up on political issues they can’t address.