What does lessons learned actually mean in project management?
The concept Lessons Learned deals with learning from experience. But it goes beyond that, because Lessons Learned means that the experience gained is actively and purposefully applied and used in the next project. In order to learn from experience, it is important to take a close look at the course of each project. The goal is to identify strengths and build on them, but also to identify and minimize risks, not only for the current project but explicitly for the future. So it is usually the case that a lessons-learned workshop is conducted at the end of a project. However, many fans of the method also conduct such a workshop at certain points during the project. You sometimes hear the terms "team debriefs" or "retrospectives" as synonyms for lessons learned.
Learning from mistakes and successes
You know how it is: a project is finished and you hardly have time to take a breath, because the next project is already in the starting blocks and should have started long ago. Everything back to square one. We start again from zero. But does zero really make sense? Wouldn't you rather build on experience and not make the same mistakes as in the last project? No one needs to reinvent the wheel. And this is where Lessons Learned comes in. Two aspects are important: Identifying things that went great and should definitely be used in the future. And identifying problems, mistakes, things that should not be repeated. The goal is improvement and more security in the project process.
When?
Generally speaking, at the end of a project is always a good time for a lessons learned workshop. But there are many more times that are suitable, because after all, you can't identify errors only at the end. Workshops in-between are also about securing experience, because towards the end you often no longer have everything in your head about what went really well or really badly in the individual stages - especially if it's a project that goes on for months or even years. Many experts therefore suggest organizing a workshop after each milestone has been reached. Just take a look at Scrum: There, a retrospective is also held after each sprint. It's the same principle.
Who?
Who has to be there? Well, that often depends on the type of project. In very general terms, you could put it like this: Invite everyone who can provide important feedback on the project. You can create a questionnaire and send it to a fairly large group of stakeholders and then invite only the top players to the actual workshop. Mandatorily, the project manager, the project team or at least the core team, the facilitator, and key stakeholders probably need to be invited and surveyed.
How does it work?
Again, of course, it depends on your project. How complex was it and how many stakeholders did it have? Simply asking about overall satisfaction is not enough. Make sure the following is highlighted in detail: Gather lessons learned (positive and negative). This is usually done in two phases, namely before the workshop in the form of questionnaires, which must first be developed and then also evaluated, and during the workshop. The results of the questionnaires are ideally presented by a neutral person during the workshops and then discussed together. In the case of errors and problems, the focus should be on finding out together what the causes were. There are also various methods for this, such as Ishikawa. Another topic to discuss is how the particular problem should be avoided in the future or how it should be addressed. It is best to try to define concrete measures. For particularly complex projects, it is also worth prioritizing the findings. Be sure to write minutes of the workshop so that you can refer to the results of the discussion later.
Documentation and analysis
With this protocol in place, the next aspect is already beginning to take shape: You need to document your lessons learned if you want to use them later. For example, you can summarize the results of the workshop in different documents for different audiences, not just for the participants. Relevant stakeholders might be interested in a final evaluative report, for example. Certainly, management will also want to be informed about various aspects. The analysis of lessons learned usually starts during the workshop or even during the evaluation of the questionnaires. But after the workshop, the analysis goes into deeper detail. A team meets to answer questions such as: Has experience shown that a particular major issue has emerged as a problem? Where is there a need for action? Can we define specific actions and name people responsible for them? Do general processes need to be adapted? Lessons learned may lead to minor or major changes in the following. It may be that a daily or weekly meeting is introduced, which has often proven successful. Of course, it may also be that a new job needs to be filled because it has become apparent that there is a staffing gap in an area.
One final tip: Ideally, store your lessons learned in a dedicated database so that anyone preparing a project in the future can search it, even by keyword!
One final tip: Ideally, store your lessons learned in a dedicated database so that anyone preparing a project in the future can search it, even by keyword!
Author: IAPM internal
Key words: Project management, Lessons Learned, Methods, Tools, Controlling