This is the first of a two part series looking at “After Action Reviews”. They are a useful tool for analyzing what happened, why it happened, and how it can be done better, by the participants and those responsible for the project
Taking a step back and reviewing a project, whether team based or individual is something that not a lot of people do these days. The usual excuse is that they are too busy, and are under pressure to immediately move on to the next project.
All of us are under time pressure, however if we plan accordingly then we really should set aside time at the end of a project to assess the reasons behind it’s success, or failure. This creates an opportunity to learn, to ensure mistakes are not repeated, and to identify what worked well, so that it can be used again.
About 5 years ago, my then manager asked me to join the Knowledge Management Team. One of the projects that I was involved in from the start was After Action Reviews. I have participated in After Action Reviews, from both sides of the table, as a facilitator running them for colleagues, and also as a participant, when I’ve wanted to look back on a project that has been completed.
In this blog post I will share with you some of the key principles of After Action Reviews. I hope it catches your attention and perhaps it is something that you might use in the future.
Structure of an After Action Review
- What was the objective going into the project?
This is always an interesting part of the review. The facilitator will get each participant to give their interpretation of what the objective of the project was. It’s usually not a good sign if there are lots of different opinions about what the objective was. - What happened during the project?
In this part of the review participants focus on the facts that emanate from the lifetime of the project. The facilitator plays an important role at this stage to ensure that people don’t start focusing on why certain things happen. - Why did things happen in the way they did?
This is where the participants start looking at why certain things happened, building upon the outputs of the “what happened” session. This is an opportunity to dig deeper and reflect. The facilitator is really crucial here as it is key that no blame is assigned during this process. - What should happen next time?
This is where participants decide the output of the review. The facilitator will ask participants the following 3 key questions:
# What should you stop doing?
Activities that had a negative effect during the project.
# What should you continue doing?
Activities that had a positive effect during the project
# What should you start doing?
Activities that should have happened during the project, but didn’t
In my experience After Action Reviews have normally been applied to team projects. That’s not to say however that the framework can’t be used for projects you are working on individually. I’ve used this methodology to review projects I’ve worked on as part of a team, as well as those which I’ve worked on individually.
In part 2 of this series, I will share with you what can be done to ensure a successful After Action Review.
Before this, I’d be interested to know your thoughts on this process. Is it something where you would find valuable? Do you use a different approach to reviewing projects? Please use the comments to let us know.
The views expressed on this post are my own and do not necessarily reflect the views of my employer, Oracle.
Image credited to http://www.flickr.com/photos/peterkaminski/
