ABCs of KMLessons learned

Lessons Learned Part 4: Capture

This article is part 4 of a series of articles exploring the Lessons Learned Life Cycle.

Wouldn’t it be wonderful if there was a way to capture lessons automatically, like setting a spring-loaded trap that would snare a lesson as it passed by? Well, if it were that easy then everyone would be doing it and I wouldn’t be writing these posts. But there are some ways to get closer to that ideal. To do that we have to answer three key questions: Who, Why, and How. I’m going to focus on who and why in this post and dive into some detail on how in the next few.

First, why are you doing this exercise of lesson capture? That seems like a broad question, but I want simplify it to a binary set of answers by putting them the context of daily workflow. As knowledge management folks like to say, is it “above the flow” or “in the flow”? Are you doing it because someone saw a need to capture or because it’s part of a routine process?

Let’s use After Action Reviews as an example (I’ll be covering those in detail in the next post). Suppose Team A and Team B are doing identical projects and have identical issues that could be captured as lessons. Team A has AARs built into their project workflow as a standard step, while Team B does not. Someone from Team B has to recognize the need for an AAR and call a special meeting, while Team A simply executes the process. Team A is much more likely to be successful, because even though on the surface the result is exactly the same – the team holds an AAR and captures a lesson – psychologically it is much different. For Team A, it is just business as usual, while for Team B it feels like extra work that is interfering with their real job. In addition, Team A will capture more lessons than Team B over the long term because their motivation is to follow the process rather than to be consciously looking for potential lessons. So regardless of your preferred technique for lesson capture, the more you can integrate it into existing processes the more successful you will be.

The second question is who is going to capture lessons in your organization. That answer to that question can also be simplified to a binary: insider or outsider. Will the capture be done by a team member or employee who actually experienced the event the lesson is drawn from, or by a facilitator or KM staffer whose role is to do this kind of work across the organization? There are pros and cons to both, depending on organizational culture. In some instances, particularly where there were serious screw-ups, teams might be embarrassed or fearful to have an outsider sitting in. They might feel more comfortable, honest, and open keeping the discussion within the confines of the team.

However, I personally prefer having someone with no stake in the outcome who is trained to facilitate discussion sessions and extract lessons from them. Particularly in situations where the talk gets heated, it’s often too much to ask for someone with a stake in the outcome to remain dispassionate as a meeting facilitator. They become focused on getting their own comments and opinions heard and forget to draw out the comments of others. Much better to have someone who can maintain focus on extracting the most information possible from the participants, rather than getting swept up in the conversation.

I like to think of these kinds of people as intermediaries rather than just facilitators, because they can serve many other roles:

  • Interviewer: extracting lessons from areas of the organization where they might otherwise pass without being captured because of time or resource constraints.
  • Gatekeeper: filtering lessons to eliminate and prevent redundancy.
  • Interpreter: more likely to see the broader value of a lesson beyond its immediate context.
  • Maintainer: taking responsibility for maintenance and improvement of the lessons learned system over time.
  • Buffer: provides the knowledge source with a way to be accountable to an outside party rather than to the source’s superiors or management, creating a less threatening environment for sharing problems and mistakes.

In the next few posts, I’ll cover how those lessons can be effectively captured.

Next part (part 5): Capture Using After Action Reviews.

Article source: Lessons Learned Part 4: Capture.

Header image source: John on Flickr, CC BY-SA 2.0.

References and further reading:

5/5 - (1 vote)

Dennis Pearce

Dennis Pearce is a knowledge management and social business / collaboration strategist with extensive experience in engineering, manufacturing, IT, strategic planning, process improvement, and change management.

Related Articles

2 Comments

  1. Great post. The “who, why, and how” covered in the article are very useful for looking at the lessons capture process. It would also be interesting to address the “who, why, and how” in the content of lessons; e.g., what makes a useful lesson to learn from going forward, especially when those who need to learn from the lesson aren’t necessarily the same team that generated it?

  2. Thanks Kristin — good point about the who, why, and how for what makes a lesson useful. While I don’t use those words exactly, I do touch on this idea somewhat in:

    Lesson 10: Scoping
    Lesson 11: Dissemination
    Lesson 12: Integration

    It’s not an easy problem to solve because you need to figure out (1) how specific or generalizable the lesson is that you’re capturing and then (2) ensure that you’ve got the right amount of context around it. The farther away the audience is organizationally from those who experienced the lesson, the more context there will need to be around it to make it useful.

Back to top button