# After-Action Review: [Event, exercise or operation name]

> An after-action review (AAR) is a guided, candid discussion held during or straight after an
> event, exercise or operation to establish what was supposed to happen, what actually happened,
> why, and what to sustain and improve. This template follows the four-step approach (plan,
> prepare, conduct, follow up) in US Army Training Circular TC 7-0.1, *After Action Reviews*
> (13 February 2025), and the After-Action Report/Improvement Plan (AAR/IP) structure in FEMA's
> Homeland Security Exercise and Evaluation Program (HSEEP) Doctrine (January 2020). Both are US
> government publications, cited and summarised in original words. Replace every `[bracketed]`
> value and every row marked *Example*. Worked examples use Pellmoor Transit Authority, a fictional
> bus operator, reviewing a winter-storm service disruption exercise.

<!--
Guidance: How to use this template
- An AAR is not a critique and does not grade success or failure. Say this at the start and
  hold to it: the aim is learning, so people must feel safe to describe their own mistakes.
- Hold the review as soon as possible, while memories are fresh. A short informal AAR on the day
  is worth more than a polished report a month later; a formal AAR can follow.
- Agree the facts (section 4) before discussing causes (section 6). Without a shared timeline the
  discussion turns into competing stories.
- Ask open questions ("What did you see when the alert went out?") rather than yes or no or
  "why didn't you" questions, and hear the most junior participants first.
- Common pitfall: a list of lessons with no owner. Every area for improvement ends in a corrective
  action with an owner and a date (section 9), and the actions are tracked to closure.
- For a software incident with customer impact, use the Postmortem (`dev/postmortem`); for a whole
  project, use Lessons learned (`project/lessons-learned`).
-->

## Document control

<!-- Guidance: One record per event. Status moves from Draft to Final once participants have validated the findings, and to Closed once every corrective action is done. -->

| Field | Value |
|---|---|
| Document ID | [AAR-YYYY-NNN] |
| Event | [Name, type (exercise, live operation, project milestone, event)] |
| Event date and location | YYYY-MM-DD, [location] |
| AAR date | YYYY-MM-DD |
| AAR type | [Informal / Formal] |
| Facilitator | [@facilitator] |
| Sponsor or senior leader | [@sponsor] |
| Status | [Draft / Final / Closed] |
| Classification | [Internal / Restricted] |

### Approvals

| Role | Name | Date |
|---|---|---|
| Sponsor | [@sponsor] | YYYY-MM-DD |
| Facilitator | [@facilitator] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@facilitator] | Draft from the review session |
| 1.0 | YYYY-MM-DD | [@facilitator] | Findings validated, improvement plan agreed |

## 1. The AAR process

<!-- Guidance: Choose informal or formal before the event. TC 7-0.1 notes that formal AARs need far more lead time, facilitators and aids; informal AARs are run by the team's own leaders at the work site. -->

```mermaid
flowchart LR
  P["1. Plan the AAR"] --> R["2. Prepare: collect data, build timeline"]
  R --> C["3. Conduct the review"]
  C --> F["4. Follow up: improvement plan"]
  F -->|"Lessons feed the next event"| P
```

| | Informal AAR | Formal AAR |
|---|---|---|
| Led by | The team's own leader | A trained facilitator, often from outside the team |
| Preparation | Little; held on site, straight after the event | Planned with the event; data, venue and aids prepared |
| Typical length | 15 to 45 minutes | Half a day or more |
| Output | Notes and a short action list | This full document |

## 2. Event summary and objectives

<!-- Guidance: This is "what was supposed to happen". Restate the objectives and the leader's intent exactly as they were set before the event, with measurable targets. -->

| ID | Objective | Target or standard |
|---|---|---|
| OBJ-1 *(Example)* | Notify customers of each route suspension | Public alert within 15 minutes of the suspension decision |
| OBJ-2 *(Example)* | Activate the operations coordination room | Room staffed within 60 minutes of the severe weather warning |
| OBJ-3 *(Example)* | Reassign drivers to the eight priority routes | All eight routes staffed within 2 hours of activation |
| [OBJ-N] | [objective] | [target] |

*Example intent:* keep the eight priority routes to hospitals and schools running, suspend other
routes early and safely, and tell customers before they reach a stop.

## 3. Participants and ground rules

<!-- Guidance: Include people from every level and function involved, plus observers or evaluators who collected data. Read the ground rules aloud. -->

| Name or group | Role in the event | Role in the AAR |
|---|---|---|
| [@name] | [role] | [Participant / Evaluator / Scribe / Facilitator] |

**Ground rules:** this is a professional discussion, not a critique; nobody has all the
information, whatever their rank; everyone takes part and nobody dominates; differing views are
welcome; we focus on what happened and how to improve, not on who to blame.

## 4. What happened

<!-- Guidance: Build the timeline from logs, recordings, evaluator notes and participants' own accounts before discussing causes. Record facts and times, not judgements. -->

| Time | Event | Source |
|---|---|---|
| 06:00 *(Example)* | Severe weather warning injected by exercise control | Exercise log |
| 06:45 *(Example)* | Operations coordination room staffed and active | Room sign-in sheet |
| 07:10 *(Example)* | Decision to suspend route 14 | Duty manager log |
| 07:48 *(Example)* | Customer alert for route 14 published | Alert system timestamp |
| 08:40 *(Example)* | Six of eight priority routes staffed | Dispatch system |
| 09:25 *(Example)* | Last two priority routes staffed | Dispatch system |
| [hh:mm] | [event] | [source] |

## 5. Planned versus actual

<!-- Guidance: One row per objective. Keep the rating factual: Met, Partly met or Not met against the target in section 2. -->

| Objective | Target | Actual | Rating |
|---|---|---|---|
| OBJ-1 *(Example)* | 15 minutes | 38 minutes (07:10 to 07:48) | Not met |
| OBJ-2 *(Example)* | 60 minutes | 45 minutes (06:00 to 06:45) | Met |
| OBJ-3 *(Example)* | 8 routes in 2 hours | 6 routes in 1 hour 55 minutes, all 8 in 2 hours 40 minutes | Partly met |
| [OBJ-N] | [target] | [actual] | [rating] |

## 6. Why it happened

<!-- Guidance: For each gap or success, ask open questions until you reach causes the team can act on: process, information, tools, training, staffing. Stop at causes, not at people. For deeper analysis use Root cause analysis (`business/root-cause-analysis`). -->

| Objective | Cause | Evidence |
|---|---|---|
| OBJ-1 *(Example)* | Alerts needed approval from the communications manager, who was not on the exercise roster; the duty manager waited 30 minutes for a reply | Duty manager log, alert system audit trail |
| OBJ-3 *(Example)* | The standby driver list was a spreadsheet on one supervisor's laptop and was not visible in dispatch | Participant accounts, dispatch notes |
| OBJ-2 *(Example)* | Room activation checklist was rehearsed last quarter and printed at the door | Evaluator notes |
| [OBJ-N] | [cause] | [evidence] |

## 7. Sustain: strengths

<!-- Guidance: Record what worked and why, so it is repeated on purpose. HSEEP describes strengths as actions that went especially well, positive impact on outcomes, or results better than expected. -->

| ID | Strength | Why it worked |
|---|---|---|
| S-01 *(Example)* | Coordination room active 15 minutes ahead of target | Recent rehearsal and a printed checklist |
| [S-NN] | [strength] | [reason] |

## 8. Improve: areas for improvement

<!-- Guidance: Write each observation as the issue, a short analysis, and its impact, as HSEEP recommends. Keep it brief and factual. -->

| ID | Issue | Analysis | Impact |
|---|---|---|---|
| AFI-01 *(Example)* | Customer alerts delayed by single-person approval | No delegate named for the approval step | Customers waited at suspended stops in freezing weather |
| AFI-02 *(Example)* | Standby driver list not visible in dispatch | List held offline by one supervisor | Two priority routes started 40 minutes late |
| [AFI-NN] | [issue] | [analysis] | [impact] |

## 9. Improvement plan

<!-- Guidance: Each action is specific, measurable, achievable, relevant and time-bound (SMART), with one owner. Agree the plan with the people who will do the work, then track it until closed. -->

| Action ID | Linked to | Corrective action | Owner | Due | Status |
|---|---|---|---|---|---|
| IP-01 *(Example)* | AFI-01 | Name two delegates who can approve service alerts and pre-approve wording for route suspensions | [@comms-manager] | YYYY-MM-DD | [Open / Done] |
| IP-02 *(Example)* | AFI-02 | Move the standby driver list into the dispatch system and test it in the next drill | [@dispatch-lead] | YYYY-MM-DD | [Open / Done] |
| IP-03 *(Example)* | S-01 | Keep the quarterly room activation rehearsal in the training calendar | [@ops-manager] | YYYY-MM-DD | [Open / Done] |
| [IP-NN] | [AFI or S ID] | [action] | [@owner] | YYYY-MM-DD | [status] |

## 10. Follow-up and sharing

<!-- Guidance: TC 7-0.1 treats follow-up as a step in its own right. Close the loop by testing the fix in the next event. -->

- [ ] Draft shared with participants for validation within [5] working days.
- [ ] Improvement plan actions added to the team's tracker with the same IDs.
- [ ] Progress reviewed at [meeting or date] by [@sponsor].
- [ ] Each corrective action tested in the next exercise or event, and the result recorded.
- [ ] Lessons shared with [other teams or sites] in a form that names no individuals.

## 11. References

<!-- Guidance: Link the exercise plan, logs and evaluator notes this review draws on. -->

- [Event or exercise plan, link]
- [Logs, recordings and evaluator notes, link]
- US Army TC 7-0.1, *After Action Reviews*, 13 February 2025:
  https://armypubs.army.mil/ProductMaps/PubForm/Details.aspx?PUB_ID=1030481
- FEMA, HSEEP Doctrine (January 2020) and HSEEP resources:
  https://www.fema.gov/emergency-managers/national-preparedness/exercises/hseep

## Standard and licence note

Based on public US government guidance: Department of the Army TC 7-0.1, *After Action Reviews*
(13 February 2025, approved for public release), which describes the plan, prepare, conduct and
follow-up steps, formal and informal AARs, and the review of what was supposed to happen, what
happened, why, and how to sustain and improve; and FEMA's Homeland Security Exercise and
Evaluation Program Doctrine (January 2020), which describes the AAR/IP, strengths, areas for
improvement and corrective actions. The earlier and widely cited Army guide, TC 25-20, *A Leader's
Guide to After-Action Reviews* (1993), does not appear on the Army's current list of training
circulars as checked on 2026-10-30. The text of this template is original and summarises these
sources; check the current versions on the official sites. Template licence: MIT.