The After Action Review (AAR) is a short focused meeting, conducted by the team, for the team, lasting half an hour or less. AARs allow to you capture useful operational knowledge which is of immediate short term benefit, and which can be ploughed back into the next shift, or the next day's operation. This allows you to make course corrections during activity based on what you learn, address and optimise the way you work as a team, and begin to build your collective operational knowledge. A longer, more detailed review process, suitable for the end of a project or major piece of work, is described separately as the Retrospect process (though sometimes you will hear the term AAR used for this too).
When to hold an AAR. Hold an AAR after a completed task, where learning has occurred:- generally when things have not gone as expected, and when the team has found new successful methods, or new problems and pitfalls. An AAR is most valuable when the task is high-cost, high value, or critical-path, and will be repeated by this or another team.
Who to invite. Invite everyone who took part in the event. Make sure everyone is on equal footing - no hierarchy. There should be no spectators - only participants. Someone from the team should facilitate.
Location and set-up. The AAR benefits from being held immediately after the process or action, so find a quiet location on site, away from immediate distractions. The facilitator must ensure the meeting is open and that blame is not brought in. The only acceptable climate in an AAR is one of openness and learning. The objective is to fix the problem, not fix the blame. Nothing kills an AAR program more quickly than using it for evaluation, formal or informal.
Process. The process consists of asking five questions, as follows
Question one; "What was supposed to happen'?" Look back on the activity or event, and remind yourselves what the main objective was. Even if there was a clear objective, people may still need to share their understanding and interpretation of what was supposed to happen.
Question two; "What actually happened?" Here you are looking for the facts about what happened - the ground truth. You can either collect these through discussion, or refer back to records of the event. If your objectives were clear and measurable ("we need to do X, Y and Z by the end of the week") then performance measurement is also easy ("we did X and Y, but not Z, which will not be complete until Tuesday"). Where the objectives are less clear ("we wish to establish credibility with this potential client") look for facts that support the outcome ("the client said 'you guys obviously know what you are talking about'").
Question three; "Why was there a difference?" With clear objectives and established work processes, then all the learning comes from differences between planned performance and actual performance. Discuss and agree the root causes for these differences. The "5 whys" can be a useful technique. Where work processes may not be so well established, valuable lessons can occur even if the performance has been as predicted. In this case we ask "What were the positive/negative factors?" (in delivering the actual outcome). What has gone well? What has not gone so well? Then we can learn from success as well as failure.
Question four; "What have we learned". Once you have analysed the root causes of the differences between actual performance and expected performance, you can draw out learnings and recommendations for the future.
Question five; "What will we do about it?". Once you have determined the learnings and recommendations, then you need to assign the action to ensure it gets done. Much of the time the action lies with the team. If the team cannot fix the action, there needs to be an escalation route.
Recording Although the AAR will help the individuals become conscious of what they have learned, and can write down the learnings in a personal log book. The facilitator can record actions, and also advice for other teams. Some teams develop proformas for AARs.
Deliverables The main deliverables from an AAR are lessons and improvement actions for the team, which should be logged in the team lessons database. Visit our downloads page for a lessons database suitable for use with the PRINCE2 project management framework. Some of the lessons may occasionally have wider applicability, and should be passed on to the company lessons database, or to the relevant subject matter experts or communities of practice.
