Lessons Learned – Goals, Workshop, Practical Tips

Lessons Learned represent experiences, knowledge, insights and understanding that people have gained in the course of a project. This involves both positive and negative aspects at different levels (technical content, emotional-social, processual).

Especially when dealing with problems, positive as well as negative experiences are continuously gathered in projects. If this knowledge can also be made available to others, the probability of future project success is increased and failures and mistakes can be prevented.

Method – Lessons Learned

„Lessons Learned“ is a method to systematically collect experiences (positive as well as negative) made in the project and to draw conclusions from them in order to improve the handling of future projects. The method has become a common part of the project management method toolbox.

The method is often referred to as project retrospective and is a classic approach in knowledge management.

As a rule, the „Lessons Learned“ method is carried out within the framework of project completion. While the implementation of „lessons learned“ is reasonably established at the end of the project, 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 who face similar challenges. Future project teams should benefit from these experiences and avoid mistakes already made. Proven methods that increase the probability of project success should be used.

  • Safeguarding the knowledge acquired through the work in the project
    – Positive and negative experiences
    – Technical findings
    – How did the process go?
  • Making findings from the project work visible for others
  • Visualizing insights for line organization
  • The knowledge gained is an excellent basis for the (further) development of project management standards in a company, as it makes it very visible where there is potential for improvement.

Possible scenarios

  • The project has been completed and handed over to the line.
  • The project is in the final phase.
  • Almost all project activities have been completed, with the exception of a few remaining tasks.
  • The atmosphere in the project team seems euphoric and relieved, because all goals could be reached as agreed or frustrating and emotional, because some things went wrong in the project.

The Right Time for Lessons Learned

Two important questions should be asked before detailed planning for the lessons learned is carried out.

  • Is the time right for the lessons?
  • How can the implementation be optimally designed in relation to the current situation?

Since each project is unique, both questions cannot be answered in general. Basically, the decision depends on how the project went and how the mood in the team was and is present over the course of the project.

If the mood parameter indicates frosty temperatures, you should wait until the lessons learned have been carried out. With some distance in time, many things can be viewed more emotionlessly. However, not too much time should be allowed to pass. As a rule of thumb, a maximum of six weeks after project completion, the lessons learned should also be collected.

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 take place either within the framework of project completion or afterwards (up to 6 weeks after project completion) by means of a workshop or individual interviews. The advantage of the later elaboration is that the employees may see some things more emotionless.

Two questions have to be asked:

  • What went well?
  • What went badly?

Once these two questions have been answered, concrete suggestions for improvement are worked out for those 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 at one table and to review the development process of the project together – in the form of a workshop. The experience and knowledge gained must be systematically documented. Working in a group is always a creative and joint process that automatically leads to higher quality results.

Workshop Preparation

  • Which goals are to be achieved?
  • What is to be examined in concrete terms?
  • Is the focus on the technical aspects or is the reflection of the process more important? Or both?
  • If the social-emotional level is to be reflected as well, more time must be allowed for.
  • Coordination with the client. His ideas, wishes and suggestions should not remain unconsidered.
  • Who will moderate the workshop? Especially in projects where deadlines and budgets have been far exceeded and massive tensions in the team have become transparent, the moderation by an „external“ is recommended.
  • Determining who should participate in the workshop. Not only the project team, but also the project client and external project staff can make a contribution.
  • Development of a process design for the workshop process. The process design can be compared to a script in which it is recorded point by point when who has to do what 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 premises
  • Organization of all supporting tools needed for the workshop (flipchart, pinboards, beamer, moderation case, etc.)
  • Creation of an agenda, where the rough process with time structure is visible.
  • 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 implemented 1:1. Small course corrections are – if necessary – of course allowed. The following exemplary procedure has proved its worth:

  • Welcoming the participants
  • Presentation of the goals of the workshop, the process and the time structure
  • Agreement on „rules of the game“ for the workshop. What is permissible, what is not. Suggestions from the circle of participants should be accepted as long as 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. Reflection continues anyway over coffee and a small snack, sometimes even more intensively than in the structured units.
  • Once the reflection is complete, we agree on how to proceed and what will happen with the results in detail.
  • Finally, the participants should be given the opportunity for constructive feedback.

Workshop Postprocessing

  • Photo documentation of the workshop results and creation of a photo protocol, which will be sent out to all participants promptly.
  • Transfer of the results / data material to the responsible functionaries in the company to ensure that future projects can access the wealth of experience and benefit from it.
  • Possible responsible organizational units in the company can be „Project 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 draw attention to how much experience, knowledge and know-how for the further development of project management runs 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 each on their own to avoid 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.
  • Lessons learned may also include recommendations for similar future projects.
  • The retrievability of the results must be guaranteed, e.g. by central archiving of the lessons learned from 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 or division-wide improvement measures.

Framework conditions for successful lessons learned

Experience has shown that three framework conditions contribute to increasing the probability that the acquired knowledge will also be reusable by 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 the „lessons learned“ is bindingly specified.
  • A person or department in the company (e.g. a project office) who is responsible firstly for collecting and documenting this know-how and secondly for using the findings to optimise project work.

If these basic conditions are fulfilled, the chance increases considerably not to let information and experiences from earlier projects become unearned treasures, but to use them for future projects and to profit from past mistakes. 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 apply. Nevertheless, this form of knowledge use is very rarely used. Very often no attempt at all is made to document the experiences gained in the project. But even if their documentation is made at the end of the project, it is far from certain that the employees who urgently need this information in the future will have access to it or will use it.

In very few organisations it is manageable to collect and process the acquired knowledge in such a way that it is available for the employees in case of need (which can often be much later). One can only speculate about the causes of 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 so.
  • While people like to talk about positive achievements and results, they prefer to keep silent about negative findings.
  • After often successful, sometimes also relatively laborious project completion, all participants are glad that it is over. The motivation to „warm everything up“ again is extremely low.
  • Even if the information is collected (a professional project manager will insist on it), the documentation often disappears into paper archives or into the infinite expanse of the hard disks of the company servers. There they are backed up daily, but no one knows they exist, let alone find them when they need them.