The lessons I learned about lessons learned


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)

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:

  1. We took time to reflect on past experience, formulate development theories and share initial thinking with a peer group
  2. …wrote the lessons learned and debated on the issues
  3. …produced a booklet with the lessons learned and disseminated the outputs including , in some cases through national TV
  4. …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)

The crux of the matter is in the learning, not in the lesson… (Credits – Pocket full of perspective / FlickR)

Related blog posts:

5 thoughts on “The lessons I learned about lessons learned

  1. Pingback: Now It Makes Sense | Steps & Leaps

  2. Thank you all for your comments and sorry for the holiday-related delay in replying.
    @Johannes: Thanks a lot for the full summary, great job!

    @Paul: Good point – difficult to tell how concise and memorable this should be as it depends on everyone’s personal preferences, so I guess this is the reason why whatever process of collecting lessons and insights has to be closely linked with a dynamic conversation space where it can be more easily be embedded by each one as they see fit. So it relates to PKM and remains earlier said than done. One of the nudges to explore as David Griffiths urges us (http://t.co/Ic5pf6T48p)

    @Nadia: Yes, we do have to DO sthg. That’s why rather than talking about lessons learned we should talk about learning lessons (in an active mode), which again drives us back to David G’s nudges and Ian Thorpe’s comment that for starters we seldom look back at the past to dig into existing stuff. That’d be a good starting point to learn our lessons😉

    Thanks a lot for your engagement! And Paul, as you are a regular blogger, I promise I’ll also comment on your blog/website as you really do interesting work and sincerely appreciate your engagement here, on KM4Dev and in other avenues.

  3. Hi Ewen,
    Thanks for the summary and your thought. Paul referred in his comment to “LL sessions are about generating a list”. Tis reminds me on a blog post about “lessons listed”: http://www.huffingtonpost.com/kathleen-p-enright/learning-from-failure_b_3606813.html
    And a colleague and friend calls LL “lessons to be learned”. I like the two versions. I think lessons listed or lessons to be learnt can be a great resources to nurture learning. But we can not delegate leaning also not learning lessons. We have to make our hands dirty, stand in it, dig and shift… We have to DO something with the materials, apply it to our field of work and our context.
    Best, Nadia

  4. Ewen thanks for doing this – I followed the thread with a mixture of enjoyment and admiration for the amazing contributions. I guess I’d add an anecdote from a conversation that I had with Victor Newman about what caused him to develop the concept of Baton Passing as a way of passing on knowledge (and lessons). Without quoting what he said (during a reflective discussion I was using for some knowledge capture and retention work I’ve been doing for Her Majesty’s Government) the essence was that often LL sessions are about generating a list so that people feel comfortable they have things to attack at the end of the debrief (however long it is). He cited an example of some 100+ ‘learnings’ on a list which would have kept everyone going for months. It was a process therefore it had to be followed – no one enjoyed it yet no one questioned it.
    So the lessons need to be presented in a manner that is both concise and memorable and devoid of blame. Nirvana?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s