Most teams only look back when something goes wrong. The Army looks back after everything.
What it is
The after-action review (AAR) was developed by the U.S. Army in the 1970s, and it's now used in many companies and hospitals. It's built on four questions:
- What was supposed to happen?
- What actually happened?
- Why was there a difference?
- What will we do the same, or differently, next time?
The rules matter as much as the questions. It's about the work, not blame. It happens soon, while memories are fresh. Everyone involved speaks, regardless of rank. And it's short.
Why people skipped it
Once a job is done, everyone moves on. Getting people together, even for fifteen minutes, feels like a luxury. And the answers to question 2 take effort to reconstruct.
How a bot does it
Question 2 is the hard one for people, and the easy one for a bot with records.
- Give the bot the plan and the records. The schedule, the spec, the RAID log, emails, files, the bot logs.
- Have it draft answers to questions 1 and 2 from those records. Plan versus actual, with dates.
- Have it list the differences for question 3, as questions, not conclusions.
- People spend fifteen minutes on questions 3 and 4. That's where the learning is.
- The bot writes the record and files lessons where they'll be found. See Lessons learned that actually get read.
The bot brief
Draft an after-action review for [project/job].
Inputs: plan/schedule [file], RAID log [file], emails and records [files].
Q1 What was supposed to happen: goals, dates, specs — cite the plan.
Q2 What actually happened: dates, results, events — cite records.
Q3 Differences: list each gap between Q1 and Q2 as a neutral question
("Why did tooling arrive 9 days late?"). Do not assign blame or guess causes.
Leave Q4 blank for the team.
After the meeting, given the team's notes [file]: write the final AAR and draft
lessons-learned entries (part/process/customer/supplier, what happened, cause, lesson).Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
Job: launch the bot-assisted quoting process.
| Plan | Actual | |
|---|---|---|
| Go-live | Oct 1 | Oct 15 |
| Quotes needing edits | Under 10% | 22% first two weeks |
| Pricing rules written | By Sept 10 | Sept 24 |
Questions for the team:
- Why did the pricing rules take two weeks longer?
- Why were 22% of quotes edited, and which kinds?
- What did we learn about testing on old quotes first?
The team spends its fifteen minutes on those three questions. Not on reconstructing the dates.
Where bots differ
The AAR depends on people being candid about what they saw. A bot can't supply what wasn't written down: the hallway conversation where everyone knew the date would slip. So the bot drafts the facts, and the people supply the story.
Keep the bot's draft neutral. A record that says "Jim was late" shuts down the conversation. A question that asks "Why did the rules take two more weeks?" opens it.
What this means for you
- Do an AAR after every project, not just the failures.
- Let a bot draft plan versus actual.
- Spend the meeting on "why" and "next time."
- File the lessons where the next team will find them.