What are Lessons Learned, what examples and phases exist, and when is the ideal time?
Using the knowledge gained
“The only mistake in life is the lesson not learned” Albert Einstein is reputed to have once said. In other words: mistakes are allowed as long as you learn from them. Lessons Learned refers to learning from experience with the aim of actively using the knowledge gained in the future.
There are many examples that show that experience and, ideally, knowledge arise through action:
- In projects, scope creep occurs; henceforth, project goals are defined, documented and communicated at the launch of the project.
- Refactoring involves additional effort; in the future, the software architecture will be analysed before coding begins.
- In requirements engineering, many unnecessary requirements are raised; with every new project, the system context is determined first.
- Users are dissatisfied with a solution; they will be continuously involved in development in the future.
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 Time 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.