Run an After-Action Review That Changes the Next Attempt

A team can discuss lessons learned after every project and still repeat the same problems. The discussion may be thoughtful, but without a clear connection to future work, the learning stays inside the meeting. An after-action review should explain what happened, identify the conditions that shaped it, and produce a small number of changes that someone will actually make. Its value appears in the next attempt, not in the length of the notes.

Choose a bounded piece of work to review. A launch, a difficult customer request, a delivery cycle, or a completed project provides enough detail for a useful conversation. Reviewing an entire year can be appropriate for strategy, but it often becomes too broad for operational learning. Hold the review while participants can still remember the sequence and have access to the relevant records. Fresh evidence is more useful than a polished story reconstructed months later.

Start with the intended outcome. What did the team expect to happen, and what assumptions supported that expectation? Establishing the original plan prevents people from judging every decision using information that became available only afterward. Then compare the actual result with that expectation. Include what went well, what went poorly, and what was simply different. A review limited to failures can miss practices worth repeating and conditions that helped the team succeed.

Build a shared sequence of events before debating causes. Identify important decisions, handoffs, delays, and changes in information. People often experienced different parts of the work and may not know what others were responding to. A simple timeline can reveal that a late request changed the task or that an unresolved question traveled through several teams. This is more useful than beginning with broad conclusions about communication or accountability that nobody can test.

Ask what made the observed behavior reasonable at the time. An employee may have skipped a step because the instructions conflicted, prioritized the wrong request because ownership was unclear, or delayed a decision because authority was uncertain. Understanding those conditions does not remove responsibility. It helps the team choose a corrective action that addresses the cause. Telling everyone to be more careful rarely improves a process that repeatedly creates the same confusion.

Select a few changes that are specific enough to implement. Replace “improve communication” with a defined handoff, a review point, or a single owner for updates. Replace “plan better” with an explicit assumption check before commitments are made. Each action should have an owner and a point at which completion can be verified. If the review generates more actions than the team can realistically carry out, prioritize the ones most closely connected to the observed problem.

Decide how to tell whether the change helped. The evidence may be fewer returned requests, a clearer approval trail, or less time spent reconstructing decisions. It does not always require a formal measurement system. It does require an observable expectation. At the next comparable piece of work, examine whether the new practice was used and whether it produced the intended effect. If it did not, investigate the mismatch instead of declaring the lesson permanently learned.

Close the loop by sharing the relevant change with people who were not in the review but will use the process. Update the template, checklist, or working instruction where the behavior actually occurs. A lesson hidden in meeting notes will rarely influence the next project. Keep the review practical and respectful: understand the work, improve a condition, and verify the result. That is how a completed effort becomes a useful input to the next one.