Lessons Learned Part 12: Dissemination

"The future is already here; it's just not evenly distributed." -- William Gibson

"Hunt, don’t just gather. Disseminate, don’t just aggregate." -- Maureen Baginski (former FBI Assistant Director)

It does no good to store a large collection of lessons if no one ever looks at them. After all, this topic is lessons learned, not lessons acquired. The classic mistake of most lessons learned systems administrators is thinking that your audience has the time, motivation, or knowledge necessary to actually learn the lessons you have captured and stored without any help or encouragement.

The simplest and probably least effective approach to dissemination is to create a repository, such as a lessons learned database, and then assume that because it exists it will be used. This really shouldn't even count as dissemination because it's only half the process. We often like to say we are "sharing" content and ideas when we post to open platforms, but in fact information is truly shared only when it moves out of one brain and into another. So how do we get that information to stick inside someone's head?

There are many more ways than you might think to disseminate lessons. To illustrate the wide range of options, check out this list that the U.S. Department of Energy published over a decade ago (which is why some of the technologies are a little dated):

List server; lessons learned web site; email; teleconferences with real time video demonstrations; fax machines (for personnel without computers); staff meetings; post-project meetings; information exchange workshops; cross-cutting working groups; employee exchanges; lessons learned search service; posting on bulletin boards, conference room doors, toilet doors; inclusion of lessons in training courses; hardcopy documentation of lessons sent by mail; benchmarking comparisons; publications such as newsletters, newspapers, bulletins, alerts, brochures, and fact sheets; lessons learned ambassadors and experts; and internal conferences

A robust lessons learned system should have multiple methods for disseminating lessons, but using multiple approaches without an understanding of both the type of lesson to be conveyed and the type of audience may result in wasted effort and even a lack of learning on the part of the recipients. Some lessons can be learned just by reading, while others might require practice (think new surgical or musical techniques).

Potential audiences can be segmented based on their relationship to the lesson to be learned. Nancy Dixon does a great job explaining this in her book Common Knowledge, describing in detail processes such as serial transfer (among members of the same team), near transfer (between similar teams), far transfer (across the organization), expert transfer (to novices), etc.

An easy way to think of these audience segments is in terms of the amount of context that has to be provided in order for them to understand the lesson. There are shared work producers, who reuse their own knowledge; shared work practitioners, who reuse knowledge from each other (as in a community of practice); expertise-seeking novices; and secondary knowledge miners. If you think of context as a set of concentric circles surrounding a core lesson, each successive audience requires greater context in order for it to be intelligible.

Producers of lessons might get by with a few notes to jog their memories, while practitioners will need a fuller description of the lesson, but can still understand the jargon associated with a particular practice. Novices require an even larger amount of context, which is why a firm's own marketing and sales people are often less likely to understand the significance of a new internally developed technology than are a competitor's engineers (see John Seely Brown's The Social Life of Information for some interesting case studies of this phenomenon). A salesperson might have a legitimate need for understanding a new technology, technique, or solution to a problem in order to be better prepared to offer it to customers, yet have a very difficult time interpreting the lesson as captured by engineers not aware of the potential expanded audience for that lesson.

So what do I mean by "secondary knowledge mining"? This goes back to the idea of the need for knowledge intermediaries (Part 8 in this series). KM staff or lessons learned system administrators might often scan the repository looking for themes and patterns. The lessons relating to these themes can then be consolidated and published as a set. Examples of this concept include the Wildland Lessons Learned Center's yearly AAR "roll-ups" and the Federal Aviation Administration's monthly newsletter Callback, which sometimes runs themes such as when to go around and try again rather than attempt a landing.

Another way that a lessons learned database might be mined is for the purpose of tying several lower-level lessons together to present a higher-level lesson. Often when an organization has a large problem or embarks on a major new initiative, a plethora of lessons is created. There may be marketing lessons, product development lessons, manufacturing lessons, service lessons, etc., all arising from the same major event. Each of these lessons will have its own narrow value for a particular group, but a standard lessons database may not adequately reflect the interrelatedness of these lessons and their larger value when taken in combination. In these circumstances, it may be more useful to executives for someone in a knowledge intermediary position to pull together an overarching story that can serve as an executive summary and weave the various lessons into it. It may be especially useful to create this as a web page with hypertext links to the detailed lessons. In this way, members of the organization can start with the big picture and drill down into whatever specific detail they find useful.

OK, so you've identified some lessons, captured and stored them along with the necessary context around them, and spread them around your organization every way you can think of. How do you make sure it actually learns them so it doesn't make those same mistakes again? In Part 13 of this series, we'll discuss integrating those lessons into the fabric of your organizational culture.

Previous posts in this series:

• 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
• Part 4: Capture
• Part 5: Capture Using After Action Reviews
• Part 6: Ten Tips for Facilitating After Action Reviews
• Part 7: Additional Ways to Capture Lessons
• Part 8: The Role of the Knowledge Intermediary in the Lessons Learned Life Cycle
• Part 9: Validation
• Part 10: Scoping
• Part 11: Storage

References:

• John Seely Brown and Paul Duguid, The Social Life of Information
• Nancy Dixon, Common Knowledge: How Companies Thrive by Sharing What They Know
• Federal Aviation Administration Aviation Safety Reporting System (ASRS), Callback
• The Guidance Group, "Successes and Challenges from AAR Roll-Ups"
• Lynne Marcus: "Toward a Theory of Knowledge Reuse: Types of Knowledge Reuse Situations and Factors in Reuse Success"
• U.S. Department of Energy Society for Lessons Learned Sharing (SELLS), "Information Dissemination Methods"
• Wildland Fire Lessons Learned Center, "From AARs to AAR Rollups"