This blog post is a bit of "tip of the hat" to Kent Greenes, who has made available some of his good work that he and his KM team did at British Petroleum (BP) during 1995-1999. And it's also to address some questions that I'd seen asked in a discussion group. The question asked in the discussion group was simply, "what is the difference between Lessons Learned and After Action Review?" And my reply was:

An After Action Review (AAR) is a process. Lessons Learned is not a process, but rather the outcome of a process such as an AAR (although as Mike Kelleher suggests, many processes may produce lessons learned, not just AAR's). From Wikipedia: "The After Action Review, or AAR, is a structured review process used by the military that allows training participants to discover for themselves what happened, why it happened, and how it can be done better. An AAR is about learning, and not about finger pointing or even fixing a problem. Conducting AARs should be conducted with the focus of improving training proficiency. After-action reviews were originally developed and are extensively used by the U.S. Army." And from the U.S. Army's Lessons Learned Manual, Lessons Learned are: "Knowledge gained through experience, which if shared, would benefit the work of others."

But there is quite a bit more to it, and I'd been meaning to do a post on this topic for awhile anyway, so it seems that now is a good time to do so. While the U.S. Army did begin (sort of) the usage of AAR's, I believe that the whole process of identifying and developing lessons learned goes a lot further than that, and to a great extent the whole schtuff was formalized as an expanded process within BP that I refer to as "three opportunities to learn."

The first opportunity to learn is
"Before" which means that before you begin to do something you attempt to find out whether others inside or outside the organization have attempted/done it before. If that answer is yes, go learn from them. The second opportunity to learn is
"During" which involves stopping right after you have just completed something, but before it is "complete" by using the AAR process. The third opportunity to learn is
"After" which involves a review of programs/projects completed, over a longer period of time the the "during" process (still using AAR concept).

Now, Kent and the BP team took this whole thing a bit further and expanded the concept greatly, polishing it up rather neatly and they ended up with what you could think of as a three-step process consisting of: 1) Peer Assist; 2) Action Review; 3) Retrospect. I've attended one of Kent's workshop on this process and I have to say that I like it a lot. And thanks to Kent providing permission for me to quote from his work, let me amplify upon the above to provide some understanding of this whole process. Peer Assist According to Kent, "A Peer Assist is a facilitated meeting or workshop where peers from different teams share their experience, insights, and knowledge with a team that has requested help in meeting an upcoming challenge or problem." A Peer Assist is intended to focus upon something specific -- a known target ("technical, mission or business challenge"). The purpose of the Peer Assist is to draw on the expertise of others outside of your team (we're assuming that this is the "Before" opportunity, and that you've determined that you have that challenge, and that you need some help or would like to better prepare) so that you can learn from their approaches and so that you can benefit from having "experienced others" ask questions that you might not or from a direction that you might not have considered. Kent believes that this works because people are likely to accept "knowledge and insights from other peers" before beginning a task. The key I think is the emphasis upon this coming from PEERS. Kent recommends that this be explored after the internal team has already put together their program/project/task plan but before any actual implementation has begun. Kent says that a Peer Assist can take from a couple of hours to perhaps as long as two days. Action Review An Action Review is a learning process that takes place during the performance of the work, typically during down time or other breaks in the "process, activity or task." This is the "During" that I discussed above and Kent describes it as an opportunity to "learn in the moment." Kent has identified four questions to ask during the Action Review:

1) What was supposed to happen? 2) What actually happened? 3) Why were there differences? 4) What can we learn and do different right now?

The key I believe is to ensure that the team is able to identify lessons learned and what action can be taken immediately. Kent also discusses this as an opportunity to "build relationships, trust and confidence." One significant point to be made is that an Action Review can be completed in about 15-30 minutes. Retrospect A Retrospect is a meeting of those involved in the program/project/task after completion and the "objective of Retrospect is to capture the new knowledge." Kent has identified three primary benefits of Retrospect:

1) Identification of valuable lessons. 2) Enhanced team openness and cooperation. 3) Achievement of closure at the end of the project.

And that includes discussing what the project was intended to accomplish vs. what was actually accomplished; a review of project plans or timelines to look for delays that occurred or where time was saved, and why; what went well and why; what didn't go well and why not; and what the major problems were. So clearly this is that "After" opportunity to learn and the primary focus will be to get "new learning" to prepare for the next time. Kent indicates that Retrospect can typically be conducted in about 2-4 hours. Delivering Real Knowledge Management Value I think that this is an extremely important -- perhaps critical -- to the success of Knowledge Management. The fact of the matter is that you MUST DELIVER ON THE PROMISE OF KM (as Kent would say). Management MUST see the value of KM or you will miss any opportunity to make sure that "good" KM is systemic. And this Before/During/After or Peer Assist/Action Review/Retrospect is an EASY way to effectively demonstrate the real value of KM. I've used this process myself, and can say first hand that it is not only highly effective but it is also an extremely powerful way to drill home the actual value of KM to all those who participate, and all those who see the end result. While it can clearly be argued that Lessons Learned are a "good" thing for the organization, all too many organizations fail to actually benefit from those Lessons Learned.

1) I believe that a part of it is a clear lack of understanding of why Lessons Learned are captured -- almost as if the "goal" is to get them into a knowledge-base somewhere, but inaccessible and unusable. 2) A second problem is that there is a fundamental lack of understanding of just what is a Lesson Learned -- for example, in the discussion group I mentioned at the onset there were some answers given to the question that suggested that Lessons Learned and After Action Reviews were the
same thing and clearly they are not. Repeating, Lesson Learned are not the same as an After Action Review. One is an outcome of a process while the other is a process to develop lessons learned. 3) And the third problem is that even when organizations grasp what a Lesson Learned is, and that they have value, they lack a process that can be utilized to drive both accumulation of lessons learned and the utilization of any knowledge gained. The above process addresses that rather neatly.

Dr. Dan's Daily Dose: If you hope to implement Knowledge Management in your organization, you better have a "plan" in play to ensure that you demonstrate the ACTUAL VALUE of Knowledge Management. And KM and learning go hand in hand, so it is critical to develop and nuture that link, and to take advantage of the symbiotic relationship that they have.