What is it?

An After Action Review is a structured debrief where a team reviews what just happened by comparing what was supposed to happen with what actually happened, then works out why there was a gap and what to do about it. The group answers four questions in order: What did we intend? What occurred? Why? What do we do next? It is short, focused, and led by the team itself. The method strips away blame and politics and forces a group to look at their own performance with honesty. When done well, it turns every project, event, or initiative into a learning opportunity.

Also Known As

• AAR
• Post-Action Review

When to Use It

• Immediately after a completed project, event, sprint, or initiative while the experience is still fresh
• After a significant milestone within a longer project, to capture learning before moving to the next phase
• Following both successes and failures. AARs are not just for when things go wrong; understanding why something worked is equally valuable.
• When a team keeps repeating the same mistakes and needs a structured way to break the cycle
• After a crisis, incident, or unexpected disruption, once the immediate response is over
• As a regular practice at the end of recurring events such as quarterly planning cycles, product launches, or client engagements
• When onboarding new team members who need to understand how and why the team operates the way it does

When NOT to Use It

• In the middle of an active crisis. The AAR is a reflection tool, not a real-time problem-solving method. Finish the action first.
• When the goal is to assign blame or hold individuals accountable for mistakes. The AAR only works when people feel safe to speak honestly. If there is a disciplinary agenda, use a different process.
• When the team has no shared experience to review. An AAR requires that participants were actually involved in the event. Observers or stakeholders who were not part of the action should not lead or dominate the review.
• When too much time has passed since the event. Memory fades fast. An AAR conducted weeks later will produce vague generalisations rather than specific, actionable learning.
• When leadership is not willing to hear honest feedback. If senior leaders will shut down criticism or override the team's conclusions, the AAR will backfire and erode trust.
• For ongoing, slow-burn issues with no clear start and end point. The AAR needs a defined event or time period to review.

The After Action Review was developed by the United States Army in the mid-1970s, originally designed to capture lessons from simulated battles at the National Training Centers. Military historian S.L.A. Marshall pioneered an earlier version of the method during World War II, conducting group interviews with soldiers immediately after combat. The Army formalised the AAR as doctrine in 1993 with Training Circular 25-20, "A Leader's Guide to After-Action Reviews." Since then, the method has been widely adopted in healthcare, business, emergency response, and project management as one of the most effective organisational learning tools available.

What You Need

Group size: 4-15 people (the team who did the work). Larger groups can be split into sub-teams reviewing their own areas, then brought together for a combined session.

Time required:

• 20 minutes for a quick informal AAR
• 45-90 minutes for a formal review of a significant project or event
• Up to half a day for complex, multi-phase initiatives.

Space:

• A room where the team can sit facing each other, ideally in a circle or U-shape
• A wall or whiteboard visible to all participants for capturing notes
• Private space where the conversation will not be overheard by people outside the team

Materials:

• Flip chart paper or a large whiteboard
• Markers in at least two colours
• Sticky notes (optional, useful for collecting individual input before group discussion)
• A timer
• A printed or projected copy of the original plan, objectives, or success criteria for reference
• A template or pre-drawn four-column chart labelled: Intended, Actual, Why, Next Steps

The Process

Setup

1. Schedule the AAR as close to the end of the event as possible. Within 24-48 hours is ideal. Longer than a week and the value drops sharply.
2. Invite everyone who was directly involved in the event or project. Leave out senior leaders who were not part of the execution unless they are genuinely willing to participate as equals.
3. Prepare a brief factual summary of what was planned: the original objectives, success criteria, timeline, and any key decisions made along the way. Have this visible in the room.
4. Set up the space with chairs in a circle or U-shape. No tables between people if possible. Post the four-column AAR template on the wall where everyone can see it.
5. Gather any relevant data: metrics, timelines, feedback, results. Hard evidence keeps the conversation grounded and prevents "I thought it went fine" from dominating.
6. If you are facilitating for the first time, rehearse the ground rules and your opening framing. The tone you set in the first two minutes determines the quality of the entire session.

Step 1: Set the Climate

Time: 5 minutes

Purpose: To create the conditions where people will speak honestly without fear of blame.

1. Welcome the group and explain the purpose: "We are here to learn from what just happened, not to assign blame. This is about making the team better, not catching anyone out."
2. State the ground rules clearly:
   • "There is no rank in this room. Everyone's perspective matters equally."
   • "We focus on actions and decisions, not on individuals."
   • "What is said here stays here. This is not a report card for anyone's boss."
   • "Be honest. If something went wrong and you were part of it, say so. That takes courage and the team will respect it."
3. Explain the four questions the group will work through and the time allocated for each.
4. If the group has not done an AAR before, say: "This might feel uncomfortable at first. That is normal. The discomfort is where the learning lives."

Watch for: If senior leaders are present, watch for deference. Junior team members may hold back. You may need to explicitly invite their input: "You were closest to this. What did you see?"

Step 2: What Was Supposed to Happen?

Time: 5-10 minutes

Purpose: To establish a shared baseline of what the team intended to achieve before reviewing what actually occurred.

1. Ask the group: "What were we trying to do? What was the plan?"
2. Walk through the original objectives, success criteria, and key milestones. Reference the documentation you prepared.
3. Capture the key points on the flip chart under the "Intended" column.
4. Check for agreement: "Does this accurately reflect what we set out to do?"
5. If there were changes to the plan during the event, note those too. Plans evolve, and understanding when and why they changed is part of the learning.

Watch for: People sometimes rewrite history to match what actually happened. Keep the focus on what was genuinely planned at the outset, not what people now wish they had planned.

Step 3: What Actually Happened?

Time: 10-20 minutes

Purpose: To build a shared, factual picture of what occurred, using evidence rather than opinion.

1. Ask the group: "What actually happened? Walk me through the key events."
2. Work through the timeline chronologically. Use data, metrics, and specific examples wherever possible.
3. Capture the key points on the flip chart under the "Actual" column.
4. Encourage multiple perspectives. Different team members will have seen different things: "What did it look like from your end?"
5. Keep the conversation descriptive, not evaluative. You want facts at this stage, not judgements. If someone jumps to "and the reason it failed was...", gently redirect: "We will get to the why in a moment. Right now, let us just map out what happened."
6. Note both what went well and what did not. The tendency is to focus on problems, but understanding successes is equally important.

Watch for: Dominant voices can hijack this step. Make sure you hear from everyone, especially those who were closest to the action. Ask quiet members directly: "What did you observe?"

Step 4: Why Was There a Difference?

Time: 15-25 minutes

Purpose: To identify the root causes behind the gaps between plan and reality.

1. Ask the group: "Why did things turn out differently from what we planned? What caused the gaps?"
2. Work through each significant difference between the "Intended" and "Actual" columns. For each one, push for root causes rather than surface explanations.
3. Use follow-up questions to dig deeper:
   • "What led to that decision at that point?"
   • "What information did we have? What were we missing?"
   • "What assumptions turned out to be wrong?"
   • "Was this something within our control?"
4. Capture the analysis on the flip chart under the "Why" column.
5. Apply the same rigour to successes: "This went better than expected. Why? What did we do that made the difference?"
6. Resist the urge to jump to solutions. The diagnosis needs to be thorough before the prescription.

Watch for: This is where blame can creep in. If someone starts pointing fingers, redirect firmly: "Let us focus on what happened and why, not who. What was it about the process or the situation that led to this?"

Step 5: What Will We Do Next Time?

Time: 10-15 minutes

Purpose: To convert the analysis into specific, actionable commitments the team will carry forward.

1. Ask the group: "Based on what we have learned, what will we do differently next time? And what will we keep doing?"
2. For each root cause identified, work with the group to agree on a concrete action. Good actions are specific, owned by a named person, and have a timeframe.
3. Capture the actions on the flip chart under the "Next Steps" column. Split them into two categories:
   • Sustain: Things that worked well and should be continued or reinforced.
   • Improve: Things that need to change, with specific actions attached.
4. For each action, ask: "Who owns this? By when?"
5. Keep the actions realistic. Three to five strong commitments that actually get implemented are worth more than fifteen that get forgotten.

Watch for: Vague actions like "communicate better" or "plan earlier." Push for specifics: "What does communicate better look like in practice? What will you actually do?"

Closing

Time: 5 minutes

1. Read back the key actions and confirm ownership and timelines.
2. Thank the group for their honesty: "This kind of open reflection takes trust, and it is what makes a team get better."
3. Explain what happens next: who will write up the notes, where they will be stored, and when the team will check in on progress.
4. If appropriate, ask: "What was this AAR process like for you? Is there anything we should change about how we run these?"
5. Close cleanly. Do not let the session drift into general conversation or re-open settled topics.

Facilitator Guidance

What Makes This Work

The AAR works because it is built on three principles that most debrief methods miss. First, it separates observation from judgement by forcing the group to describe what happened before analysing why. This prevents the loudest voice from framing the narrative. Second, it flattens hierarchy. The method was designed so that a corporal's observations carry the same weight as a colonel's. When people believe their honesty will not be punished, they tell the truth. Third, it closes the loop by requiring specific actions with owners and deadlines, turning reflection into change rather than just conversation. The power of the AAR is not in any single session but in the rhythm of doing it repeatedly. Teams that run AARs consistently after every significant event build a culture where learning is automatic, not exceptional.

Common Pitfalls

• Blame creeps in: The single biggest failure mode. Once someone feels attacked, honesty shuts down and the rest of the session is performative. Intervene immediately if you hear finger-pointing. Redirect to process and decisions, not people. "Let us talk about what happened, not who did it."
• Only reviewing failures: Teams that only run AARs when things go wrong miss half the learning and train people to dread the process. Run AARs after successes too. Understanding what went right is just as valuable.
• Skipping the "what was supposed to happen" step: Without a clear baseline, the whole review becomes unfocused. People argue about whether something was a problem because they never agreed on what success looked like.
• Vague actions: "We should communicate more" is not an action. Push for specifics: who, what, when, how. If an action cannot be checked off as done, it is not specific enough.
• Waiting too long: Every day between the event and the AAR costs you accuracy. Schedule the AAR before the event starts, ideally within 24 hours of completion.
• The facilitator talks too much: The team should be speaking 75% of the time or more. Your job is to ask questions and hold the structure, not to provide the analysis.
• No follow-through: An AAR without follow-up is just a conversation. The actions must be tracked and reviewed. Build a check-in into the next team meeting or project kickoff.

Adaptations

• Quick AAR (15-20 minutes): Use just the four questions verbally with no flip charts. Ideal for end-of-day reviews during multi-day events, after meetings, or at the end of a sprint. Ask each question, capture two or three points, and move on.
• Virtual/remote delivery: Use a shared document or digital whiteboard with the four columns visible. Have each person type observations in the "Actual" column before discussing, which prevents groupthink. Mute and unmute to manage turn-taking. Allow extra time as virtual discussion moves more slowly.
• Large groups (15+): Split into sub-teams of 5-8, each reviewing their own area of responsibility using the four questions. Then bring the full group together for a combined session where each sub-team shares their top two or three findings and actions.
• Before Action Review (BAR): Run the AAR framework before an upcoming event by reviewing the AAR notes from the last similar event. Ask: "What did we learn last time? What will we do differently this time?" This closes the learning loop.
• Written AAR: For teams that struggle with verbal candour, have each person write answers to the four questions individually before the group discussion. Collect the written responses and use them to structure the conversation.
• Recurring rhythm: The most powerful adaptation is making AARs a habit. Schedule them automatically after every significant event, not as a special occasion but as standard practice. Over time, the team stops needing a facilitator and runs them independently.

Real-World Applications

Product launch debrief: A product team runs a 60-minute AAR the day after a major feature launch. They discover that the launch itself went smoothly, but the internal handoff between engineering and customer support was unclear, leading to a 48-hour gap in support readiness. The team assigns the engineering lead to create a launch checklist that includes a support briefing 72 hours before every future release.

Post-event review for a conference organiser: An events team conducts an AAR after a two-day industry conference. By walking through the timeline, they identify that the registration process worked better than expected (sustain) but that session transitions were consistently running 10 minutes late due to unclear signage (improve). They assign a team member to create a venue signage plan template for future events.

Quarterly sales review: A sales team uses a 30-minute AAR at the end of each quarter. In Q3, they compare their pipeline forecast with actual results and discover that deals over a certain size are consistently taking two weeks longer to close than predicted. The team adjusts their forecasting model and assigns a senior rep to shadow one large deal per quarter to identify where the delays occur.

NHS clinical team reflection: A hospital ward team runs a quick 20-minute AAR after a challenging weekend shift. They identify that the handover process between shifts was incomplete, resulting in a missed medication check. Rather than blaming individuals, they redesign the handover template to include a mandatory medication review section, reducing similar incidents in subsequent weeks.

Agency project retrospective: A design agency runs an AAR after delivering a client rebrand. The creative work received strong feedback, but the project ran three weeks over schedule. The AAR reveals that scope changes were agreed verbally in meetings but never updated in the project plan, causing confusion about deadlines. The team introduces a rule: no scope change is real until it is in the project management tool with an updated timeline.