After Action Review

Input: $ARGUMENTS

Overview

The After Action Review (AAR) is a structured debrief to learn from experience. It compares what was supposed to happen with what actually happened and extracts lessons for the future.

The US Army credits AARs with dramatically accelerating organizational learning and considers them one of their most important innovations.

Steps

Step 1: Set the Context

1. What was the event, project, or action being reviewed?
2. What was the timeframe?
3. Who was involved?
4. Do this SOON after the event (memory degrades rapidly)

Ground rules:

• No blame — focus on learning, not punishment
• Rank doesn’t matter — everyone’s observations are valid
• Honesty is mandatory — sanitized AARs are useless
• Specifics, not generalities — “the timeline slipped 2 weeks because X” not “things could have gone better”

Step 2: What Was Supposed to Happen?

1. What was the objective/goal?
2. What was the plan for achieving it?
3. What were the key milestones or checkpoints?
4. What was the expected timeline?
5. What were the success criteria?

Document this BEFORE discussing what actually happened (prevents hindsight distortion).

Step 3: What Actually Happened?

Walk through chronologically:

1. What happened at each stage?
2. What decisions were made and why?
3. What information was available at each decision point?
4. Where did reality diverge from the plan?
5. What was the actual outcome vs expected?

Key: Reconstruct what people KNEW at the time, not what we know NOW.

Step 4: Why Was There a Difference?

For each significant divergence between plan and reality:

Probe causes with:

• What decisions led to this outcome?
• What information was missing that would have changed the decision?
• What assumptions proved wrong?
• What went right that wasn’t planned? (Positive surprises matter too)
• What external factors contributed?

Step 5: What Did We Learn?

For each divergence, extract:

Sustains (things that worked — do MORE of these):

1. [What worked] — WHY it worked — HOW to replicate it

Improves (things that didn’t work — do DIFFERENTLY next time):

1. [What didn’t work] — WHY it didn’t — WHAT to do instead

Key insight: The most valuable lessons are usually about process, not content. Not “we should have chosen option B” but “we should have tested our assumption before committing.”

Step 6: What Will We Do Differently?

Convert lessons into specific, actionable changes:

Quality check on actions:

• Is it specific? (Not “communicate better” but “send weekly status email”)
• Is it actionable? (Someone can actually do it)
• Is it measurable? (You can tell if it happened)
• Does it address the root cause? (Not just the symptom)

Step 7: Report

AFTER ACTION REVIEW:
Event: [what was reviewed]
Date of event: [when]
Date of AAR: [when — should be close to event date]

PLANNED vs ACTUAL:
| Aspect | Planned | Actual | Divergence |
|--------|---------|--------|-----------|
| [aspect] | [plan] | [reality] | [gap] |

SUSTAINS (keep doing):
1. [what worked and why]

IMPROVES (change):
1. [what to do differently and why]

ACTION ITEMS:
| Action | Owner | Deadline | Measure |
|--------|-------|----------|---------|
| [action] | [who] | [when] | [indicator] |

KEY INSIGHT: [single most important lesson]

When to Use

• After completing a project or phase
• After a significant event (success or failure)
• Regularly during long-running projects
• After any learning opportunity
• → INVOKE: /fat (failure attribution) for deeper failure analysis
• → INVOKE: /ret (retrospective) for team-oriented learning
• → INVOKE: /ssr (session summary and review) for session-level review

Verification

• Conducted soon after the event
• “What was supposed to happen” documented BEFORE discussing actual
• Both positive and negative divergences analyzed
• Root causes identified (not just symptoms)
• Lessons are specific and actionable
• Action items have owners and deadlines