Lessons Learned Part 4: Capture

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 blog 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. The 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.

Continue to Part 5: Capture Using After Action Reviews

Previous posts:

• Part 1: You Can Lead a Firm to Knowledge but You Can't Make It Think

• Part 2: What is a Lesson?

• Part 3: Initiation and Recognition

References:

• Nancy Dixon: "Organizational Learning: A Review of the Literature with Implications for HRD"

• John Everett and Daniel Bobrow: "Resolving Redundancy: A Recurring Problem in a Lessons Learned System"

• Moira Levy: A Holistic Approach to Lessons Learned

• Lynne Marcus: "Toward a Theory of Knowledge Reuse: Types of Knowledge Reuse Situations and Factors in Reuse Success"

• Michael Morris & Paul Moore: "The Lessons We (Don't) Learn: Counterfactual Thinking and Organizational Accountability after a Close Call"

• George Roth and Art Kleiner: "Developing Organizational Memory through Learning Histories"

• James Thomas et al: "Understanding 'Strategic Learning:' Linking Organizational Learning, Knowledge Management, and Sensemaking"

• U.S. Department of Energy: "DOE Standard: The DOE Corporate Lessons Learned Program"

• Karen Watkins and Victoria Marsick: "Building the Learning Organisation: a New Role for Human Resource Developers"