What is Lessons Learned?

Phases in Lessons Learned

The examples show that lessons learned often refer to organisations – companies, committees, teams, etc. The term is often used in the context of projects, in the course of developments, or when making decisions. But individuals also learn from their experiences. Albert Einstein is said to have once said “The only mistake in life is the lesson not learned”. But how can individuals and organisations learn from their experiences? This happens in three phases:

• The identification of the lesson, also known as Lessons Identified.
• The analysis of the lesson, also known as Lessons Analysed.
• The learning of the lesson and thus the actual Lessons Learned.

Before individuals and organisations can benefit from their experiences, these experiences must be identified as such. What were the problems with a project? What worked well or less well in a project? Are there any potentials for improvement? Individuals and organisations can learn from both positive and negative experiences.

Identification is followed by analysis. Why did something work or didn’t work? What were the underlying conditions? How was the setting, the communication, the motivation, the tooling? The analysis of the experiences is important in order to learn from them as an organisation and/or individual and to transfer them to comparable situations, challenges or projects.

When actively learning from situations, it is important to document the findings and to store them in such a way that they are easily accessible for all concerned in the future. A mere filing in the intranet is easily overlooked in an upcoming project. It is better, for example.

• to work with checklists,
• optimise and provide document templates,
• support good practices and process steps with software tools,
• and possibly even concrete activities to deal with lessons learned previously documented in the project plan.

The Moment for Lessons Learned

An essential criterion for lessons learned is the time at which the participants get together to identify valuable experiences, analyse them and learn from them. In this context there is, for example,

• the project review as a review of a project or a project phase, and
• the retrospective that is performed at the end of a sprint in Scrum.

Both formats are less about the results achieved and more about the way in the work was conducted. It is about challenges and opportunities for improvement. Depending on the format used, the following aspects are collected:

• things that worked well,
• things that didn’t go so well,
• things to stop right now,
• and aspects that should be tried out.
  to hold on to.

Thus, retrospectives and project reviews differ significantly from code reviews or sprint reviews, which are more about evaluating work results than about collaboration.

In the case of lessons learned – e.g. in the course of a project review – it is important to avoid mistakes. A procedure may prove to be wrong afterwards, but individuals and organisations can only learn from it if the required information was known at the time of the decision. The shorter the time gap between experience and knowledge, the less likely it is to lead to a backward error. In addition, early lessons learned sessions offer the opportunity to use the knowledge gained already in the current project or ongoing development.

Challenges with Lessons Learned

In practice, it can be observed time and again that there are also challenges in dealing with lessons learned in organisations:

• It can happen that at the end of a project it “has run out of steam”, i.e. only a few employees feel the desire to actively learn from the recent past. Interestingly, this can be observed especially when projects have taken a relatively long time and/or the perceived cooperation did not go well.
• Especially at the end of a project, dealing with lessons learned is not perceived as an advantage. Projects are by definition temporary and one-off, so why should the lessons learnt benefit future temporary and one-off projects?
• Using the experiences of others feels “unusual” to some staff. So in a way, lessons learned have an image problem.
• There are projects that suffer from staff with too much self-confidence. From this position, lessons learned from other projects are simply rejected.
• And last but not least, the additional effort – at the end of a project or at the beginning of a new project – is shied away from. This is especially the case at the beginning of projects when resources are lacking, the project start should ideally have taken place yesterday or the management places little value on actively dealing with previously gained insights.

How do you manage in your organisation to remember lessons learned and use them concretely?

Notes:

Learning from experience is a principle in PRINCE2, the British project management method. The collected findings, risks and problems encountered, improvements and ideas are recorded in the so-called experience log. In the PMBOK Guide, the documentation of experiences is a task in the process “Completing a project or phase”. And in the Indiviudal Competence Baseline, the IPMA competence standard, the documentation of lessons learned takes place, among other things, during the project completion analysis.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you will find additional information from our Smartpedia section:

What does t2informatik actually do? One click and you know.