Lessons Learned represent experiences, knowledge, insights and understanding that people have gained in the course of a project. They deal with both positive and negative aspects on different levels (technical and content, emotional and social, process-related).
Especially when dealing with problems, positive as well as negative experiences are continuously collected in projects. If this knowledge can be made available to others, the probability of future project success is increased and failures and errors can be prevented.
Inhaltsverzeichnis
Method – Lessons Learned
„Lessons Learned“ is a method to systematically collect experiences (positive and negative) made in the project and to draw conclusions from them in order to improve the handling of future plans and projects. The method has become a common component of the project management methods toolbox.
The method is often referred to as project retrospective and is a classic approach to knowledge management.
Usually the method „Lessons Learned“ is carried out in the context of project completion. While the implementation of „lessons learned“ at the end of the project is more or less established, the actual use of this valuable knowledge for new projects is unfortunately still very limited.
Goals – Lessons Learned
The aim of „Lessons Learned“ is to systematically collect, consolidate and document acquired experience and knowledge and to make it accessible to employees facing similar challenges. Future project teams should benefit from these experiences and mistakes already made should be avoided. Proven methods that increase the probability of project success should be used.
- Securing the knowledge acquired through the work in the project
– Positive and negative experiences
– Technical findings
– How did the process go - Making insights from the project work visible to others
- The visualization of insights for the line organization
- The knowledge gained is an excellent basis for the (further) development of project management standards in a company, as it shows very clearly where there is potential for improvement.
Possible situations to start with
- The project has been completed and handed over to the line.
- The project is in the final phase.
- In terms of content, almost all project activities have been completed, except for a few remaining tasks.
- The atmosphere in the project team seems euphoric and relieved, since all goals were achieved as agreed, or frustrated and emotional, since something went wrong in the project.
The Right Time for Lessons Learned
Before a detailed planning for the Lessons Learned process takes place, two important questions should be asked.
- Is the right time to carry out the Lessons Learned?
- How can the implementation be optimally designed in relation to the current situation?
Since every project is unique, it is not possible to answer both questions in a general way. Basically, the decision has to be made depending on how the project has proceeded and the mood in the team over the project period has been and is currently.
In case the mood parameter indicates rather frosty temperatures, the Lessons Learned should be postponed. With a little time distance, many things can be viewed more emotionlessly. However, not too much time should pass either. As a rule of thumb, the lessons learned should be completed no more than six weeks after the project is completed.
Classically, the „lessons learned“ are collected after the completion of a project as part of the project completion documentation.
Approach & Questions
It is important to work together with the project team and other key project participants. This can be done either during the project completion or afterwards (up to a maximum of 6 weeks after project completion) by means of a workshop or individual interviews. The later development has the advantage that the employees may already see some things in a more emotionless way.
There are two questions to be asked:
- What went well?
- What went badly?
Once these two questions have been answered, concrete suggestions for improvement are developed for the points that did not go so well. These may not all be immediately implementable, but they form a good basis for continuous improvement in the implementation of future projects.
Examples of further possible questions:
- What did each individual learn for himself on the project?
- Which results are important for the line organization?
- What should be done differently in future projects?
- What should be retained in future projects?
Lessons Learned Workshop
The most common approach is to bring all relevant project participants together and to review the development process of the project together in the form of a workshop. In doing so, the experience and knowledge gained must be systematically documented. Working in a group is always a creative and joint process that automatically leads to a higher quality of results.
Workshop Preparation
- Which goals are to be achieved?
- What is to be examined in detail?
- Is the focus on the technical and content-related aspects or is reflection on the course of the process more important? Or both?
- If the social-emotional level is also to be reflected, more time must be planned.
- Coordination with the client. His ideas, wishes and suggestions should not remain unconsidered.
- Who moderates the workshop? Especially in projects where deadlines and budgets have been exceeded by far and massive tensions within the team have become transparent, moderation by an „external“ person is recommended.
- Determining who should participate in the workshop. Not only the project team, but also the project client and external project staff can contribute.
- Development of a process design for the workshop procedure. The process design can be compared to a script, in which point by point it is recorded when who has to do what and how and how much time has to be spent on it. Typical questions for reflection are:
– What went well in the project and what went less well?
– What should be done differently in project work in the future? What should or must change?
Reservation of rooms
- Organization of all supporting equipment needed for the workshop (flipchart, pin boards, beamer, moderation case, etc.)
- Preparation of an agenda, where the rough course of events with time structure can be seen.
- Timely invitation of all participants by sending the agenda. Tip: Coordinate the date in advance with those persons whose participation in the workshop is particularly important.
Workshop Implementation
The execution of the workshop depends on the design of the script. What was well thought out and planned in advance is now being implemented 1:1. Small course corrections are – if necessary – of course allowed. The following exemplary procedure has proven itself:
- Welcoming of the participants
- Presentation of the goals of the workshop, the schedule and the time structure
- Agreement on „rules of the game“ for the workshop. What is allowed, what is not. Suggestions from the circle of participants should be accepted, provided they are supportive and constructive.
- Reflection should not start until all participants have understood the task. It is important that everyone knows what to do.
- Ensure that all results are documented in a structured and legible way.
- A break should be scheduled after two hours at the latest. With coffee and a small snack, reflection continues anyway, sometimes even more intensively than in the structured units.
- When the reflection is completed, agreement on how to proceed and what happens with the results in detail.
- At the end, the group of participants should have the opportunity for constructive feedback.
Workshop postprocessing
- Photo documentation of the workshop results and creation of a photo protocol, which will be sent to all participants in a timely manner.
- Handing over the results / data material to the responsible functionaries in the company to ensure that future projects can access and benefit from the wealth of experience.
- Possible responsible organizational units in the company can be „Project Management Office“, „Organizational Department“, „Quality Management“, etc.
- If these „responsibilities“ do not exist in your company, then point out the problem to the right people and point out how much experience, knowledge and know-how for the further development of project management is lying unused in the sand here.
Useful tips and tricks from the field
- Lessons Learned should not only be carried out with the project team, but also with the project client and external project staff (possibly individually, in order to rule out mutual influence).
- The main findings should be accessible to all participants.
- Less is more: especially the things that have proved their worth and those that have gone wrong. In this way, important information can be captured at a glance.
- The lessons learned can also include recommendations for similar future projects.
- The retrievability of the results must be guaranteed, e.g. by centrally archiving the Lessons Learned of all projects (or at least a copy of them).
- If the same problems occur again and again in projects, this should serve as a reason for general, company-wide or area-wide improvement measures.
General conditions for successful lessons learned
Experience shows that three basic conditions contribute to increasing the probability that the acquired knowledge will be reusable for others:
- A corporate culture that allows you to talk openly about mistakes and problems
- A standardized procedure for the handling of projects in the company, in which the documentation of „lessons learned“ is binding
- A person or department in the company (e.g. a project management office) who is responsible for firstly collecting and documenting this know-how and secondly for using the knowledge gained from it to optimize project work
If these basic conditions are fulfilled, the chance increases considerably that information and experience from previous projects will not be turned into unearthed treasures, but that they will be used for future projects and that past mistakes will be exploited. Because mistakes are allowed – as long as one learns from them and does not make the same mistake again.
Why is the acquired knowledge so rarely used?
The „Lessons Learned“ method is relatively easy to implement. Nevertheless, this form of knowledge utilization is used very rarely. Very often no attempt is made at all to document the experience gained in the project. But even if their documentation takes place at the end of the project, it is far from being certain that the employees who urgently need this information in the future will have access to it or use it.
In very few organizations it is possible to collect and process the acquired knowledge in such a way that it is available to the employees in case of an emergency (which can often be much later). One can only speculate about the reasons for failure:
- The project team, which is supposed to collect the information, usually has no direct benefit from it, on the contrary, for the time being only additional expenses are incurred.
- There is no obligation (e.g. through company-wide PM standards) to do it.
- While people like to talk about positive achievements and results, they prefer to keep silent about negative findings.
- After often successful, sometimes relatively tedious project completion, everyone involved is glad that it’s over. The motivation to „warm up“ everything once again is extremely low.
- Even when the information is collected (a professional project manager will insist on it), the documentation often disappears into paper archives or into the infinite vastness of the hard drives of the company servers. There they are backed up daily, but nobody knows that they exist, let alone finds the information when they need it.