ABCs of KMLessons learned

Lessons Learned Part 13: Integration

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

In times of profound change, the learners inherit the earth while the learned find themselves beautifully equipped to deal with a world that no longer exists. – Eric Hoffer

Integration, the actual learning of lessons by the organization, is not only the linchpin of the entire lesson learned life cycle but also by far the most difficult of the life cycle phases to manage. Even organizations such as NASA, the U.S. Army, Federal Aviation Administration, and U.S. Department of Energy, where lessons are a matter of life and death, still report difficulty getting employees to learn in spite of years of focused and intensive effort. For example, even after highly publicized space shuttle and unmanned spacecraft disasters, one fourth of NASA’s managers were still not aware of the agency’s decade-old lessons learned system.

Clearly, while one can argue that in some ways all organizations learn just by virtue of their existence, creating an organization that effectively learns from its mistakes and experiences is extremely challenging. There are several common fallacies and hurdles that must be overcome to ensure that lessons are integrated into the organization.

If you build it, they will come

There is a notion that the mere existence of lessons, if properly packaged in an easy-to-use repository or newsletter, will draw users like moths to a flame. Frequently after deployment of such systems, the creators are puzzled as to why the organization is not learning. System developers may find at least one of the following: (1) the system was not designed with sufficient understanding of users’ preferences; (2) the users do not have time to search the system; (3) the content is not perceived to be relevant or actionable; (4) the receipt of the lesson does not coincide with an activity where it can be put to use.

Can’t we all just get along?

This is the idea that knowledge intermediaries are not necessary — capturing and sharing lessons should as a matter of course be an integral part of everyone’s job. But the fact is that in the midst of problems, most people left to themselves do not make the time or have the inclination to stop and reflect on what they have learned unless prompted by an outside force. Also, many very smart people with valuable knowledge to share are not good writers or communicators. Unless there is a very strong pre-existing culture of knowledge sharing, the critical mass it takes to make this approach successful will be very difficult to attain.

We tried that five years ago…

This is variously called the “Hot Stove Effect,” after Mark Twain’s description of the cat that gets burned and never again sits on a hot stove but also never sits on a cold one, and the “Green Room Effect” after Schein’s description of dogs who get shocked every time they enter a green room and so learn to avoid it. This effect creates a bias in organizational learning against risky and novel alternatives. From a lessons learned standpoint, the effect influences the actual lesson learned. An organization may try a new method or technology but then abandon it at the first sign of problems. The surface lesson that gets captured is that the new approach is worse than the old one, but the deeper uncaptured lesson may be that the new method is actually better but was not given sufficient time for the organization to fully understand it. It is here that intermediaries can, through tools such as AARs, push the organization into the “double-loop” learning that uncovers these deeper lessons.

You can lead a firm to knowledge but you can’t make it think

This play on an old adage is the title of the first post in this series and reflects the point at the beginning of this section that the capture, storage, and dissemination of lessons can be tightly managed and controlled, but true learning at the individual level has to be voluntary. The best that a lesson learned system designer can do is design the system such that it increases the likelihood that lessons will be learned. There are several techniques to aid in this; not all techniques will apply to all lessons.

  • Stories. Humans have been passing lessons to each other in the form of stories for thousands of years. Shaping a lesson into a story makes it easier to understand, easier to remember, and easier to transfer. A well-designed “springboard” story or learning history allows its recipients to make the mental leap from the context of its origin to the context of their own work experience For example, NASA has expanded its dissemination of lessons in recent years beyond a basic database to a collection of stories specifically written to illustrate lessons.
  • Case studies. In some respects a special form of story, a case study can be created and integrated into training. The fact that these cases are real and came from one’s own organization can make them more meaningful than standard hypothetical cases. A popular approach is to describe the case, ask “What would you do?,” and then compare the student’s answer to what actually happened, possibly followed by discussion as to which answer might be better and under what circumstances.
  • Phase gates. Many processes in an organization have several phases, and often include a gate at the end of each phase that prohibits entry into the next phase until certain criteria have been met. Lessons can be inserted into these gates as a way of ensuring that they will at least be acknowledged, if not learned. This insertion can range from a simple instruction to “check the lessons learned database” before proceeding to insertion of actual lessons where appropriate, perhaps in the form of a checklist. These lessons may be either awareness lessons or action lessons. An awareness lesson, such as a pre-flight checklist for a pilot, is a lesson that says “be aware of these things when performing this activity.” It does not necessarily require action, just heightened observation. An action lesson says something like “always do this in this situation.” The expectation is that by following the process, the right actions will be taken.
  • Process or system changes. Under some circumstances, lessons can be used to fundamentally change a process or system. This might be accomplished through the use of artificial intelligence systems to replace human decision makers, or can also be achieved through redesign of systems. For example, as government agencies and automobile manufacturers have learned more about auto safety, they have gradually moved from stories and case studies (“Look what happens when you don’t wear a seatbelt”) and phase gates (“Always buckle up before starting the car”) to design changes that include airbags, anti-lock brakes, and on-board radar systems that react to the proximity of nearby vehicles. It can be argued that these systems have “learned” even though individual drivers have not.

Notice that the above techniques for organizational learning progress from full individual responsibility for learning to none. A passive lessons learned database requires not only a high level of individual learning but also a high level of individual initiative – finding appropriate lessons, understanding them, interpreting them, and acting on them at the right time and place. Stories and case studies take some of the burden off the individual learner by adding context to the lesson to make it easier to absorb. In a phase gate, the individual does not have to understand the lesson but simply follow the recommended action. Finally, a process or system change integrates the lesson so completely into the organization that its members do not even have to be aware of it.

In the next post we discuss the problem of unlearning lessons and maintaining a relevant lessons learned system.

Next part (part 14): Maintenance.

Article source: Lessons Learned Part 13: Integration.

Header image source: PeakPX, Public Domain.

References and further reading:

Rate this post

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

Back to top button