After Action Review (AAR) Template
After Action Review (AAR) Template
A simple and effective tool for organisational learning and improvement
TL;DR use these four questions in review meetings to learn from experience and take actions:
What did we set out to do? (goals)
What actually happened? (observations, results)
Why did it happen and what do we learn?
What are going to do next time / moving forward? (action)
Why - learning organisation: In order to learn and improve it is essential that a startup regularly reviews what works, what didn’t and what to change. Part of this will be in form feedback by managers (which will be another post). It is also important to review performance candidly as a team. This does not come easy to everyone, as some people don’t take (or give) constructive feedback easily. Hence, we need a process that allows unfiltered feedback without blaming people or triggering defensiveness.
When - applications: Apparently the After Action Review approach was developed by the U.S. military where it is rigorously applied in all branches. Personally, I learned about the AAR during my training as a Marshall Goldsmith Stakeholder Centered Coach, where the method is a key component. In startups it can be applied in various contexts, whenever learning and improvement is necessary - which is typically always and everywhere! Some common applications that I have used are:
sprint or project reviews (after a project was delivered)
debrief after presentations (e.g. sales or investor pitches, board meetings and others)
development conversations with team members (monthly or quarterly)
periodical reviews, e.g. Friday afternoon review of the week passed
Some organisations use the term ‘post-mortem’ for project reviews. I don’t like the term as it starts with a negative mindset (post-mortem literally means ‘after death examination’). In my view, many startups struggle more with understanding what actually works, than identifying what doesn’t.
How - the process: in an AAR you go through four simple questions:
What did we set out to do? (goals)
What actually happened? (observations, results)
Why did it happen and what insight can we gain? (learning)
What are going to do next time / moving forward? (action)
Generally, the approach should be more or less self explanatory. For clarity let me outline the role that each step plays:
1. What did we set out to do? (goals)
In order to objectively evaluate the success or effectiveness of an activity, it is necessary to explicitly state and agree on, why you did it in the fist place. When the goals are not clear, it is possible that people disagree if an initiative was a success or not.
2. What actually happened? (observations, results)
This should be easy, but frequently is not in practice. Aim to stick to observable facts, like who did what and when, and measurable outcomes. Avoid at this stage to evaluate, judge or draw any conclusions.
When there is agreement on what actually happened, the group can hopefully agree if the objectives defined before were actually achieved or not.
3. Why did it happen and what insight can we gain? (learning)
Now we get to the analytical part where the team identifies the root causes (underlying reasons) for both, failure and successes. It is critical do be completely honest and equally examine in depth shortcomings as well as strengths.
The biggest challenge at this stage is to avoid blaming people and triggering defensive behaviour (“it wasn’t my fault”). The leader needs to set the sage and lead by example that making mistakes is acceptable, even a good thing, when the team can learn from and take actions not to repeat them. It shouldn’t matter who caused a problem, but only what everyone can learn from them.
4. What are going to do next time / moving forward? (action)
Last comes the most important part: taking action. What are you going to do differently in the future? What will you keep doing, because it worked, or do even more? What should you stop doing? Are there goals that need to be revisited or plans that should be adjusted?
Make sure to name owners and time frames for actions and document what you have learned, so that in the future the team can understand what directed you learning and the knowledge stays retained.