This action might not be possible to undo. Are you sure you want to continue?
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?
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. 2. First. activity. The following provides an example of two ways to write-up a SAR from an AAR . The facilitator asks the team members for crisp and clear. The facilitator then asks the team members what aspects of the project. if the participants have difficultly being open. Additional probing questions could include . Alternatively. 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. activity. event or task. activity. event or task and whether they were achieved as planned. 1. 3. the facilitator could go around the room asking each individual to express one thing that worked and one thing that didn’t. Tip: If suggestions are not forthcoming. for an individual to capture the quotes connected to each SAR. Again. achievable and future-oriented recommendations. 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. The facilitator should arrange in advance. 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. event or task worked for them.“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 should use the “Why?” question to identify the root reasons or explanations as to why things didn’t go so well.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. you can also start with writing down comments on ‘stickies’ and discuss them in the group afterwards. What would you do differently next time? This question is intended to help identify Specific Actionable Recommendations (SARs). They supplement the SAR and can be included in the documentation of the AAR. event or task didn’t go so well or “What were aspects that they didn’t like”. the facilitator asks the team members what aspects of the project. It is the role of the facilitator to encourage and promote discussion around these questions.
Tip: Ask each individual to write down their response to the question “What mark out of 10 would you give this project.Gilles Tip: The question could also be asked as “If you could do this all over again. 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.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) . The following template is provided as a guide. Name of Event: Date of Event: One or two sentences giving the background / scope to the experience: Key Player . event or task?”. þ Better SAR: Purchase support documentation for the application as soon as possible preferably once the selection has been made. make sure that it is circulated to all AAR participants for their comments and feedback. activity. get each individual to tell the team their mark and then respond to the follow-up question “What would make it a 10?”. Once the document is complete. Once everyone has written down their response. what would you do differently”.conducted following the deployment of a new software application across an organization: ý Poor SAR: More time is needed to better understand the application. Captured Quote: “ If we could get our hands on the support documentation earlier in the deployment. we could provide better training” .
Darling. Marilyn J. Parry. From Post-Mortem to Living Practice: An in-depth study of the evolution of the After Action Review (Boston: Signet Consulting Group). Charles S. Parcell. Chris../Dec.” Knowledge Management Review. Paul.. 2001.. Learning to Fly (Milford: Capstone Publishing). “Seizing Learning Opportunities at Tearfund. Nov.Key Dates: (the years that the learning was acquired) Specific Actionable Recommendations (SARs) Quotes Sources Collison. 2001. Geoff. Whiffen. 2001 .
The AAR process very evidently improved their confidence in the way ITMD was doing their work. Included below are some of their comments. Go with the flow – it works. 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. Director of ITMD was first exposed to the AAR process at IDRC when he took part in an IDRC Strategic Planning exercise. Terry Terry Gavin. Although Hugh has not yet applied any specifics recommendations from the AAR. I was amazed to see a project plan from one of our technical staff include. At the end of the process. what didn’t work and what could be done differently in a very short period of time. It also leveled off the understanding of the project among the variety of people involved in the process. 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. The new images were developed for deployment on all new desktops and laptops. 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.” 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. Terry provides others with several recommendations… “The first thing that you have to do is be open minded about the process.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. He became really excited about the process particularly because of the way that the team was able to get a sense of what worked. 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. an AAR” After taking part in several AARs. as a final item on the plan.” . we ended up sharing a common view of the project. You can always learn. “People seem to like them and have stuck with them. 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. It is something new and different.
Having now done four AARs. Staff who had a very specific role initially questioned why the AAR was being conducted. in this case the end users. As a result. 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. 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. There was the assumption that something went wrong and we needed to figure out why.Hugh suggests that AARs be planned in advance at key milestones in the project. we didn’t expect many surprises going into the AAR because we were such a close. 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”. This surprised us because we thought we could put all of the goals together on one table. Whenever we needed corrections we did them as we went along. “In this particular project. AARs could help the team identify the issues and as a result. she conducted an AAR bringing together the project team. Louise Louise Brennan is the project manager for the Microsoft Office Rollout Project at IDRC. 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. “For projects on a similar scale. It made us realize how important it was to include people external to the project. self-contained group working together on a daily basis. which affect an entire organization.” Although other staff interviewed did not think that ITMD faced any challenges in introducing the AAR.” Allen Allen Sinfield has participated in the majority of AARs conducted at ITMD as the Manager of the Infrastructure Support Unit. the AAR gave us the opportunity to reflect on what we could change and modify the next time. Close to the halfway point of the project. it became clearer to us that ITMD had two types of goals that needed to be identified and achieved – client goals and technical goals. ITMD is slowly beginning to see a consistent pattern especially around the identification of project goals. 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. in the AAR because it will allow us the opportunity to discover those unexpected surprises – those things that you aren’t necessarily aware of . But. change how they were doing business. “After we had completed two AARs. Allen recognized that ITMD would continue to face the same issues if they continued to do things the same.
Name of Learning Event: Date of Learning Event: One or two sentences giving the background / scope to the experience: NT/Eudora Rollout – After Action Review 22th November 2001 Over the past 12 months. This After Action Review sought to capture some of the key lessons learned from both the implementing team and some of the users. Simultaneously.Bellanet Eudora. The following documentation sought to capture some of the key lessons learned from the implementing team at ITMD and some of the users involved.individual(s) who called the AAR: Team Owner of 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) Steve Song. pioneers 2001 . ITMD has designed and implement a conversion from Banyan Vines Network Operating System to Microsoft NT.during the project”. Terry Gavin ITMD Key Player . migration.” 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. “AARs are about sharing as well. NT. Louise prescribes an approach that is positive. email. Allison Hewlitt (captured quotes) . training. you share in everything not just what went well but also what didn’t go well. If you are a team. it has rolled out a new corporate email system (Eudora).
Merge the role of the pioneer and the coach.” – Pauline Dole “Training seems to be a big issue. others are for the users” – Allen Sinfield Pioneers More “pioneers” are needed on each floor. Allow users training sessions” – Scott Rattray to select sessions that suit them. “If at all possible. At least 2 but up to 4 per floor. “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. 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. Clarify user goals versus ITMD goals. In the beginning users don’t know what they don’t know.Specific Actionable Recommendations (SARs) Communication Quotes Explain why the choice of software was made and make it clear when the decision to move forward has been made. Maybe we should monitor the pioneers and train them more” – Yvan Plamondon Training Spend twice as much money and time on training. “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. Set up targeted training sessions focusing on “I agree with having very targeted one hour particular aspects of the application. 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 In delivering training. Involve a larger variety of users in the software selection process. Invest in a second round of follow-up training. . focus on the key differences between the old and the new software. Ensure a representative cross-section of pioneers.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.