An A3 problem-solving report should make the reasoning behind a change visible. What is happening now? What is causing the gap? Why would the proposed countermeasure help? A completed page is useful only when those connections make sense.
Use a shared workspace for the problem-solving discussion to put evidence and proposed changes side by side. This worked example follows a training team whose requests repeatedly move back from scheduling to intake because essential information is missing or unclear.
Start with the problem, not a completed form
The Lean Enterprise Institute describes A3 as more than a sheet of paper: it brings the current situation, analysis, countermeasures, responsibilities, and evidence of results into a shared problem-solving process.
Imagine a training team receiving requests from several departments. Intake records the request and passes it to scheduling, which assigns a trainer and agrees on a date. Some requests return to intake because scheduling cannot tell whether the proposed date is approved, which audience needs the session, or who can answer questions.
“We need a better request form” is already a solution. It may be right, but it does not describe the problem. A more useful opening is: scheduling cannot assign a trainer from some submitted requests because the audience, date status, or decision contact is unclear, causing additional handoffs.
Keep the scope narrow enough to observe: one training service, the handoff from intake to scheduling, and a defined period. “Fix communication across the organization” would give the A3 no practical boundary.
Show the current condition with a small request log
Draw the existing path: request received → intake prepares details → scheduling reviews → trainer assigned. Add a return arrow from scheduling to intake, then record why a request travels along it.
The sample log below shows the level of detail to capture. Replace these example records with observations from the scoped service before selecting a countermeasure.
| Example request | What scheduling receives | Reason for return | Question to investigate |
|---|---|---|---|
| R01 | A date is entered, but its approval status is absent. | Scheduling cannot tell whether to reserve a trainer. | Was the date known but not recorded, or still awaiting approval? |
| R02 | “Team training” appears without the intended audience. | The scheduler cannot select an appropriate trainer. | Did intake receive the audience information, and where was it stored? |
| R03 | The request is complete, but nobody is named to resolve a date conflict. | A clarification is sent back through intake. | Who can make the decision, and can scheduling contact them directly? |
Count requests and clarification events separately. One request sent back three times is one affected request and three return events. Combining the two can make the size of the problem look different depending on who prepares the report.
Also distinguish time waiting for a reply from time spent reviewing the request. A longer elapsed handoff does not necessarily mean the scheduler's work takes longer. The countermeasure for unclear information may be different from the one for an overloaded queue.
Separate causes from plausible stories
The team may quickly conclude that requesters are careless or that intake needs more training. Those explanations are too convenient without examining the work. Follow a returned request from its original submission through each copy, message, and handoff.
For R01, two causes are possible. The date may have been approved but lost when intake copied information into a scheduling message. Alternatively, no approval may exist yet, while a mandatory date field encourages someone to enter a placeholder. The same visible blank has different causes.
| Possible cause | Evidence that would support it | Why it changes the response |
|---|---|---|
| Required information is lost during transfer. | The source request contains the detail, but the scheduling version does not. | Preserve the information through the handoff instead of asking the requester again. |
| The request is passed on before a decision is made. | The date remains unapproved in the source record and conversations. | Make readiness and provisional status visible; adding another mandatory field may not solve it. |
| Intake and scheduling use different meanings of “ready.” | Both teams follow their current instructions, but those instructions require different information. | Agree on the handoff condition rather than assigning blame to either team. |
The Lean Enterprise Institute's guidance on A3 thinking emphasizes inquiry and a logical connection between facts, the problem, and countermeasures. In this case, observing the handoff matters more than filling every box with an answer during one meeting.
Choose a countermeasure that fits the cause
Suppose the handoff review shows that both teams use different readiness rules and that provisional dates are indistinguishable from confirmed ones. A targeted countermeasure would define the information needed for scheduling and make the date's status explicit.
For the trial, the handoff could include the intended audience, the requested date with a confirmed/provisional status, and the person authorized to resolve conflicts. Requests that are not ready would remain visibly in clarification rather than appearing in the same queue as ready work.
This does not mean rejecting every incomplete request. Some planning conversations legitimately begin before a date is settled. The change should let scheduling distinguish an early inquiry from a request ready for assignment, not force requesters to invent answers so they can submit a form.
Compare that proposal with a larger replacement system. A new system might still reproduce the same ambiguous readiness rule. Unless the evidence shows that the current tools prevent the necessary handoff, test the clearer rule before making software replacement the center of the A3.
Make the trial and measures specific
Write who will maintain the handoff rule, which requests enter the trial, when the teams will review the results, and what would make them change or stop it. Use the same service boundary and counting rules as the baseline.
One useful measure is the share of submitted requests returned for missing or ambiguous handoff information. Keep its numerator and denominator explicit: affected requests divided by all submitted requests in the scoped group and period. Track repeated return events separately, along with elapsed time to a scheduling decision.
Watch the other side of the handoff too. If fewer requests are returned only because intake now holds them indefinitely, the service may not have improved. Record the intake waiting time and any extra work required to prepare the request. Do not declare success from one local measure while the delay moves elsewhere.
Leave the result area blank until the trial produces observations. The A3 can say “trial proposed” and show the planned measures. A forecast belongs beside the proposed countermeasure, not in a box labeled “results.”
Lay out the A3 reasoning in Boardmix
Place the current condition on the left of a Boardmix canvas: the handoff path, the return arrow, and the request log. Put the cause analysis in the middle, with each possible explanation connected to its supporting or missing evidence. Place the selected countermeasure and trial plan on the right.
For this training example, connect the unclear date status to the proposed confirmed/provisional distinction. Connect the conflicting readiness rules to the shared handoff condition. Do not connect every cause to every change; that makes it impossible to see which proposal addresses which problem.
Open a Boardmix board and bring the actual intake and scheduling examples into the discussion. Use anonymized request details where necessary, and keep the person responsible for the A3 visible without implying that this person owns every team involved.
If the trial later shows that clear requests still wait because trainer availability is the constraint, keep that finding. It changes the next problem to investigate. The A3 should show why the team changed its understanding, not preserve the original explanation at the expense of the evidence.
