How to Run an After-Action Review for a Small Project

How do you run an after-action review?

Run an after-action review by comparing a small project's original aim with what actually happened, examining the evidence for the difference, and deciding what to repeat or change. Include the people who did the work, record uncertainty honestly, and finish with a named next action and review date. Use this lightweight approach for ordinary projects, not as a substitute for formal incident reporting or professional investigation.

A finished project leaves you with two things: an outcome and a story about the outcome. The review is a chance to check whether the story holds up before carrying it into the next attempt.

What is an after-action review for?

An after-action review, often shortened to AAR, is a structured discussion of completed work. Wharton Executive Education describes four central questions: intended results, actual results, reasons for the difference, and how to adapt or repeat success. Its guidance includes reviewing successful events, not only disappointing ones. Wharton's explanation provides the foundation; the small-project worksheet below is our editorial adaptation.

Choose a bounded event: producing a club handout, finishing a shared presentation or sending a volunteer newsletter. "How did Wednesday's handout production go?" gives you something observable. "Why are we always disorganized?" starts with a verdict and offers no clear finish.

This is different from a one-page decision memo, which records a choice before acting. The review looks backward to inform the next choice. Keep both documents if you have them: the earlier memo preserves what you believed before you knew the result.

What should you gather before the discussion?

Make a small evidence packet, not an archive of every message anyone sent. Our suggested packet has the original objective, the agreed deadline, the actual deliverable and the few records needed to reconstruct important handoffs.

For example, a document's version history may establish when a draft existed. A message may establish when somebody requested feedback. Neither automatically establishes whether the recipient read it, understood the request or had time to respond.

Label each note with its status:

• Recorded fact: supported by an identified document, message or other record.
• Recollection: somebody's account, not yet checked against a record.
• Interpretation: a proposed explanation of the facts.
• Unknown: something relevant the review cannot currently establish.

These labels are our practical note-taking convention, not a claim that an official AAR standard requires these exact categories.

If the objective was never written down, say so. Ask participants what they understood it to be and retain the differences. Do not turn today's preferred outcome into yesterday's supposedly agreed target. That would make the comparison look cleaner while making it less informative.

How do you give everyone room to contribute?

Agree who is facilitating, who is recording decisions and who is watching the time. Baruch College's Teaming resource suggests note-taking and timekeeping roles, broad participation and clarification when consensus is not possible. Its AAR guidance is useful preparation for a first shared review.

Our adaptation is to begin with a short individual writing period. Each participant writes one observation about the work and one question they want answered. Read those contributions before settling on an explanation.

A facilitator can redirect "you never told me" into "which instruction did each of us receive, and when?" This does not erase responsibility. It gives the group a checkable sequence before deciding what responsibility follows.

State who will see the notes before asking for candid comments. Atlassian's retrospective guidance explicitly recommends explaining how discussion information will be used and whether it will be shared beyond the group. Its meeting playbook also emphasizes improvement rather than blame. Do not promise anonymity or confidentiality that your process cannot provide.

What can a short review agenda look like?

Here is our suggested 30-minute agenda for a small, low-stakes project with records already available. It is an editorial starting point, not a validated duration or an institution's required timetable.

The allocations total 30 minutes. If participants are still disputing the basic timeline, stop trying to finish the explanation on schedule. Record what needs checking and arrange a continuation.

Do not use the final minutes to collect ten ambitious promises. One clearly specified change is a more manageable starting point for this small-project format. Larger work may justify several actions and a longer meeting.

What does a completed example look like?

The following book-club handout example is entirely fictional. Names, times and records are invented to demonstrate the worksheet, not to report a tested intervention or a real group's results.

Review question: How did the preparation and handoff of the discussion handout compare with the agreed plan?

Check the arithmetic before discussing causes. Six minus four is two. Wednesday at 18:00 to midnight is six hours; midnight to Thursday at 09:00 adds nine, giving 15 hours.

Those calculations describe a difference. They do not establish that the reviewer caused it. The records show an incomplete draft and a request for wording comments. The editor's expectation is an additional account, not proof that the reviewer accepted responsibility for writing.

In this fictional review, the reviewer explains that they understood their task as checking finished text. That supports the interpretation of a mismatched handoff. It still does not prove that clearer instructions alone would have produced six good prompts on time.

The group also identifies something to keep: numbering the prompts made the missing sections visible. Their next plan preserves that feature instead of replacing the whole process after one disappointing delivery.

How do you turn the explanation into an action?

Write the action as an observable change to the next attempt. "Communicate better" is an intention. It does not tell anyone what to do differently.

For the fictional handout, the action card could read:

• Change: Put a short completeness check above the next draft.
• Owner: The editor who prepares the draft.
• Deadline: Before requesting wording feedback on the next handout.
• Check: Count completed prompts and label any unfinished sections, with a named person responsible for each.
• Follow-up: At the next review, compare the request with the actual handoff and delivery record.

Atlassian recommends assigning owners and deadlines and placing actions in the team's working task system. The card above is our own small-project implementation, not its supplied template.

The owner needs to accept the action. Naming an absent volunteer does not create an agreement. If the change requires a tool, authority or time the owner lacks, record that dependency before declaring the action ready.

Keep the claim modest: the completeness check addresses one identified ambiguity. Whether it improves delivery remains to be observed. If the next project is very different, note that difference rather than presenting the outcome as a clean test.

What if the project went well or people disagree?

A successful outcome deserves a specific account too. In another fictional handout review, all six prompts might arrive on time because one person unexpectedly had a free afternoon. That is useful context, but not necessarily a repeatable process.

Ask what the next attempt can actually preserve: an agreed scope, an early draft, a clear feedback request. Keep a separate note for favorable circumstances you cannot arrange again.

When explanations differ, record them without manufacturing agreement. For instance: "The editor sees incomplete instructions as the main issue; the reviewer also identifies insufficient time for the requested work." Then name the evidence that could distinguish those accounts, such as when the request arrived and what work it contained.

If no useful evidence is available, leave the explanation unresolved. You can still agree to make the next request clearer without claiming to have discovered the single cause of the previous result.

When is the review actually finished?

Finish when the record tells the next person what happened, what remains uncertain and what to do next. A polished summary alone is not the follow-up.

The UK Government Service Manual describes retrospectives as regular opportunities to examine team working and assign actions, with the aim of completing those actions before the next retrospective. Its agile delivery guidance supports that continuing cycle.

For this small-project format, put the action where the next project will be planned. At the next review, ask whether it was attempted, what the record shows and whether it should continue. A missed action is also information: distinguish forgetting it from discovering that it was impractical.

If the next step is an individual, reversible routine change rather than shared project work, use the separate two-week personal experiment guide. More planning tools belong in Clear Decisions.

The useful final sentence is concrete: "Before the next feedback request, the editor will mark every unfinished section and confirm who will complete it." That is enough to make the next attempt different without pretending the last one explained everything.

Sources

• Wharton Executive Education: learning through after-action reviews — the four-question structure and reviewing successful as well as unsuccessful work.
• Baruch College Teaming: After Action Review — participation, facilitation roles and handling unresolved agreement.
• Atlassian Team Playbook: retrospectives — discussion expectations and accountable action items.
• GOV.UK Service Manual: agile tools and techniques — recurring retrospectives and follow-through.