Another one of these fascinating KM4Dev conversations that flares up without notice – or perhaps prompted indeed by this great title ‘Lessons Learned – The Loch Ness monster of of KM‘.
When will we know what to do with our lessons? (Credits – Notionscapital/FlickR)
The conversation initiated by Johannes Schunter from UNDP elicited a great many fascinating responses about another one of KM evergreens (along institutional memory) – some of these came after I drafted this post.
Johannes’s original question was:
Would you know of any good paper, research article or other evidence that looks at this in a comprehensive way and supports the conclusion that collecting lessons learned documents in a database might not be smart KM?
Fair enough a question… Here is a selection of my personal favorite replies about lessons learnt (LL) databases // and my personal reactions to these:
Our problem owner is alluding to the traps of LL databases. The essential problems with such databases is that:
- On the one hand, they are still seen by some as an end (the typical first generation KM trap)…
- On the other hand, they relate to an essential behavioural problem that our species faces:
Getting people to actually use knowledge that is already available is a behavioural challenge in general (I. Thorpe)
Now, assuming learning lessons is still a valuable thing to pursue and codify in some way, what really makes a lesson learnt? A lesson is only learnt if it is applied. “Knowledge needs action and effective use to realise it’s potential” (N. von Holzen) // though sometimes the proof of the learning is not only in the action but in the discourse, the attitude, the thinking and guiding principles that command our actions, before there is any opportunity for action.
But what makes a lesson learnt really interesting? “replicability, evidence, and context” states D. Piga as, he continues “there is no lesson learned that is worth reading if the experience described in it isn’t replicable.” To which Stephen Bounds responds that, on the other hand, “understanding the bias and prejudices of the person or people reporting gives readers a much more powerful sense of the thinking process involved. This provides a much stronger context for critical evaluation of the material presented, as well as a stronger narrative involvement in the actual course of events.” // So a yes to qualifying who came up with the story, in what context, but striving for the universal lessons at the same time? I tend to stick to the personal angle, as universal tends to mean ‘lowest common denominator’, like a bad Hollywood remake of an excellent national film.
Ian Thorpe argues that LL databases are just one element in a broader KM strategy including events, communities or practice etc. The database lessons are then more of a prelude to a deeper conversation. Interestingly he also points to other uses: as field examples for advocacy publications, as thematic analysis and planning resources, as ‘evidence’ that something is happening, as case studies for internal advocacy, to push a new way of working. // Excellent reflections – the question is ‘how much effort do you want to put into this database as opposed to other KM approaches and tools, and for what purpose really? Those hard questions help find a better fit.
Ok, so what can be done specifically about lessons learnt databases?
Eric Mullerbeck suggests adding “‘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, without them having to do anything more than sign up to get the updates.” Pete Cranston adds: “perhaps we need a collection of personal stories on success and failure”. This echoes Robin van Kippersluis’s plea to process lessons at different levels in an integrated way – as a “true learning organisation” would do – and with a view to track evidence // Indeed compelling ideas that might enhance the effectiveness of such databases, or certainly the drive to structure them better, with a clearer view to satisfying donors.
What you do with the lessons again affects the chances of success of using the database. Thiendou Niang summarises the steps he and his team took to make best use of lessons learnt in a project in West Africa:
- We took time to reflect on past experience, formulate development theories and share initial thinking with a peer group
- …wrote the lessons learned and debated on the issues
- …produced a booklet with the lessons learned and disseminated the outputs including , in some cases through national TV
- …used the lessons learned in debate, policy influence and resource mobilization. // To me that sounds about right, perhaps not perfect but here’s a good example of knowledge ‘just in time’ (not just in case) with a purpose to using the lessons, not just to storing them. Rinko Kinoshita also shared his example of linking the LL database with a newsletter to garner more momentum and interest around the lessons.
Perhaps indeed lessons learnt databases will never satisfy our needs and so be it – because learning and knowledge are and remain transient, fluid, Behind all of this, Eva Schiffer ponders:
How can you codify the time people need to spend in the shower each day to have good ideas, how can you standardize, make controllable, create and attribute the culture change you need for a vibrant knowledge sharing organization?
Or perhaps as Ian Thorpe enquires, we might settle for a mixed solution of high-end, rather expensive LL databases combined with cheap but rich self-reflection, using the “personal insights of those people managing the project about how it works on the ground, interpreted through their experience.” Self reflection is at the heart of Rinko Kinoshita’s final comment, that:
We cannot neglect the effects on the LL producers’ side (…) the process of documenting enabled them analyse and self reflect on their own experiences- there is a key learning here.
// Now that’s a compelling idea. Perhaps pushing this even further, the lessons learnt database could be indeed combined with ongoing conversations leading back to the database, adding new insights as conversations go along. In a way the KM4Dev wiki is a very good example of a lessons learnt database that kinda works: a conversation happens, it gets documented (including the lessons and cases), it is stored there, someone else later comes back to the topic and updates the wiki entry or adds another one in relation…
What I learnt about lessons learnt is that we have much to learn about them still, that they work in combination with other means – information and knowledge, tacit and explicit, people and technology – that they are a beginning, a process and an end result, that they can serve various purposes other than learning, that they affect the storyteller and the reader, and that we will be trying to fetch these lessons for a long time still, but the solution lies with the learner and his/her (collective) learning, not with the lesson itself… We might want to talk about (continually) ‘learning our lessons’ rather than what to do with our lessons learnt’…
The crux of the matter is in the learning, not in the lesson… (Credits – Pocket full of perspective / FlickR)
Related blog posts: