The “Duh-test”, or what is not a lesson learned

I was recently reviewing a number of texts which my organization collected from past projects and initiatives (some through an internal mandatory monitoring tool, others gathered as part of After Action Reviews or Lessons Learned Papers), which all meant to capture ‘lessons learned’ from specific experiences.

And while these texts were not wrong per se, I realized that there seems to be a fundamental misconception what constitutes a good lesson, and what doesn’t. Here are a few typical examples of what we often collect as part of such lessons learned exercises:

• “Ensure that the [Team] Manager has excellent leadership, project and team management skills, understanding of programming and experience working in [the subject matter].”
• “Project outputs must be compatible towards project goals. Throughout the project there is a need for careful identification of project goals and outputs to ensure that they are compatible with each other. This can be only ensured through a consultative and participatory approach in project design with target institutions, implementing partner and experts.”
• “Managing relationships between key national and international players during [the project activity] is very important. Recognizing and respecting national ownership and leadership of the process is vital and key to winning the trust of the national authorities.”
• “The better local authorities are involved in the process, the better the expected results are easily achieved and durable.”

The above examples are representative for a common type of lessons learned write up, which fails to pass what I would call the “Duh-test”:

If a ‘lesson learned’ statement is so obvious that it is self-evident to every reader, and at the same time so generally applicable to almost any type of project or initiative, it basically becomes meaningless.

It is good when a team realizes that it failed to put in place a team leader who has leadership and team management skills (and yes, it should remind itself do better next time), but there is literally no value in sharing that learning point with others outside the team, simply because everyone already knows that this should always be a criteria for selecting team leaders. There is nothing new to learn here that would change anyone’s views or actions.

Also, if a lesson is so generic that it could apply to any scenario, we deprive ourselves of the learning effect that comes from understanding the particular conditions responsible for making your project work or not work, so others can go and try to replicate or avoid those conditions.

Such lessons that are either too obvious or too generally applicable produce ‘lessons learned noise’ because these same lessons are reported from countless projects over and over again, without anyone actually learning from them. At the same time, this noise detracts everyone’s attention from the meaty lessons learned pieces that really provide value to a wider audience.

So what is it that makes lessons learned write-ups actually add value? Maybe asking ourselves the following three questions could help make lessons learned statements worth capturing and sharing:

1. Will anyone else actually learn something new from this lesson, as opposed to self-evident truths that everyone usually already knows?This is the “Duh-test” and should always be the first criteria.
2. Is this lesson particularly relevant to your specific situation, as opposed to a lesson that it so general that it would apply to any scenario?The more general a lesson is, the less useful it is.
3. Does the lesson include or lend itself to a concrete action that you or someone else can take in order to effect a change in future practice? Capturing a lesson is only meaningful if there is an actual change triggered by it

But aren’t the ‘bad’ examples mentioned earlier still true and important to highlight, even if they are not particularly new or context specific? Doesn’t the fact that everyone agrees to them intuitively and that they apply to all our projects and initiatives all the more valuable?

Absolutely! But I would never call them ‘lesson learned’. Rather, these are important principles that anyone should abide by, no matter what subject matter expertise or functional roles someone has. We should treat them as guiding lights for our work, teach them in our training curriculae, communicate them our onboarding and induction sessions and embed them our policy guidance.  Some lessons from projects, if they are collected often enough, might eventually be added over time to such a common canon of principles. But we should stop collecting what is already part of that canon over and over again from individual projects, which is no good use of anyone’s time.