Lessons Learned Template
What to repeat and what to change, written down while anyone still remembers.
Details
lessons learned templateUploads
Your logo
A photo or picture
Goes on this page only. Drag it anywhere and pull its corner to resize it.
Your signature
Draw it with a finger, a mouse or a trackpad, and it goes on the page like a picture.
Pictures and signatures stay on this device. Nothing is uploaded to a server.
Red highlights mark what is still blank. Click anything on the page to change it. Your draft is kept on this device as you work.
| Project | [project] |
| Project manager | [project manager] |
| Closed on | October 14, 2026 |
1. What to repeat
[add one per line]
2. What to do differently
[add one per line]
3. What changes as a result
| Change | Owner | By when |
|---|---|---|
| [add one change per line] |
What is a Lessons Learned Report?
A lessons learned report captures what worked, what did not, and what should be done differently next time, written while the people involved still remember the detail. It matters because the same problems recur: the estimate that ignored testing, the approval that always takes three weeks. Without a written record and an owner for each change, the knowledge leaves with whoever leaves, and the next project pays for it again.
Project teams write one at closure or at the end of a phase, and the most useful ones are written at both, because a report produced six months after go-live is largely reconstruction. Event organisers, construction teams, grant-funded programmes and software teams running retrospectives all do a version of it. Funders and programme offices sometimes require one before a project can be formally closed. It is also worth writing after a near-miss, which is the cheapest possible moment to learn something.
Where the review touches a safety incident, a data breach, a clinical event or a regulated failure, there is usually a separate mandatory report with its own deadline — notification to a data protection supervisory authority, a workplace safety regulator or a sector regulator — and a lessons learned exercise does not satisfy it. Check the reporting deadline first, because some are counted in hours rather than days. Where legal liability may arise, take advice before circulating a document that assigns cause, since the rules on privilege differ by jurisdiction.
A lessons learned report is not an incident report and not an investigation. It does not establish cause for the purposes of a claim, and it should not be used to allocate blame — the moment it does, the next one will be written carefully and truthfully by nobody. It also changes nothing by itself. Until a checklist, a template, an estimating model or a contract clause has actually been amended, the lesson has been noted rather than learned.
What to put in a Lessons Learned Report
These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.
| Field | What goes in it |
|---|---|
| Issuing organisation | For example: Maple Grove Homeowners Association |
| Organisation address | For example: 1420 Kinnear Road, Columbus, OH 43212 |
| Project name | For example: Barton Road trade counter fit-out |
| Project manager | For example: Sarah Chen |
| What to repeat next time | One per line |
| What to do differently | One per line |
| Actions | One per line: Action | Owner | By when |
How to write a Lessons Learned Report
Fix the scope and the facts first
Start with a short factual timeline everyone can agree on: baseline dates against actuals, budget against outturn, scope changes with dates, and the significant events. Do this before collecting opinions. Half the disagreement in these sessions comes from people working off different recollections of the sequence, and a shared timeline removes it in ten minutes rather than an hour.
Ask what went well before what went wrong
Run the positive question first and give it real time. Teams that skip it produce a document that reads as a complaint and gets filed unread. It also surfaces practices worth making standard, which is the half of the exercise most reports miss. Write each one specifically: 'the two-hour supplier workshop in week one removed three assumptions' beats 'good communication'.
Separate what happened from why
For each problem, write the observation and the cause as separate fields. 'Testing overran by three weeks' is an observation. 'Test environments were requested after design sign-off and provisioning takes four weeks' is a cause you can act on. Keep asking why until you reach something the organisation controls — a process, a template, a decision point — rather than a person or bad luck.
Turn each lesson into an owned change
A lesson with no owner is a paragraph. For each one, name the specific artefact that changes: add the environment lead time to the planning checklist, adjust the estimating template, amend the standard contract clause, change the induction. Name the person who will make that change and the date it is due. Then track those items where they will be chased, not inside the report.
Put it where the next team looks
A report filed in a closed project's folder will never be read again. Push the changes into the documents people already use — templates, checklists, the risk library, the standard schedule — and keep a short searchable register of lessons tagged by project type. Reading that register should be an item on the initiation checklist for the next project, not an act of unusual diligence.
Common mistakes
- Holding the review months after closure, by which point the people who could explain the decisions have moved on and the account becomes reconstruction.
- Letting the session become an attribution of blame, which teaches everyone present to be less candid in the next one.
- Recording lessons as generalities such as 'communicate better', which cannot be acted on and quietly excuse the specific failure underneath.
- Producing recommendations with no owner and no date, so the report is accepted, filed, and changes nothing at all.
- Treating the review as a substitute for a mandatory incident notification, which can leave a regulatory deadline missed while the organisation believes it has responded.
Frequently asked questions
When should a lessons learned session be held?
Within a fortnight of closure or of the phase ending, while the detail is still retrievable. On projects longer than a few months, run interim sessions at each phase gate too, because a single session at the end is dominated by whatever happened most recently. After a near-miss, hold it immediately — willingness to talk fades quickly once the crisis has passed.
Who should attend a lessons learned review?
The delivery team, the business owner who now runs the result, and someone from each function that was a dependency — procurement, finance, IT, legal. Invite the sponsor for the closing summary rather than the whole session, since seniority in the room suppresses candour. A neutral facilitator, ideally not the project manager, will get more out of it than the person being reviewed.
What is the difference between a lessons learned report and a retrospective?
A retrospective is short, frequent and team-owned, run at the end of each iteration to change how the team works next week. A lessons learned report is produced at the end of a project or phase and is aimed at the organisation, not just the team. They serve different loops and are not substitutes: teams running retrospectives still owe the wider report.
How long should a lessons learned report be?
Two to four pages plus an actions table. The value sits in the actions rather than the narrative, so keep the background short and put supporting detail in an appendix if anyone needs it. A ten-page report is read once, by its author. What people genuinely reuse is a searchable register where each lesson is one line with a link.
How do you get people to be honest in these sessions?
State at the start that the output describes systems and decisions rather than individuals, then hold to it in the write-up. Collect written input beforehand so quieter people are represented. Do not have the person whose work is under discussion facilitate. Most importantly, show the actions from the last review being implemented, because nobody invests candour in an exercise that changes nothing.
This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.