The After Action Review (AAR) Toolkit

What is an AAR?
The AAR is a simple process used by a team to capture the lessons learned from past
successes and failures with the goal of improving future performance. It is an opportunity
for a team to reflect on a project, activity, event or task so that the next time, they can do
better.

Why would you conduct an AAR?

The AAR will not only make learning conscious within a team but it can also help build
trust amongst the team’s members.

Who participates in an AAR?

Participants of an AAR should include all members of the team. A facilitator should be
appointed to help create an open environment, promote discussion and draw out lessons
learned.

When do you conduct an AAR?

AARs should be carried out immediately while the team is still available and memories
are fresh. It is recommended that AARs should be incorporated at key points during a
project, activity, event or task in the early planning stage though they are often completed
at the end.

How long should an AAR take?

AARs can be powerful processes because of their simplicity. AARs can be conducted
almost anywhere and will vary in length. For example, a 15 minute AAR can be
conducted after a one-day workshop or a much longer meeting could be held to reflect on
the roll-out of a software application throughout a large organization.

How do you conduct an AAR?

Creating the right environment is critical. Participants unfamiliar with the AAR process
should be given information on what it is all about and why it is being done. Particular
emphasis should be made that AARs are used to promote learning and make it explicit
rather than on seeking out individuals to blame for past failures.

Asking the right questions: There are different ways to conduct AARs. Facilitators and
groups are encouraged to experiment with the process and find the right questions that
will work best with their group and the project, activity, event or task that is being
reviewed. They should also attempt to keep the process as simple as possible. As a
guideline, the following three sets of questions are suggested:
1. What was supposed to happen? What actually happened? Why were there
differences?
2. What worked? What didn’t? Why?
3. What would you do differently next time?
It is recommended that the facilitator posts the sets of questions on a flipchart or
whiteboard to be briefly reviewed prior to seeking out the answers.

1. What was supposed to happen? What actually happened? Why were there differences?
These questions are intended to create a shared understanding within the group on what
were the initial objectives of the project, activity, event or task and whether they were
achieved as planned. It is the role of the facilitator to encourage and promote discussion
around these questions.

Tip 1: The facilitator can ask the project manager or team leader to summarize the
objectives which are already posted on a flipchart or whiteboard. Others are then asked to
add their comments and other objectives if omitted.

Differences between reality and planned should be highlighted and insights into why
there were differences should be further explored.

2. What worked? What didn’t? Why?

This set of questions focuses on generating conversation about what worked and didn’t
work during the course of the project, activity, event or task.

First, the facilitator asks the team members what aspects of the project, activity, event or
task worked for them. Additional probing questions could include - “What did they like?”
or “What are things that would be worthwhile repeating?” The facilitator should
repeatedly follow up the team members’ responses with the question “Why?” to help
generate a better understanding of the root causes of the successes.

The facilitator then asks the team members what aspects of the project, activity, event or
task didn’t go so well or “What were aspects that they didn’t like”. Again, the facilitator
should use the “Why?” question to identify the root reasons or explanations as to why
things didn’t go so well.

Tip: If suggestions are not forthcoming, the facilitator could go around the room asking
each individual to express one thing that worked and one thing that didn’t. Alternatively,
if the participants have difficultly being open, you can also start with writing down
comments on ‘stickies’ and discuss them in the group afterwards.

3. What would you do differently next time?

This question is intended to help identify Specific Actionable Recommendations (SARs).
The facilitator asks the team members for crisp and clear, achievable and future-oriented
recommendations.

The facilitator should arrange in advance, for an individual to capture the quotes
connected to each SAR. They supplement the SAR and can be included in the
documentation of the AAR.

The following provides an example of two ways to write-up a SAR from an AAR
conducted following the deployment of a new software application across an
organization:

ý Poor SAR: More time is needed to better understand the application.

þ Better SAR: Purchase support documentation for the application as soon as
possible preferably once the selection has been made.

Captured Quote: “ If we could get our hands on the support documentation

earlier in the deployment, we could provide better training” - Gilles

Tip: The question could also be asked as “If you could do this all over again, what would
you do differently”.

Tip: Ask each individual to write down their response to the question “What mark out of
10 would you give this project, activity, event or task?”. Once everyone has written down
their response, get each individual to tell the team their mark and then respond to the
follow-up question “What would make it a 10?”.

Capturing Learning – An AAR TEMPLATE

Learning captured in an AAR can be documented and entered into a searchable file
format such as a database for later usage. The following template is provided as a guide.
Once the document is complete, make sure that it is circulated to all AAR participants for
their comments and feedback.

Name of Event:

Date of Event:

One or two sentences giving the

background / scope to the experience:

Key Player - individual(s) who called

the AAR:

Team Owner of the Learning:

Key Players/AAR Participants

AAR Facilitator:

Key Words: (maximum of 10 that

would enable future users to re-find
this learning)
Key Dates: (the years that the learning
was acquired)

Specific Actionable Quotes

Recommendations (SARs)

Sources
Collison, Chris, Parcell, Geoff, Learning to Fly (Milford: Capstone Publishing), 2001.

Darling, Marilyn J., Parry, Charles S., From Post-Mortem to Living Practice: An in-depth
study of the evolution of the After Action Review (Boston: Signet Consulting Group),
2001.

Whiffen, Paul, “Seizing Learning Opportunities at Tearfund,” Knowledge Management

Review, Nov./Dec., 2001
AARs at Work in an Organisation – A Case Study

Several staff at the Information Technology and Management Division (ITMD) at the
International Development Research Centre (IDRC) were interviewed to share their
thoughts and recommendations on the AAR process. Included below are some of their
comments.

Terry
Terry Gavin, Director of ITMD was first exposed to the AAR process at IDRC when he
took part in an IDRC Strategic Planning exercise. He became really excited about the
process particularly because of the way that the team was able to get a sense of what
worked, what didn’t work and what could be done differently in a very short period of
time. He was so impressed by the process that he decided that it would be worthwhile to
try it out on some of ITMD’s projects. He expected to get a collection of things that his
team could apply to future projects such as mistakes that would not made again as well as
things that worked well which could be done again. So far, the AAR has lived up to
Terry’s expectations.

Terry was surprised about how easy it was to get others interested and involved in the
AAR process. “People seem to like them and have stuck with them. I was amazed to see
a project plan from one of our technical staff include, as a final item on the plan, an
AAR”

After taking part in several AARs, Terry provides others with several
recommendations…

“The first thing that you have to do is be open minded about the process. It is something
new and different. Go with the flow – it works. You have to ensure that the group has a
sense of trust so that they can openly talk about the things that don’t work. You should
also use the AAR to review the things that did work and the things that didn’t work quite
so well. You can always learn.”

Hugh
Hugh Campbell managed the Windows XP project at ITMD which involved the design
and testing of a new corporate disk image based on Windows XP. The new images were
developed for deployment on all new desktops and laptops.

Although Hugh has not yet applied any specifics recommendations from the AAR, the
process has resulted in a few unexpected surprises…

“One surprise was the reception by the user community who were on the receiving end of
the project. The AAR process very evidently improved their confidence in the way ITMD
was doing their work. It also leveled off the understanding of the project among the
variety of people involved in the process. At the end of the process, we ended up sharing
a common view of the project.”
Hugh suggests that AARs be planned in advance at key milestones in the project. “For
projects on a similar scale, which affect an entire organization, AARs should be
scheduled 2-3 times throughout the project – at milestones rather than at the end of the
project. We used the AAR at the end of the project but there were atleast two other
opportunities throughout the project which they could have been used.”

Allen
Allen Sinfield has participated in the majority of AARs conducted at ITMD as the
Manager of the Infrastructure Support Unit. Allen recognized that ITMD would continue
to face the same issues if they continued to do things the same. AARs could help the team
identify the issues and as a result, change how they were doing business. Having now
done four AARs, ITMD is slowly beginning to see a consistent pattern especially around
the identification of project goals.

“After we had completed two AARs, it became clearer to us that ITMD had two types of
goals that needed to be identified and achieved – client goals and technical goals. This
surprised us because we thought we could put all of the goals together on one table.
Instead we found out that the project managers need to be the conduit between the two
types of goals rather than trying to mix them together.”

Although other staff interviewed did not think that ITMD faced any challenges in
introducing the AAR, Allen noticed some reluctance in the early stages although he was
quickly able to resolve a common issue that can often arise when introducing AARs…

“We had some difficulty in introducing the AARs. Staff who had a very specific role
initially questioned why the AAR was being conducted. There was the assumption that
something went wrong and we needed to figure out why. As a result, we needed to
clearly explain why we were doing an AAR – not to review the performance of a single
individual but to identify consistent successful practices and lessons learned that could be
used in for future projects”.

Louise
Louise Brennan is the project manager for the Microsoft Office Rollout Project at IDRC.
Close to the halfway point of the project, she conducted an AAR bringing together the
project team.

“In this particular project, we didn’t expect many surprises going into the AAR because
we were such a close, self-contained group working together on a daily basis. Whenever
we needed corrections we did them as we went along. But, the AAR gave us the
opportunity to reflect on what we could change and modify the next time. One of the
important things that came out of this AAR was that we recognized that we needed to do
another AAR once the project is complete because we hadn’t included any of the end
users in the review. It made us realize how important it was to include people external to
the project, in this case the end users, in the AAR because it will allow us the opportunity
to discover those unexpected surprises – those things that you aren’t necessarily aware of
during the project”.

Louise prescribes an approach that is positive. “AARs are about sharing as well. If you
are a team, you share in everything not just what went well but also what didn’t go well.”

After Action Review – IDRC NT/Eudora Rollout

Following the conversion to a new network operating system as well as the rollout of a
new corporate email system at IDRC, Terry called an AAR. The following
documentation sought to capture some of the key lessons learned from the implementing
team at ITMD and some of the users involved.

Name of Learning Event: NT/Eudora Rollout – After Action Review

Date of Learning Event: 22th November 2001

One or two sentences giving the background /
scope to the experience:
Over the past 12 months, ITMD has designed
and implement a conversion from Banyan
Vines Network Operating System to
Microsoft NT. Simultaneously, it has rolled
out a new corporate email system (Eudora).
This After Action Review sought to capture
some of the key lessons learned from both the
implementing team and some of the users.

Key Player - individual(s) who called the AAR: Terry Gavin

Team Owner of Learning: ITMD

Key Players/AAR Participants

AAR Facilitator: Steve Song, Allison Hewlitt (captured quotes)

- Bellanet

Key Words: (maximum of 10 that would enable Eudora, NT, migration, email, training,
future users to re-find this learning) pioneers

Key Dates: (the years that the learning was acquired) 2001
Specific Actionable Recommendations
(SARs)
Communication
Explain why the choice of software was made
and make it clear when the decision to move
forward has been made.
Involve a larger variety of users in the software
selection process.
Clarify user goals versus ITMD goals.
Pioneers
More “pioneers” are needed on each floor. At
least 2 but up to 4 per floor.
Merge the role of the pioneer and the coach.
Ensure a representative cross-section of pioneers.
Both invite and ask for volunteers to become
pioneers. Don’t just use the “early-adopters” as
pioneers.
Monitor the “pioneers” more closely to better
identify training requirements.
Training
Spend twice as much money and time on
training.
In delivering training, focus on the key
differences between the old and the new
software.
Invest in a second round of follow-up training.
In the beginning users don’t know what they
don’t know.
Set up targeted training sessions focusing on
particular aspects of the application. Allow users training sessions” – Scott Rattray
to select sessions that suit them.
Quotes
“Might be useful to explain why the choice was
made – Scott Rattray
“Different slice of end users (should be used)
to select the software” – Roch Paquette
“Some goals are ITMD specific, others are for
the users” – Allen Sinfield
“I would have tried to get more pioneers per
floor” – Veronica Suarez
“We didn’t feel like we were coaches” –
Veronica Suarez
“A combination of invitation and choosing
pioneers.” – Pauline Dole
“Training seems to be a big issue. Maybe we
should monitor the pioneers and train them
more” – Yvan Plamondon
“If at all possible, devote more time and budget
to training” – Hugh Campbell
“Twice as much money AND time” – Veronica
Suarez
“Training should be done by someone who
knows the difference between the packages” –
Pauline Dole
“I agree with having very targeted one hour