Table of Contents
It seems to me most people instinctually solve problems in their organisations the wrong way. They see a problem, immediately jump to the first solution that comes to mind, and write a memo to persuade an authority of the merits of their recommended solution. They write memos that have a hidden agenda.
Their heart is in the right place, but the process they follow leads to politicised, ill-considered solutions to unimportant problems, that are hard to implement because nobody understands the reasoning behind it. Instead, we ought to
- think about whether it’s a problem at all1 Chesterton’s fence.;
- consider if now is really good timing for a solution;
- have an open mind as to what the actual solution should be;
- get a variety of perspectives on the problem; and
- set up a plan for how to handle both success and failure.
If the above happens, we get efficient, well-considered, stakeholder-anchored solutions to important problems. But it’s difficult – much more difficult.
The Toyota A3 process is designed to achieve the above. First, let’s look at the components of an A3 document, and then we can see why I like this process.
There are many variations on the disposition, and there’s no right or wrong. This is how I usually structure my A3-inspired documents. Remix and come up with a variation that makes sense to you. The important part is to fulfill the desirable points above.
The full document should not be longer than two normal pages2 Hence the name “A3”. A3 is the standard paper size that corresponds to two A4 papers concatenated. The A4 paper size, in turn, is similar to the U.S. “Letter” paper size., but don’t take that as an excuse to over-simplify. This is the material used to make important decisions, so all key considerations and complicated trade-offs should be presented.
Most of the work of producing an A3 document is often the first three sections (Problem, Target, Cause Analysis), but work on it never really stops: an A3 document is a living document. It starts being useful already in the very early draft stages, and the people affected by it collaboratively update it throughout the lifetime of the proposed change.
In the first section, briefly describe the problem. Note that I use the word “problem” in the Toyota sense here. Here’s how to describe a problem exhaustively:
- Start by describing the standard condition; what are things supposed to be like normally? State it from the customer’s point of view.
- Then describe the current condition. Since we think there is a problem, the current condition must be deviating from the standard condition. Point out the gap between the current condition and the standard condition.
- Explain how important it is to solve this problem, and why specifically now is good timing for it.
It’s easy to go into both judgment and solutions here. Don’t! Just describe, as objectively as possible, the gap between standard condition and current condition. A lot of times when someone thinks there is a problem, it’s because they don’t fully understand what the standard condition or current condition is. By explicitly writing them out, we can correct a lot of misunderstandings early in the process.
The word “standard” should be interpreted broadly. If we want to enact an improvement, then it’s likely we think the old “standard” (if it even exists) is insufficient, so “standard” in our A3 document would refer to our improved standard.3 E.g. if we think our website loads too slowly, we can describe the problem as “The average page load time ought to be less than 0.8 seconds. The current average page load time is 1.7 seconds. This is 210 % of the standard.” The 0.8 second ceiling then becomes the new standard for the purpose of the A3 document. But we should be clear on whether we are referring to an existing standard or proposing a new one! “Get back to where we ought to be” and “we ought to be better than we are currently aiming for” are two different types of improvement.
It is important to state the standard condition from the customer’s point of view. Focusing on the job-to-be-done makes it easier to avoid solutions masquerading as problems.4 E.g. If we run a taxi company, we might think the problem is that our car fleet consumes too much fuel. The actual problem, from the customer point of view, would be that riding with our company is too expensive. Taking a wide perspective on the problem is helpful to generate solutions that would otherwise be missed.
As with any document, think of your target audience. How much you need to explain the problem depends on who is going to read your document. At the same time, keep in mind that A3 documents usually turn out to be more widely useful over a longer time period than many other types of documents.
This is where we state what needs to change, in terms of outcomes, not methods. We should also write by when we expect certain things to happen. Think “specific, measurable, realistic, and time-bound”.5 For the website example, it could be as simple as “During the next six months we should reduce average page load time by 1.2 seconds.”
What I’m proposing here might seem a lot like a goal-setting exercise. If you have read my article on statistical process control, you may be surprised by that; don’t I equate goals with wishful thinking? Am I not strongly against that? Yes. When I speak of targets, I do it in the Allen Ward sense. Targets are un-ambitious and flexible; we should be fairly sure we’ll over-deliver on a target, and we should be willing to change to a different target if it seems meaningful, or trade off targets against each other.6 Lean Product and Process Development; Ward & Sobek; Lean Enterprises Institute, Inc.; 2014.
Targets are a way to characterise the direction we are going in, they are not something measure progress against. Targets are just as much wishful thinking as goals, but with targets we acknowledge that and don’t pretend otherwise.
In the previous two sections, it’s been all about the “what”. This section is where we start talking about the “why”.
- Why is the standard what it is? Ideally, the people who decided on the previous standard are still around and we can ask them. If we don’t know why the standard is what it is, we can speculate, but we should be honest about that. If we’re proposing an improvement, we need to explain why the standard should be what we are proposing. This needs to be backed up with some sort of evidence.
- Why is the current condition what it is? Was it always this way, or did it start to deviate from the standard recently?
- Since the target we are proposing is an improvement over the current condition7 Otherwise, why would we be proposing it?, then we need to answer why the target hasn’t achieved already by others. Were there obstacles that are no longer a problem, or are some of these obstacles still in the way of the standard condition? What are the potential objections to the target, and why do we think they are not valid?
This is a section where it really helps to start involving other people. We can show them the A3 draft we have so far, and ask them for input on the questions above. We write down in this sections the answers we have gathered.
When we write this section, we should try to think in terms of countermeasures, not solutions.
The difference is not obvious, but an example can help: Imagine we’re hiking on a trail with the intention of reaching our campsite before night, and sometimes we lose the trail and get lost in the wilderness and have to navigate back to the trail, while continuing to make forward progress to the campsite. A solution would be something that gets us back on the trail this one time. A countermeasure is something we put in place that prevents us from getting lost in the first place. Usually, a countermeasure will also help us find our way back to the trail.8 Countermeasures in this example could be things like looking at the map more often, keeping an eye on our cardinal direction, not getting distracted by the scenery, using a gps. In this example, the trail and forward progress to the campsite would be the standard condition, and deviations from that are problems. A countermeasure is more of a long-term ongoing improvement, in contrast to a solution which is more of a quick fix.
If we have not involved people by now, this is definitely the time to do it. To write this section, we show people the draft we have so far, and ask for suggestions on countermeasures to the obstacles preventing the standard condition today. We write all suggestions down in this section. If we get a small list, we can call a meeting to discuss the alternatives directly. If we get a long list, we can use something like dot voting to eliminate a good portion of the worst suggestions before discussion.
Once we know which countermeasures we want to enact, it can be meaningful to include a brief cost/benefit analysis for them in this section as well. There’s no point in doing cost/benefit analyses for all the countermeasures, since there’s likely a large number we won’t bother trying anyway.
We select one or more countermeasures to enact. We agree on who should do what, and by what date. This section will usually just be a table with those three columns: what, who, and when. That way, we can easily track progress toward improvement.
This is an important section! And we can start writing it even before the previous two sections.
Here is where we specify by what date we will verify that the enacted countermeasures have had the desired effect, and how we will measure that. If we are able to run the improvement as a small experiment, we will also write down here how we can roll it out on a broader scale if it was successful, or roll it back if it was unsuccessful.
After we have evaluated what effect the countermeasures had, we can include the data from those measurements in this section as well. This means when someone three years from now wonders “why are we doing this again?” they can look in this section and see for themselves what the documented improvements were.
You may want to follow up at multiple points in the future, to track the long-term effects of the countermeasures.
Why would we follow an A3 inspired process? At its core, it’s a structured problem solving approach:
- clearly define the problem,
- investigate why there is a problem,
- solicit solutions, and
- ensure accountability over execution.
However, there’s a little more to it. Here are some benefits of the A3 process:
- The A3 document is a written record of the thought process of the change advocate, so that anyone else can inspect it and find errors in it, including incorrect assumptions (a common source of errors!)
- It encourages involvement from others, reducing the risk of tunnel vision.
- It gives people sufficient context and detail to have useful opinions.
- It presents a fairly objective view on the problem, and doesn’t try to convince other people of one solution being the best one.
- It forces a plan into existence for evaluating proposed changes before the change itself is attempted.
- When the document is close to finished, it will have been seen by many people. There will be no surprise decisions to socialise – most people have already consented to the general idea and have been given a chance to opine on the countermeasures, This means implementing the change can go much faster.
I have found one drawback to A3-style documents: they are wholly incompatible with attention-deficit executives. If you have any of those, I would recommend using an A3 inspired process for coming up with countermeasures, and then translating it into a more traditional persuasive memo for final review. Or just bypassing the executives entirely, if you don’t strictly need their approval to execute. Attention-deficit executives don’t want to understand a problem and make a rational decision. They just want to be given marginally different alternatives so they can pretend they are in control and doing an important job. Throw them a bone if you have to, even at the cost of a little extra work for you.