In my first post about Project Management and Knowledge Management I spoke about Collaboration, in this second post I will talk about after-action reviews.
After-action review also known as a project snap-shot, lessons learned, or any number of other names is an important Knowledge Management activity to complete at the end of a project. They don’t have to be long and cumbersome, in fact they shouldn’t be. Taking a few minutes to summarize key decisions that were made, things that went well, things that should be done again, things that didn’t go well, and things that shouldn’t be done again is an important learning tool for project team members and for future teams–if they decide to go and look for lessons learned before starting a project. This is especially true for inexperienced project teams/members, i.e. they should be looking for lessons learned before starting a new project.
Some project managers will argue that there is no point in doing after-action reviews that no one looks at them and that may be true. I have gone to many Knowledge Management conferences in the past and at the ones I have attended recently it surprised and frustrated me that many of the case studies seem to repeat the same lessons learned, in fact I wrote about it in an earlier blog post. That doesn’t mean that after-action reviews shouldn’t be done, it means that project managers and others need to remember to go and look for lessons learned and not fall into the “not invented here” trap of thinking that no one has done a particular activity before or that if it hasn’t been done by them/their organization there is nothing to be learned from other’s experiences.
Even if no one outside of the project team uses the lessons learned it’s important for the project team to do the analysis. Sometimes things are happening so quickly on the project that team members need to take a few minutes once the project is done to tie everything together. Once all the tasks are complete they can see the big picture of what actually happened and the consequences of certain actions and decisions so they can learn and do things differently next time, make new mistakes rather than repeating the same ones time and again. I know I like to make new and improved mistakes rather than the same old ones.
Thanks Nick, that sounds like a great use and application of AAR! I have mostly seen them poorly implemented for internal/IT/consulting projects. I always like to do them, because I like to learn from my mistakes and figure out how to do things better the next time, but it’s always a fight. Being more efficient and effective with oil wells/drilling has a more measurable cost-benefit, which I imagine makes it easier for people to justify spending the time.
Stephanie, I find that when a project team institutionalises AAR like this, they usually find that each AAR results in one or more actions. I think here, for example, of the drill crews in Alaska, who use AAR after each significant task drilling a well. The action is either to fix something (order better equipment, train an operator, reorder a schedule) or to update a defining document (the rig manual, the drilling procedure, the contractor operating procedure). This way, if the actions are completed, the knowledge is never lost. The teams used a lessons database with action trasking enabled, so they can enusre improvement actions are closed out. The military use a similat approach
regards Nick