Lessons Learned Part 10: Scoping
This article is part 10 of a series of articles exploring the Lessons Learned Life Cycle.
We’re drowning in information and starving for knowledge. – Rutherford D. Rogers (Yale librarian)
At some point during the lessons learned life cycle, somebody has to determine what a lesson means. In other words, why are we capturing this information? What makes it more than just a historical record of an event? I call this activity scoping, although in the papers I reviewed (see Part 1) it has also been variously called “distillation,” “evaluation,” “interpretation,” and “packaging.” It is tightly coupled with the storage of a lesson and often happens either immediately before, simultaneously with, or immediately after storage.
Poor scoping is often the culprit behind many lessons learned system failures. Without appropriate clues, it’s hard for users to determine whether any given lesson fits their particular situation. These clues can be in the way the lesson is written, the examples it provides, or the metadata used to tag and categorize it. This is where knowledge intermediaries (see Part 8) can be of tremendous help.
Scoping actions often include:
- Extracting and distilling a lesson down from what might be a collection of interrelated knowledge describing an event
- Interpreting and evaluating lessons for their broader applicability and adaptation within the organization
- Catching lessons that are redundant and eliminating them or preventing them from entering the system
- Prioritizing lessons and assessing the best method(s) for their dissemination, then packaging them appropriately.
A big challenge when scoping a lesson is identifying the proper level of specificity. Specificity is a two-edged sword; adding more detail makes the lesson clearer for those who find it applicable, but at the same time reduces the range of situations for which it is applicable. Here’s a silly example:
Suppose I was at a bar celebrating my twenty-first birthday and drank way too much, waking up the next morning with the worst hangover of my life. A lesson I might take from this is to never drink this much again when celebrating my twenty-first birthday. Of course this is a ridiculously specific lesson because I will never again have a twenty-first birthday. Here are some additional lessons I might come up with as I become increasingly more general in my scope:
- Never drink this much again at any birthday celebration
- Never drink this much again at any party
- Never drink at a party
- Never attend a party where alcohol is served
- Never go anywhere where alcohol is served
- Never go anywhere.
As you can see, both ends of the spectrum are ridiculous, at one end because the lesson is so specific it can apply only to the unique situation that created it, and at the other end because the lesson is so general that it could apply to almost anything. The trick, which is admittedly not an easy one, is to find the lesson somewhere in the middle that is general enough to be as broadly applicable as possible while specific enough to be recognized as useful.
Another challenge is that the same event might have different lessons at multiple levels. I once was documenting a situation where a design engineer had specified the wrong material for a part, causing it to fail. But deeper investigation uncovered that this same mistake was made by another engineer a year earlier who specified this same material for another part on another product, yet that mistake was never captured or shared beyond his own team. So at the surface level there was an engineering lesson to be learned about how to properly specify materials for certain uses, but at a deeper level there was a broader lesson about communication and knowledge sharing that really had nothing to do with physics or material properties and could be applied to just about any part of the organization.
I mentioned earlier that scoping is tightly intertwined and can come before, during, or after the storage of a lesson. Prior to storage, there must be some organizational understanding as to the importance and breadth of a lesson in order to determine whether it is worth capturing and, if so, the level of detail and categorization required. For example, the U.S. Department of Energy’s lessons learned flow process has three separate checkpoints at which lessons are reviewed to assess applicability prior to dissemination.
After storage, assessing the priority, breadth, and context of a lesson will help to define the best methods for packaging and disseminating it. So scoping essentially determines which elements of a complex, real world lesson need to be stored in order to make it useful and salient. These elements that need to be preserved in order to make such a useful, salient lesson will be covered in detail in the next part of the series.
Next part (part 11): Storage.
Article source: Lessons Learned Part 10: Scoping.
Header image source: Public Domain Vectors.
References and further reading:
- John Bickford, “Sharing Lessons Learned in the Department of Energy”
- Nancy Dixon, “Organizational Learning: A Review of the Literature with Implications for HRD Professionals”
- John Everett and Daniel Bobrow, “Resolving Redundancy: A Recurring Problem in a Lessons Learned System”
- Lynne Markus, “Toward a Theory of Knowledge Reuse: Types of Knowledge Reuse Situations and Factors in Reuse Success”
- George Roth and Art Kleiner: “Developing Organizational Memory through Learning Histories”
