What are lessons learned?
Lessons learned are the knowledge gained from doing something: what to repeat because it worked, and what to change because it did not. Captured well, they stop an organisation from paying twice for the same mistake, and spread good practices from one team to the next. Captured badly, they become a file nobody opens. The difference is a clear recommendation and someone responsible for applying it.
Running a lessons learned session
- Prepare: share the project goals, timeline and key data before the session.
- Collect: let everyone write what went well and what to improve, silently first.
- Discuss: group similar points, understand why things happened, avoid blame.
- Recommend: for each lesson, agree what future projects should do.
- Follow up: assign owners to change templates, procedures or checklists, and track until done.
Lessons learned example
The team behind the first phase of an eQMS implementation holds a retrospective. Four things went well, including involving super-users from every shift and the vendor validation package, which saved about six weeks. Five things should be done differently. The highest-impact ones are data migration, which took three times longer than planned, and change requests that were not assessed for validation impact. Each improvement gets a recommendation; two are already done (a validation impact check on the change request form, report requirements agreed in the design phase), three are open, and one still needs an owner.
Tips
- Hold the session soon, before people move on to other work.
- Balance the columns: successes are lessons too.
- Write recommendations as actions ("add X to the template"), not observations.
- Dig into the causes of the biggest issues with 5 Whys, and feed the recommendations into the next PDCA cycle.
How to use this Lessons Learned tool
- Describe the session. Enter the project or event, the date and the participants.
- Capture what went well. Click + in the left column to add what worked and should be repeated.
- Capture what to improve. Click + in the right column to add what should be done differently.
- Categorise and rate. Click a card to set its category and impact.
- Make it actionable. Write a recommendation for each lesson and, for improvements, an owner and follow-up status.
- Export and share. Export the board and register to PDF or Excel and share them with future project teams.
Frequently asked questions
What is a lessons learned session?
A lessons learned session (also called a retrospective, post-project review or after-action review) is a structured meeting at the end of a project or phase, or after an event, where the team reviews what went well and what should be done differently, and turns those insights into recommendations for the future.
What questions should a lessons learned review ask?
What did we set out to do? What actually happened? Why was there a difference? What went well that we should repeat? What should we do differently next time? Who will make sure the recommendation is applied?
Why do lessons learned often fail?
Because they are recorded but not applied: a document is filed and the next project makes the same mistakes. A lesson is only learned when it changes a template, a procedure, a checklist or a plan. That is why this tool asks for a recommendation and, for improvements, an owner and follow-up status.
When should lessons learned be captured?
At the end of each project phase, not only at the end of the project, when memories are fresh and the team is still together. Also after significant events such as a major deviation, a recall or an audit.
Who should take part?
The core team plus key people from outside it: users, suppliers, the sponsor. A neutral facilitator helps keep the session focused on learning rather than blame.
How do lessons learned relate to ISO 9001?
ISO 9001:2015 clause 7.1.6 requires organisations to determine, maintain and make available organisational knowledge, including lessons learned from failures and successes. A lessons learned register is a common way to meet it.