Lessons Learned - The Loch Ness monster of KM
|
| ||||||||
Contents
Original Message
From: Johannes Schunter, posted on 2013/07/18
Hi all,
Whenever I talk to managers and executives, often the most important thing they want to get out of Knowledge Management is "capturing lessons learned". This often goes along with a request to "create a database of lessons learned" where experiences can be systematically archived and searched to inform future initiatives. However, since I have become a member of KM4Dev 7 years ago, I have yet to come across an example of an organization where this was actually done successfully in a systematic way. Where lessons got collected, aggregated, shared and - most importantly - applied. It always felt to me like lessons learned were a phantom that everyone was chasing after, but nobody has ever seen.
The reason for this, I am convinced, is that knowledge sharing only works where experience is shared within a specific context, where the experience can be attributed to the person who has learned the lesson, and where the knowledge sharing is happening just in time (when the input is needed), not just in case. This is happening in Communities of Practices and social networks, but not in databases of documents.
My problem is that I often have a hard time coming up with evidence for this. Would you know of any good paper, research article or other evidence that looks at this in a comprehensive way and provides some insight whether collecting lessons learned documents in a database is (or is not) smart KM?
Of course, if you happen to have evidence of where this is actually working, I'd be happy to hear about that too. No one would be happier than me to be shown that this can actually work.
Looking forward to your insights!
Johannes
Contributors
All replies in full are available in the discussion page. Contributions received with thanks from:
Johannes Schunter
Sophie Treinen
Eric Mullerbeck
Nadia von Holzen
Josef Hofer-Alfeis
Jaap Pels
Charles Dhewa
Davide Piga
Ian Thorpe
Eva Schiffer
Pete Cranston
Robin Van Kippersluis
Neil Pakenham-Walsh
Paul Mundy
Stephen Bounds
Rinko Kinoshita
Matt Moore
Ewen Le Borgne
Philipp Grunewald
Nancy White
Related Discussions
- How to collect and present Lessons Learnt (2 December 2011)
- A rigorous approach to lesson learning (6 August 2010)
- Sharing Lessons and Worst Practices (30 January 2009)
- Does sector learning lead to enhanced capacity and performance? (5 January 2009)
Summary of Contributions
Preliminary Considerations
ccccccc
- ddddddddd
- eeeeeeeee
- fffffffff
= Sources
- Sophie Trainen stated that FAO has "set up several repositories to archive different types of documents. For her, learning lessons is part of the process of good KM, but need to know what the process will lead to. If the process leads to the documentation, sharing and appropriation of good practices, the final products (good practice fact sheet, video, audio programme, theatre play, etc.) need to be archived somewhere. What is crucial is to use good metadata so that you can use and reuse the same document and have it appear on several websites.
- Eric Mullerbeck has not heard of any working Lessons Learned databases. However, he pointed out that if such databases are set up, we might want to ensure that the databases are not 'pull only' so that they don't depend on people going to the database to try and hunt down relevant lessons. Instead they should have 'push' features like RSS linked to specific and well-defined topics, that will automatically push the LL documents to the persons who have interest in those topics.
- Nadia von Holzen referred to a previous KM4Dev discussion on Knowledge banks and emphasized that "we cannot treat knowledge or insights as a commodity we can put in a bank. Knowledge is mysterious. A special stuff, knowledge is fluid, gas-like or steam-like: you can't arrange it successfully in a bank. Information is storable but not knowledge. To make knowledge storable you loose its characteristics, its quality."
- Josef Hofer-Alfeis agreed that LL sharing is seldomly done effectively. He referred to one good example from Continental Cooperation in Germany, which is a LL database accompanied with a lot of complementary organizational, cultural and other KM measures. He links to a graphic illustration of their success factors, showing that the database is only a minor part in their approach.
- Jaap Peels, Nancy White all referenced a recent blog post and slideshow by Harold Jarche "Building institutional memory, one story at a time" which emphasizes the role of stories in building institutional memory.
- Charles Dhewa stated his conviction that KM is more about behaviour change and answering questions than publishing ideas. Working at the interface of formal and informal agriculture in Zimbabwe, he e.g. sees traders become active digital share-croppers. But since these interactions are contextual, he doubts whether trapping this into a paper/article or video will illuminate anything. In his view there are too many case studies that remain case studies and can't be replicated anywhere.
- Jaap Peel suggested to think outside of development as "consciously developing, stimulating and maintaining capacities of people (perhaps next to interfering context, infrastructure, technology which in itself would be useless unless done by capacitated people). He therefore proposed to understand a LL database as information on people capacitated 'by' the organisation. This would then actually be a network which is best kept up-to-date by all the 'people in it' themselves. So instead of focusing on LL databases of documents, an organisation should cherish networks around its staff.
- David Piga shared his case study of a recent LL project for which he sought advice from the KM4Dev community in 2011 (see KM4Dev discussion: "How to collect and present Lessons Learnt". In this project the MDG Achievement Fund activated about 130 UN Joint Programmes (JPs) on various thematic areas related to the MDGs, with the objective to "accelerate the progress on the MDGs", and one component of the initiative was collecting lessons learned. The 130 JPs were organized in thematic windows. UNEP was the convener for the "Environment and Climate Change Window", comprising of 17 JPs. The KM project involved setting up a Community of Practice and, among other things, collecting lessons learned. David, as the facilitator of that community, prepared a handout on how to prepare good lessons learned, and a template, which helped him collect about 50 lessons learned documents. Once we collect lessons, we need to allow other people to use them, for which we need to make them available, which led to a database of lessons learned from the 17 MDG-F JPs on Environment and Climate Change. The problem in his view isn't the database itself, but feeding the lessons to the people who could use them. This requires good metadata, but also promoting the LLs in a number of ways, in all places where the target audience has a presence. They could then also be used for for future planning and inform mandatory steps in new programs and projects. A selection of their projects LLS has been compiled in a booklet available in English, French and Spanish and distributed at a number of events.
- Ian Thorpe suggested that communities and LL databases should be seen as complementary approaches that can reinforce one another. But like with communities, it's not always that easy to do them successfully. He shared UNICEF's past experience where for a time it managed a database of lessons learned that were either submitted by countries in their annual reports, or which they actively sought out for specific themes. The database had several hundred LLs of varying qualities, and the better ones were used in donor reporting,external publications and thematic analyses. These were "case study" LLs that gave specific country programme examples with the LLs rather than generic procedural lessons. Ian reflected that
- A lessons learned database needs to be part of a broader KM strategy which includes other tools such as knowledge sharing events and communities of practice. The database itself can never be sufficiently detailed and every lesson needs to be adapted to context. Amended with contact information of people, the database should be seen as a conversation starter rather than an end in itself.
- Getting people to actually use knowledge that is already available is a challenge. Effort needs to be put into making the database user friendly and relevant, promoting it, and linking into people's everyday work.
- Lessons learned databases actually have other uses apart from as a knowledge resource for aid workers on the ground and these reasons may be why management tends to like them. Among them are i) they can help provide much needed country examples for donor reporting and for advocacy publications ii) they can be a useful information resource for thematic analyses and planning iii) the database is something tangible that can be shown off (it's much harder to "show off" a community, you can only easily show off the knowledge products it produces) iv) case study lessons learned can be useful tools for internal advocacy, or external technical advocacy around new programming approaches as they illustrate them in practical terms (e.g. we produced a thematic analysis of country examples of community approaches to sanitation which was used to help advocate for a greater use of the approach internally and with key partners).
In short I don't believe that it's true to say that communities work and lessons databases don't but rather they should be seen as complementary approaches that can reinforce one another. But like with communities, it's not always that easy to do them successfully.
Presentation
Publications
- AAAAAAAAAAAAAA. BBBBBBBBBBBBBBBBBBBBBB
