An A3 for a problem that keeps returning

Read the diagram as text

Describe the current condition, define the gap, investigate a possible cause, choose a countermeasure, plan a test and review the evidence. Keep observations distinct from hypotheses.

If the same release mistake returns after every reminder, writing a longer procedure may not help. An A3 gives the team a compact place to investigate what actually happened and agree on an experiment. The one-page discipline is useful because it makes omissions visible. It is also easy to misuse: a filled template can still contain no evidence.

Frame an observable gap

Start with the consequence and the scope. “People need to be more careful” is a judgment about people. “Three of the last ten illustrative releases needed a correction to the deployment configuration” describes something the team can investigate. Label invented training numbers as examples. For a real problem, include the period, item records and the accepted standard. Never write a precise baseline merely because the template asks for one.

Separate the evidence from the explanation

Use two small lists. The first contains observations with their sources: a timestamp, failed check, handoff or missing decision. The second contains hypotheses you still need to test. Ask a person doing the work to walk you through a recent example. An apparently simple mistake may involve an ambiguous instruction, unavailable environment or two conflicting versions of a configuration.

The Lean Enterprise Institute describes A3 as both a concise report and a process of dialogue around a concrete problem. Our worksheet is a starting structure for that dialogue; it is not a certification or an automated root-cause detector.

Choose a countermeasure with a mechanism

Write how the proposed change should affect the observed failure. In an illustrative release example, a pre-release configuration check could detect a mismatch before deployment. That is more testable than “improve communication.” Assign an owner who can arrange the test, and include the people affected by the change. A good idea that nobody can implement is not an action plan.

1. Describe one specific gap and the current process boundary.
2. Collect examples, including exceptions to the pattern.
3. Write a hypothesis and a way to challenge it.
4. Select a limited countermeasure with an owner and review date.
5. Observe the result and any new friction it creates.
6. Retain, modify or abandon the change with a recorded reason.

Agree on the check before the trial

Decide which future evidence would support the countermeasure and which would contradict it. For the configuration example, review both detected mismatches and corrections that escaped the check. Also ask how much time the check added and whether it became easy to bypass. A quiet week alone is weak evidence if there were no comparable releases.

Use a review date that matches the arrival of useful evidence. A fixed two-week cycle may be convenient, but a team releasing monthly might need a different observation window. Keep any claimed conclusion proportionate to the work actually observed.

A concise coaching conversation

• What did you see directly, and what did somebody tell you?
• Which explanation is still a guess?
• What observation would change your mind?
• Who needs to help before the test can run?
• What will you check for unintended consequences?

Use the local A3 worksheet to draft and export a plain-text version. It sends no worksheet data to a server. Read the original A3 Reports archive entry to see the earlier emphasis on concise communication.

A filled A3: distinguish the symptom from the condition

This invented service-team example is an editorial teaching case, not a project or result by Richard Durnall. Its purpose is to show how an A3 can expose an untested explanation before the team commits to a solution.

1. Define the observed gap and its boundary. In the example, four of ten handovers in one fictional week lack an acceptance owner. Record the ten observations before interpreting the cause.
2. Separate observation from hypothesis. “People do not care” is neither a useful observation nor an established cause. A testable alternative is that the handover form has no owner field and the meeting ends without assigning one.
3. Choose a small countermeasure and a disconfirming check. Trial an owner field in the next ten handovers. If the field is completed but acceptance still stalls, the explanation is incomplete.
4. Name a person to review the trial, its end date and what evidence would change the decision. Leave the result blank until the trial has happened; a planned experiment is not improvement already achieved.

Diagram text: Problem boundary: Fictional week; one team; 10 handovers; 4 without an acceptance owner; Current condition: Form has no owner field; assignment step not recorded; Hypothesis: An explicit assignment step may prevent unowned acceptance

Field	Example or check
Problem boundary	Fictional week; one team; 10 handovers; 4 without an acceptance owner
Current condition	Form has no owner field; assignment step not recorded
Hypothesis	An explicit assignment step may prevent unowned acceptance
Trial	Next 10 handovers: name owner and acceptance criterion before closing
Measures	Count missing owners and count stalled acceptances separately
Disconfirming observation	Owners are named but acceptance still stalls: inspect authority, capacity and criteria
Result and next decision	Not run. Review evidence before retaining or changing the trial.

Do not call “add a field” the root cause. It is a proposed countermeasure linked to one hypothesis. Preserve contradictory observations and ask the people doing the work whether the form represents the actual process. The downloadable card keeps problem, evidence, hypothesis, trial and result in separate boxes.

Download the working record ↓

Source context: Lean Enterprise Institute: A3 report