Skip to content

Lessons learned

01st August 2017

By Rod Sowden

In general, lessons learned are rarely actually learned. Research and general knowledge about what causes programme and project failure has abounded for years, yet the same things keep happening. So, what can we do to help?

For the last 20 years in the UK, the world of best practice (originated by the UK government) has illustrated the issue. We wrote Managing Successful Programmes (MSP) on the assumption that audiences already had experience of programme management, understood programme management, and wanted to improve. The reality is, however, that people who take the course are new to the topic, spend a week studying to pass an exam, and then never consider it again.

The work of P3M3 has shown that although the knowledge has been absorbed temporarily for the examination, it's not sufficiently understood to enable deployment in the real world. The courses are attended by inexperienced individuals, who are unable or unauthorized to deploy the knowledge that they have gained in their working environments.

What is a lesson learned?

'Lessons learned', as a term, is part of the problem, as it assumes that someone is teaching and someone is listening, and that the learning is being validated. This clearly doesn't happen; instead, it has become an overused cliche that covers a range of issues, including:

  • Generic statements about what happened, often covering the blindingly obvious that underestimates or overestimates the audience
  • Something that the author wants to boast about to promote themselves
  • Brain dumps of random information that makes little sense to others
  • Statements that are too complex for the audience, or are unique to a specific scenario
  • Reflective lessons for the host, not advice or guidance for others, which lacks meaning to the listener.

Why do we fail to learn from the past?

What is happening is that people are trying to share experiences, often with an unknown audience. The problems that face programmes and projects are common, but the ways to deal with these problems can vary, depending on the context and capability of the team.

When lesson sharing is undertaken face to face with the right audience, it is likely to work. Here are some ideas about why this is such a challenge:

  • Lessons are written at the end, rather than at the time, so can become out of date very quickly.
  • Lessons are written generically, with little thought for the audience, and as a self-glorifying brain dump
  • Individuals have little incentive to learn from the past, as organizations value heroism, and in particular, heroic avoidance of failure. Organizations' cultural values: do they value the heroic innovator over the systematic analyst?
  • Critical information is hidden in long wordy documents, so can't be found
  • The knowledge has to trigger some emotional relationship to a personal experience to be able to stimulate the recognition of value
  • Unconscious incompetence: if people don't know what they don't know, they will not value advice from others, as it appears out of context. People who can benefit from the lesson are often not listening or incentivized to listen, and the reward process doesn't encourage them to research them
  • People have biased views, dependent on the source of the message
  • Teams want to copy rather than create, thus they repeat the mistakes of the past
  • Knowledge management only works in mature organizations or teams; the ability to acknowledge, disseminate and act on lessons is characteristic of high maturity
  • The valuable nugget is rarely the lesson documented, it is a small piece of insight that, when connected to other information, generates the valuable piece of knowledge. It is very difficult to design a process to handle this.

The core of the problem is that organizations do not value knowledge and, in general, have no knowledge management strategy as such, it is a peripheral activity. When it is done, it is often seen as a routine piece of bureaucracy, rather than a critical, value-adding activity. Accountability for knowledge development and deployment is rarely defined.

Magnificent seven: our tips for improvement

Based on our observations from various pieces of recent work, here are our six tips to improve the way that you manage your knowledge sharing in the future:

  1. Knowledge is fragile - it can be easily lost with a resulting impact on organizations, so it should be regarded as a risk
  2. Knowledge should be put into context - often it is as important to understand the context within which the lesson was learned as the lesson itself, e.g. the insight may only be of value in certain situations and can't be applied widely
  3. Knowledge should be 'showered', namely, lots of sound bite nuggets may be picked or register an idea that may become valuable at a later date, or in a different context to which the 'receiver' is operating at that moment.
  4. Focus on the audience - vary channels to find them. We know that we learn and listen in different ways (neurolinguistic programming for example), so the broadcast channels need to reflect this. The approach of one-dimensional documents in a digital world is outdated and ineffective
  5. Incentivize individuals to reuse - very few organizations reward the deployment of experience, which means that there is no incentive not to reinvent the wheel. High-calibre teams tend to focus on problem-solving through invention, rather than research. Belbin team roles theory is relevant to this, as over-reliance on certain team types will create different effects
  6. Nurture the role of human capital - knowledge moves around within the heads of individuals and teams. New people joining the teams have access to this knowledge, and people leaving the team take it with them to other teams. The Tuckman model for team performance illustrates how knowledge and relationships mature; the 'reforming' element of the model reflects the need to share knowledge with the new member
  7. Improve the knowledge curation - the specific management of knowledge in and out of the organization should have ownership and be incentivized to deploy. Once ownership is defined, a strategy that fits the organization can be developed.

If just one word from this article triggers a thought or an idea that improves your performance at any time in the future, then it will have been worthwhile.

About the Author

This article has been written by Rod Sowden, Managing Director of Aspire Europe Ltd and Lead Author for MSP® and P3M3® and author of a number of other books on how to deploy programme management effectively.

Aspire Europe specializes in supporting organizations to deliver their performance improvement strategies.

MSP® and P3M3® are [registered] trademarks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

Agility Linked-In profile Twitter

Website created and managed by TSO information and publishing solutions