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.