How to collect and present Lessons Learnt

From KM4Dev Wiki
Jump to: navigation, search

Original Message

From: Davide Piga, posted on 2011/12/02

Dear all,

This will be my first question as a knowledge manager, I am both thrilled and honored! :)

I recently started working at UNEP in Nairobi, on a KM initiative aimed at coordinating 17 programmes related to environment and climate change. The related community of practice is aimed to:

  • Promote and facilitate knowledge sharing between the 17 programmes;
  • Collect good practices and lessons learned and share them with "relevant stakeholders".

I would like to have your opinion on:

  • How to collect lessons learned. Guidelines, templates, tips, it's all welcome. Here is a template that has been designed for the purpose, but there is still some (but not much) time for improvements. So feel free to comment on it or just chip in your two cents freely. I know there was a recent discussion about the same topic with title "Templates/ tools in generating lessons learned", but it was a very short one and maybe someone has something toadd. Also, we can take that discussion to the next step, by putting on the table the second question:
  • How to present lessons learned. We are going to have a workshop in February and the idea is to start from thelessons collected by each programme, and build on them. But since there are 17 programmes and each one will have a couple of lessons to present, we don't want to end up burying participants under a mountain of powerpoint slides. So the question is, have you ever come across a particularly engaging/inspiring way to present lessonslearned? A magic format that keeps people entertained and also makes everyone realize that "wow, I can use this in my work!"?

Just to give you a little bit of context, these programmes are all bound together by the MDG Achievement Fund (more details here), a Spanish initiative aimed to accelerate progress on the MDGs. The 17 programmes are all related toMDG 7 "Ensure Environmental Sustainability", therefore the main thematic areas involved are:

  • Mainstreaming environmental issues in policy, planning and investment frameworks;
  • Improving local management of environmental resources and service deliveries;
  • Expanding access to environmental finance (carbon and other Payments for Ecosystem Services);
  • Enhancing capacity to adapt to climate change.

Given these topics, I would also greatly appreciate any suggestions on "relevant stakeholders" that you think we should get in touch with, either for collaboration or for showing them the results of the project.

Thank you very much,



All replies in full are available in the discussion page. Contributions received with thanks from:

Eva Schiffer
Hannah Beardon
Paolo Brunello
Paul Mundy
Juliana Caicedo
Charles Dhewa
Ian Thorpe
Jaap Pels
Sebastiao Ferreira
Amir Toister
Lizzie Wiltshire

Related Discussions


Preliminary Considerations

Determine the audience and objectives beforehand. That will help determine the type of material to collect as well as the content and tone.

It is always possible to find better forms or structures to express lessons learnt, but the performance of the form is not an internal feature, but a question of functionality to the purposes of the lessons. Therefore:

  1. Choose the method for collecting Lessons Learnt based on the cognitive preferences of the protagonists;
  2. Choose the format for presenting Lessons Learnt based on the needs and skills of the intended audience;
  3. Defining a purpose will define the organization of the Lessons Learnt. Key question: which is the purpose of these Lessons Learnt?


  • Be prepared to dig. The interesting material often surfaces only through a lengthy interview with a project manager or staff member.
  • Don't forget failures are a good source of learning. You should look beyond success stories.
  • Your greatest lessons may be outside your own organization. There is much to learn from external players, as internal players are often too engrossed in the game to see how else winning can be achieved.
  • Don't look at the surface, go deep down. Communities that are part of each of the seventeen players you are working with are an important source of lessons. Involve them.
  • Integrate collection of Lessons Learnt in existing reporting mechanisms. Add a request for submission of examples in any annual reports that are submitted.
  • Call for submissions - send out an appeal (can be good if there is a conference or publication at the end of it to attract people to submit, otherwise this can be a bit hit or miss).
  • Ask for reviews/suggestions from regional or technical advisors.
  • Use e-discussions to identify potential cases – take advantage of requests for advice, assistance or examples in communities of practice to identify potential good practices or lessons that can be further explored.
  • Review lessons learnt sections of evaluations - Evaluations often include a lot on lessons, but they are usually not documented in a way which is easily transferrable. Use evaluations to identify potential lessons, but then flesh them out according to the template to ensure key contextual information is included.
  • Organize documentations/self reflection sessions in the office. Use structured working sessions to have offices carry out self-reflection on a programme, preferably involving counterparts in a one-day workshop which would identify the key elements of a lessons learnt piece which could then be nicely written up. (UNICEF might have the workshop outline as they experimented this approach).


  • Visibility is a good incentive. If people know that these lessons will be published and promoted externally then this can actually be a great incentive to get people to share and will improve the quality (while it does mean it will take a little longer to get everyone to sign off – since in this case those involved will want to read carefully what has been written about their work).
  • Ask specific questions rather than asking for "Lessons Learnt". A really relevant question about aspects of a project is more motivating than a form simly asking for "lessons learnt" or suchlike.


  • Use concrete stories rather than abstract lessons. It's easier to remember concrete stories than abstract bullet points, and even if abstract lessons are applicable to most situations in the world, in fact they are not applicable to any specific situation. So generally they end up having less impact than concrete stories.
  • Be careful with templates, as they work like a sawmill: you enter trunk and you exit parquet. The richness of the details gets washed away. In order to compensate for such dissection of the real story, let the presenters be creative and use metaphors, analogies and multimedia to tell their lessons learnt. Check out this TED video for inspiration.
  • Template: make it as simple as possible not to scare people off. Consider combining similar fields to make it shorter (or make it look shorter).
  • Prefer fluid conversations to fixed templates, as they are reductive.
  • Expect a lot of wastage. A lot of stories end up being unusable for one reason or another – nothing interesting to say, lack of some vital detail, don’t fit your audience or objective, and so on.
  • Don’t try to collect too many stories. Focus on quality rather than quantity. For example, you might either ask people to complete the template, but alternatively you could just ask them to complete the “summary” part so you can get an idea whether the lesson is worth exploring further then follow up with the more interesting examples to complete the template.
  • If you want to foster mutual learning between your programmes it is not enough to document and disseminate. What you really need to do is foster a conversation between programme managers around these examples. The brief documentation of the cases is just the starting point for the knowledge sharing. One effective way of doing this might be to organize a thematic knowledge fair or workshop where participants get a chance to discuss the project experiences in more detail.


  • Professional writing skills are necessary to write good stories. Identifying and writing interesting stories takes time and skill. For external audiences, it may be worth investing in someone with journalistic skills to conduct interviews and write up stories, or to edit stories that staff have written into a publishable form.
  • KIS MII – Keep It Simple, Make It Interesting. Make stories simple and easy to understand, and tell them in an interesting way.
  • Repurpose media stories - stories that are written for fundraising and awareness raising and other types of publicity can be rewritten as lessons learnt pieces with some additional information added IF there is some substance to them. Look for those which talk about solutions and successes and dig into them to see why they are successes and if there are any real shareable lessons in them.
  • Good stories are hard to come by. Make multiple use of them if possible. Rework the same material for different media and different audiences if possible.
  • Create a wiki to host the Lessons Learnt and make them visible. Try to engage the community so that they perceive the wiki as "theirs".
  • Examples of dissemination: thematic newsletters, lessons learnt compendia (example by UNICEF), online database.
  • Use very brief presentations to open the discussion with the main points, or even have project managers present posters or stands about their lessons as an opening session, but then organize discussion in small round-table groups using approaches such as “world café” to allow a more in depth discussion. The benefits of this are that participants get to explore the cases in more detail and ask follow up questions, as well as that those that present their cases also get feedback and new perspectives on how to improve their own programmes. The added benefit is that this helps build personal relationships between people working on similar topics across the globe who might then be more likely to share knowledge with each other in future.
  • Open space is the ultimate form because whoever participates takes responsibility (and one can not not participate as to not participate is to participate too)
  • Perhaps it is best if your workshop is framed around your questions; s'ee if you can get participants to think along and feel they came up with the solutions themselves on how to collect and present their knowledge'. Just organize a couple of tables with fixed or a logical set of questions and ask one person / table to facilitate (e.g. stay at the same table) and another to report.
  • Especially if you work with grow-ups teaching / lecturing / "(im)press conferencing" is not the way to go: Group work! From "talk, show, do" towards "do, frame, talk".
  • Workshop format: World Cafe, or a Knowledge Fair:
    • Knowledge Fair each of the programmes could have a ‘stall’ with a poster and resources about their successes, and the programme reps and the stakeholders can then go around the room looking at the different posters and explaining them to each other (works better if there are a few reps from each programme, as they can take turns).
    • World Cafe you could place a very short description of the success on each table, and then groups could build on those successes by discussing them and writing their ideas on the paper table cloth. People could either be free to come and go from the different tables/discussions as they wanted, or you could have a few set times during the workshop when a group moves from one table on to the next.

You could maybe combine the two ideas, have a knowledge fair to kick off so that everyone gets a chance to see all the success stories, and then choose a few examples to use during the World Cafe to discuss more in depth. Perhaps during the knowledge fair people could vote for the success story they wanted to discuss in the world cafe, and you could print up a short version of those successes during the lunch break to use in the afternoon.

Recommended Resources