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:


Modern musings on a KM evergreen: institutional memory

Go on, try to Google ‘Institutional memory, KM’ and see what comes up

In the past generations of Knowledge Management, especially the first one, when all companies seemed to build the vastest database of lessons learnt and ‘best practices’ (double errrrr), ‘institutional memory’ was the holy grail.

Institutional memory, the Matroschka-like cascade of memories and assets...

Institutional memory, the Matroschka-like cascade of memories and assets…

The discourse of that KM era was all about learning organisations, as magically alive entities. Naturally, preserving the memory of those entities was just as understandable as making sure they would learn…

Let’s take a step back here : organisations themselves don’t learn. One doesn’t call organisations; and an organisation does not respond to challenges. Its people do. Similarly, organisations don’t have a memory, so much for institutional memory… But it is possible to keep traces of the past work involving members of that organisation to avoid reinventing the wheel… And that’s worth looking at more closely, something that a former KM4Dev conversation did in the past though not in a very user-friendly way for once.

Whenever a project ends, it leaves behind a certain legacy. Ditto with organisations: whether they die or not they have some assets, a legacy. What is that legacy made of?

  • Information and outputs produced
  • Expertise (knowledge and know-how)
  • A network of connections

…And of course some other resources (financial resources, physical assets etc.) which I’m not bothering about on this blog…

For each of these assets, institutional memory can be pursued by intentionally connecting personal asset bases (those of the staff) with the collective asset bases (those of the organisation).

So what makes us keep track of these resources for the benefit of all? And what are modern options re: institutional memory, given social media and other developments of the social age?

Regarding information and outputs produced:

An organisation keeps track of a rich and wide trail of information both for internal or external consumption, from legal statutes and strategies to annual reports, content publications etc. All this information ought to be well curated in a central repository, well tagged, well organised (with distributed ownership among various functions [not people], well described in internal processes and manuals, well explained at the induction or during job handover.

At ILRI we keep track of all finalised outputs using a D-Space repository for all final outputs. All internal documents are kept track of on the intranet if they are sensitive, or on the ILRI website if not. Certain teams entertain a wiki to keep track of their collective work, such as our ILRI comms and KM wiki.

At a meta level, the organisation should keep a clear description of the logic behind the information architecture and systems chosen (using open standards for easier sharing), but ultimately individuals should also play a key role in this, perhaps joining hands in mixing, where appropriate, their personal collections (e.g. of bookmarks using or Diigo, of pictures using FlickR groups etc.).

Regarding expertise:

This is perhaps the most difficult of all to keep a link with in a way or another: information can be shared and stored easily; network connections can be developed jointly and expanded to other colleagues without too much trouble. But developing capacities, know-how, the business knowledge and savoir-faire of well-oiled relations and mastering the tricks of the trade don’t come by easily.

Some conventional methods remain extremely useful: Coaching and mentoring, on-the-job training and on-the-job rotation… Even simple after-action-reviews and exit interviews are great methods to build a collective track-record of ‘how things are done here’ or how they ought to be. Though as explained in my definition of KM, these conversations need to be documented and learning-focused in order for a collective memory to withstand.

Documenting work processes and tasks at hand is helpful to let new staff find their way through the maze of procedures, protocols, tools and other options available.

A personal learning network to keep our expertise sharp

A personal learning network to keep our expertise sharp

What is new here is the plethora of conversation-documentation methods where people learn and share expertise together, such as LinkedIn or Facebook groups, of wikis (see above) and even using Twitter as a personal learning network (PLN). The trick is to ensure that the organisation allows hosting connections with its staff’ PLNs.

Regarding networks:

Networks here are understood as the personal networks of the staff members and the institutional partnerships established, and they combine the above two, mingling information and expertise. Ensuring solid memory and legacy requires working on both scales:

  • From the personal network perspective, the new grail is to focus on trimming one’s personal learning network, on expanding that network and the practices that come with it via e.g. communities of practice to nurture a very solid network that is recognised for its different layers and circles of interests (hence the interesting ‘circles’ approach of Google+).
  • From the institutional network perspective, the challenge is to cross the institutional partnerships with a curiosity for PLNs and for possible linkages across the two, by means of institutionally recognised communities of practice, of institutional participation (i.e. participation that is done formally on behalf of the organisation) in more informal networks etc. Cultivating networks of former staff such as alumni networks for universities, is another way to ensure that some connections are maintained between previous and current staff.

This primarily and most deeply happens through joint work, long term interactions, multi-faceted conversations that slowly lead to building trust. When those processes are in place, institutional memory is built up naturally, provided that there is a conscious intention to developing relations and a sort of memory base at a higher scale than the individuals alone…

In summary, essentially…

Institutional memory feeds off:

  1. Strong personal knowledge management among individual staff members,
  2. Open and loose spaces of interaction in personal learning networks, where staff can easily connect their understanding and expand the knowledge fields that they are cultivating,
  3. Deep connections and capacity development experiences where staff work together and have time to transfer to each other key clues and
  4. A will, supported by the management and all staff (by the ‘culture’ of the organisation) to make this happen and to go beyond individual interest and selfishness, team pride and even projects’ arrogance.

Though of course, in a rapidly changing world, the most important is not necessarily to keep track of the past but to predict the future, and luckily PKM, PLN and all that also prove useful…

Related blog posts:

Institutional memory (making) and learning across project silos

Every (smart) development organisation wants to be a ‘learning organisation’. It’s perhaps a doomed enterprise, or a red herring. But there is one thing that every organisation can do to reduce its silos: to learn across its various projects and programs (let’s call them projects here).

How to ensure projects share the best lessons from one another like a champagne fountain? (Credits - KievCaira)

How to ensure projects share the best lessons from one another like a champagne fountain? (Credits – KievCaira)

Developments projects are rich learning grounds, since most development (cooperation) work follows a trial-and-error process – it’s not necessarily condemnable actually.

The basic idea is that the lessons learnt at the end of the project are carried over to subsequent projects, developing the institutional memory. Perhaps it happens, but not always. Yet it could happen throughout the lifetime of projects, not just at the end – continuous institutional memory making. Remember process documentation and related approaches?

Yet that doesn’t happen much. Everyone’s too busy. Projects take time to find their own dynamics, to create their common language, to develop trust among key parties, to get all parties involved in the transformative part where they start developing greater than the sum of the parts and start thinking outside their project box.

So let’s have a shoot at learning across project silos and explore what could be useful ways to learn and share that learning…

What could be interesting ways to learn across project silos?

Usually, projects are mostly concerned with the ‘what to do’. Few are wondering about the ‘why and how’ but this is sometimes just as important, if not even more important. The what is concerned with the activities and outputs that supposedly will bring success to the project. The why connects visions, ideals, perspectives and bonds people at a deeper level. The how is what makes or breaks a project and is the architecture that conjugates concepts and visions with actions and responsibilities. What skills, methods and processes are required to achieve the project objectives.

Why is universal and important to share in order to influence the culture (and the soul) of the organisation as a whole (across its projects), it’s what helps generate principles that guide whole groups of people and generate energy. What is usually very much focused on each project and perhaps the least share-able part of a project (because we focus so much on this partly explains why we don’t spend more time sharing across projects). How is rich in lessons, ideas, capacity development tips and tricks, tutorials and materials that guide the effective implementation of activities, and it relates to other questions such as who (a critical question), when and where etc.

So what can be learnt across projects?

Why Principles, political agendas, drives and motivations of the organization, culture, soul, mission and purpose, (implied) leadership model, assumptions about impact pathways
What Activities, outputs, assumptions about impact pathways
How Conceptual frameworks and mental models, approaches, tools and methods, guidelines and tutorials to use these, identification of capacities (knowledge and know-how) necessary to achieve objectives
Who Mapping of actors, their agendas, the nature and strength of their relationship, the density of the network, who are the connectors, who are the isolated nodes, where are opportunities to reinforce the social fabric among actors
Where Spatial scales and geographic mapping of actors and their activities
When Temporal scales and pacing of actors and their actions and of influence pathways over time

So how can we effectively learn across projects?

There are a few pre-requisites that make this learning more likely to take place:

  • A conscious approach to documenting change and willing to use what has been collected to inform activities – and a place where that documentation is easily accessible for others.
  • Realising what is good to capitalise on, in a project – the unique selling point or added value of that project;
  • A flexible monitoring and evaluation framework that embeds this learning in adaptive management;
  • Good relations among project teams and a willingness to share for a wider collective benefit – be it the organisation or anything beyond.

And there are many ways we can build that cross-pollination and learning among projects:

If we made all these aspects more explicit in each project, we could organise share fairs among projects to assess how we are looking at the rationale and ideal of the project (the why-related issues), how we are thinking of relating all activities in the project’s impact pathway (the what-related issues) and how we are thinking about capacity development and concrete approaches and methods to implement the project (the how-related issues).

Simple meetings to zoom in on one aspect of the table would also help to come up with simple and concrete guidelines that bring together the experiences and insights from various projects.

Developing fact sheets about the methods and approaches used would itself help understand the how factor better.

Planning organisational retreats to zoom in among others on the ‘why’ would also inform a collective design of projects and reinforce conditions for learning across projects.

Systematic reviews of these different aspects as part of the M&E or process documentation – undertaken or shared with other projects’ proponents – could also help cross-pollinate better.

Developing project proposals that relate to the same set of issues would also help make these projects more comparable and easy to learn from one another.

Inviting another project team in another project’s workshop is another way to share across projects.

Of course, relying on people to cross-pollinate individually (as they end up working in different projects) is another way but a slower and perhaps more hazardous one – as it also requires those people to have solid personal knowledge management and to consciously carry over lessons from the past to the present and future.

So, there really many ways to learn across these projects. Now that we are conscious of what it takes, what are we waiting for?

Related blog posts: