Back in July of this year, my colleague and mentor
Jim Lee blogged on the topic, "In KM, What's Old Is New Again." In his post, he mentioned lessons learned and the fact
that another mutual friend of ours once commented that "lessons learned" are
frequently nothing more than "lessons captured." I was reminded of the topic
again during a recent episode of "The Amazing Race" on CBS. I admit, I'm a huge
fan of the show and watch it regularly every Sunday evening (after football, of
course--I am, after all, from
Many organizations have lessons learned activities
or initiatives in place. Many even have trained facilitators who are
responsible for helping individuals, project teams, and other groups identify
and capture their lessons. Despite these efforts, however, the actual learning--the behavioral change that
would bring about a different outcome the next time around--never occurs. Why is
that? What is it about capturing and applying lessons learned that so often trips
us up and causes us to never get past the "capture" step of the process? Is it that
the mistake or error that prompts the lesson is so context-dependent that we
think others couldn't benefit from it and therefore we don't capture it at all?
Or could it be that whatever repository these lessons disappear into is so
unorganized that retrieving them in order to apply them is a huge undertaking?
Or is it simple communication--in other words, we simply don't share our lessons
learned proactively with those who might benefit from them? Or some combination
of the above?
So, what's the deal with lessons learned? They get
a lot of air time, but something prevents us from realizing their true value.
I'm interested in hearing your perspectives on the challenges of capturing
and, moreover, applying lessons
learned.
I think part of the right answer is to build a learning & collaboration culture. So much of what is done in KM/IM is about the knowledge/content owner capturing / making their stuff available.. or pushing it on overworked, ADD knowledge workers.
The focus needs to be more on the learner / consumer. (I think Nancy Dixon wrote about the "neglected receiver" a while back.)
(We) Knowledge workers learn before doing (from information content, friends, colleagues, experts etc.) as part of doing knowledge work, and as a result, often create new / improved /evolved knowledge and information. We need to remove the structural, process, practice and technology barriers to learning / knowledge seeking, recognize and reinforce that behavior in ourselves and our colleagues, and create a demand for knowledge and information in all its forms.
That demand, the learning needs, will create the context important for the sharing of lessons learned, because they're not learned unless there is a change. And the change comes from the learner.
Creating a learning / collaboration culture is not an easy task, given the power of the human ego - "I'm different".. "I can do it better".. - or the time pressures we're all under - "it's too hard to find what/ who I'm looking for.. so I'll just recreate it.. "
I'm beginning to think that the evolution of knowledge management thinking, the growing promise and potential of emerging social technologies, age demographic shifts in organizations, behaviors of newer generations of techno-savey employees, and the growing acknowledgement of the need to systematically go about connecting people to each other and to information, may be creating a more generalized readiness for "knowledge markets" of the type McKinsey was writing about earlier in this decade.
The following comment was posted by Kerstin Kleese Van Dam in our KM Edge LinkedIn group.
I agree with your conclusion that though often captured the lessons are usually never really learned. Personally I believe that this is down to human nature. In many cases learning the lesson would mean changing ones behaviour i.e. in your example be more thorough and observant, however we usually only change our behaviour long term if there is real pressure to do so.
The other problem is that we often look at what went wrong, but we do not explore with the same zest how we could have done it better and even if we do there is no follow up exercise e.g. to practice and enforce the new behaviour. Thus by the time the next project comes around many of the lessons are already forgotten and unless in real trouble few people will look at the lessons learnt captured from a previous project however easy to reach.
A solution could be a much more extended capture process incl. specifically exploring in detail how to do it better next time, reinforced with exercises that demonstrate the value. In addition one might need a designated person/facilitator who guides the team through the next project and ensures that the lessons learnt are applied. Alternatively a review of past lessons learnt could be made part of the project monitoring i.e. a checklist of things that where meant to change.
Best wishes,
Kerstin
GOOD MORNING, DARCI! To answer your question, in my opinion the lessons learned process is definitely an "all of the above... and then some" issue.
The foremost problem is the traditional treatment of "lessons learned" as a stand-alone checklist process. In my 25 years of workforce experience, lessons learned has always been a mandated activity following a major event. As such it is a post-facto analysis of what one person thinks the next one needs to do (or avoid doing). So right from that start there are several filters in place - with the in-situ context missing (forgotten) lessons learned providers are omitting key contextual information; and like cops with traffic ticket quotas, providers are focused on quantity versus quality. Contributing to the problem are the traditional "capture" systems, which are predominantly fixed format databases that limit the amount of scope & context submitters can provide. The net result: in a post-facto environment that lacks full situational context, submitters are more likely to focus on the positives ("do [x]", "do [y]") and not the negatives ("don't do [a]", "don't do [b]"). Now add the common consumer in the Web 1.0 world who interacts with this "system" via keyword search - more often than not their time is wasted rediscovering the obvious. Hence the whole thing becomes a self-defeating spiral.
Effective transfer of experienced-based knowledge is a persistent cultural phenomenon, not a mandated one-time process. Submitters need the ability to rapidly and efficiently provide knowledge throughout the course of their endeavor, and consumers should be drawn to it in real-time rather than having it pushed by a knowledge purveyor as part of a rigid process. Web 2.0 offers some promise to improve knowledge transfer - but the exact solution will be different in every case depending on the nature of the organization and its existing culture.
Lessons learned programs don’t work because they don’t align with how we think, how we decide, or even an accurate history of what happened. Other than that - totally worth the investment...
http://drfuzzy.wordpress.com/2008/12/06/on-lessons-learned-programs/
An even more fundamental question is what exactly constitutes a "lesson." A few years ago I got interested in lessons learned and did a research paper on the topic as part of my doctoral qualifying exam. I looked across both academic research and real-world publicly available applications (mostly US government agencies) and tried to come up with a set of components for a good lessons-learned repository and a "lessons-learned life cycle."
The repository components I categorized as:
Content
- situation
- driving event
- cause
- actual lesson learned
- recommendation
- application
- evidence of effectiveness
- benefits
Identification (submitter, creation date, ID number, etc.)
Categorization (specific to the organization)
The phases of the life cycle were:
- initiation
- recognition
- capture
- validation
- scoping
- storage
- dissemination
- institutionalization
- maintenance
I'll be happy to mail a copy of the paper to anyone who wants one. Just email me:
depearce@lexmark.com
Acute observation: "the actual learning--the behavioral change that would bring about a different outcome the next time around--never occurs."
Perhaps it's a culture issue: the military do lessons learned because it's a life and death issue. We bureaucrats, on the other hand, gain esteem from being visibly overcommitted, so it may be that LL AND the learning work better in small teams.
Another issue I have been pondering about online posting and retrieval and learning: Le Roy Little Bear, a professor at University of Lethbridge, suggested in a keynote speech that European thought patterns can be likened to Newtonian physics: linear, retraceable, documentable. He says that Aboriginal thought patterns, on the other hand, are more like quantum physics: circular, inferential, and always in a state of becoming. He additionally notes that most Aboriginal languages are verb-based, rather than noun-based (try describing a chair without a noun... and you'll see the difference).
The relevance? I suspect that many knowledge workers may share with other innovators and artists a tendency to the inferential, circular/cluster thought patterns of "right-brain thinking". This makes it difficult to use standard online collaborative sites like wikis, blogs, and SharePoint, which seem to be constructed by engineers in linear patterns.
CNET used to use a cluster-based search tool similar to that of the Visual Thesaurus; I wonder whether a collaborative site with this kind of structure would be more accessible and usable for those whose native mode is not linear?
I would be interested in your collective thoughts on this, and any examples you might have of collaborative sites structured in this way.