Project Management guide · Risk, quality and control
Lessons Learned in Project Management: Guide and Examples
Lessons learned in project management are the knowledge a team gains about what worked well and what should be done differently, recorded so the same project and future ones can act on it. This guide shows you when to capture lessons, how to run a lessons learned session, which questions to ask, how to write a useful lesson and how to make sure lessons actually change practice.
Key takeaways
- A lesson learned explains what happened, why, what effect it had and what to do next time.
- Capture lessons throughout the project, at phase ends and after major events, not only at closure.
- Run sessions that focus on processes and decisions, not blame, and agree an owner for every recommendation.
- Keep lessons in a register during the project and move them to an organisational repository at the end.
- A lesson is only learned when it changes a template, checklist, plan or habit on a later project.
What are lessons learned in project management?
Lessons learned are the documented knowledge gained during a project about what went well, what went badly, why, and what should be done differently in future. A good lesson is specific enough that someone who was not on the project can act on it, and it ends with a clear recommendation.
Lessons can be positive or negative, and both matter:
- Positive lessons record practices worth repeating, such as a supplier review routine that caught defects early.
- Negative lessons record problems, their root causes and how to prevent them.
- Recommendations turn each lesson into an action for the current project, future projects or the organisation's methods.
There is an important difference between a lesson identified and a lesson learned. Writing 'testing started late' in a spreadsheet identifies a lesson. It is only learned when a later project plans testing differently because of it. Most of the effort described in this guide is about closing that gap.
Why lessons learned matter
- Better estimates: actual durations and costs from past projects improve future cost estimation and scheduling.
- Fewer repeated problems: known risks can go straight into the next project's risk register.
- Repeatable successes: good practices spread beyond the team that discovered them.
- Faster onboarding: new project managers can learn from the organisation's history rather than from scratch.
- Improved methods: a PMO can update templates, checklists and standards based on evidence.
- Stronger team culture: a well-run review shows that raising problems is welcome, which makes future reporting more honest.
Lessons also support project governance: a decision log and the lessons drawn from it give sponsors and boards an evidence base for approving similar projects.
Lessons learned register, repository, log and report
Different methods use different names for the documents. This table shows how they fit together.
| Term | What it is | Where it comes from |
|---|---|---|
| Lessons learned register | A project document that records lessons as they are identified during the project | PMBOK Guide sixth edition (output of Manage Project Knowledge) |
| Lessons learned repository | The organisation's searchable store of lessons from many projects | PMBOK Guide sixth edition (part of organisational process assets) |
| Lessons log | The PRINCE2 record of lessons during the project; in PRINCE2 7 it is one of the records in the project log | PRINCE2 |
| Lessons report | A PRINCE2 report that passes lessons on, at the end of a stage and/or the end of the project | PRINCE2 |
| Lessons learned report | A general name for the summary written at project or phase closure | Common practice |
In the PMBOK Guide sixth edition, lessons are recorded in the register throughout the project and transferred to the repository when a phase or the project closes. PRINCE2 makes 'learn from experience' one of its seven principles, which means looking for lessons at the start of a project as well as recording new ones. Whichever terms you use, the pattern is the same: capture during the project, share at the end, reuse at the start of the next.
The lessons learned process
- Identify: spot lessons as they happen, in reviews, status meetings and retrospectives, and at the end of each phase.
- Document: record each lesson in the register with its context, impact and evidence while the details are fresh.
- Analyse: find the root cause, not just the symptom. A fishbone diagram or the 5 whys helps.
- Recommend: write a specific action with an owner and decide whether it applies to this project, future projects or the organisation's standards.
- Share and store: move validated lessons into the organisation's repository with consistent categories and tags so they can be searched.
- Apply and check: review relevant lessons when starting new projects, and check later that recommendations were actually implemented.
Steps 1 to 4 belong to the project team. Steps 5 and 6 usually need a PMO or another owner outside the project, because the project team will have moved on.
When to capture lessons learned
| When | Why it works |
|---|---|
| Throughout the project | Details are fresh, and lessons can be applied straight away in the same project |
| At the end of each phase or stage | A natural pause to reflect before the next phase starts |
| After a major issue, near miss or success | Evidence is available and root causes are easier to find |
| At sprint retrospectives | Agile teams already reflect every iteration; pick out lessons other teams could use |
| At project closure | Review the whole project and transfer lessons to the organisation |
| Some months after go-live | Shows whether the benefits arrived and which lessons only became visible in operation |
How to run a lessons learned meeting
- Prepare the evidence: gather the plan and baselines, status reports, the issue log, the RAID log and change log.
- Collect input in advance: send a short survey or shared document so quieter people and those who cannot attend can contribute.
- Invite the right people: the core team, key stakeholders, suppliers where relevant and, ideally, the sponsor. Keep it to a group that can talk openly.
- Choose a facilitator: use someone neutral, not the project manager, if the project was difficult or contentious.
- Set ground rules: focus on processes and decisions, not individuals; assume people did their best with what they knew at the time.
- Walk the timeline: review the main events, decisions and turning points in order.
- Discuss what went well and what to improve, then group similar points into themes.
- Find root causes for the top few themes rather than trying to analyse everything.
- Agree recommendations with an owner and a target date for each one.
- Record and share the results in the register, and send a short summary to attendees and the PMO within a few days.
Sample 90-minute agenda
| Time | Item |
|---|---|
| 0–10 min | Purpose, ground rules and project summary |
| 10–30 min | Timeline review: key events and decisions |
| 30–55 min | What went well and what to improve, grouped into themes |
| 55–75 min | Root causes for the top three to five themes |
| 75–90 min | Recommendations, owners and next steps |
Use our meeting agenda template to send the agenda in advance.
Facilitation formats
- After action review: a short structured debrief that originated in the US Army. Ask what was supposed to happen, what actually happened, why there was a difference, and what to do next time.
- Start, stop, continue: quick to run and good for generating actions.
- Went well / to improve / ideas: a simple three-column board that works in person or online.
- Timeline with highs and lows: the team plots events on a timeline and marks how they felt, which surfaces issues people might not otherwise raise.
- Retrospective games: formats such as the sailboat or 4Ls work for project reviews too; see sprint retrospective games.
Lessons learned questions to ask
Pick the questions that fit your project rather than working through every one.
Planning and scope
- Were the objectives and success criteria clear from the start?
- Were requirements complete and agreed before work began?
- How well did we control scope changes?
Schedule, cost and estimates
- Which estimates were furthest from actuals, and why?
- Where did delays start, and were they visible early in our reports?
- Was contingency the right size and used for the right things?
Risks and issues
- Which issues had we already identified as risks?
- Which problems took us by surprise, and could we have seen them coming?
- Did escalations reach the right people quickly enough?
Team, stakeholders and communication
- Did people have the skills, time and authority they needed?
- Did stakeholders receive the right information at the right time?
- Were decisions made quickly and recorded?
Suppliers, quality and closure
- How well did suppliers perform, and what made the relationship work or not?
- Did quality checks catch defects early enough?
- Was handover to operations smooth, and what would we change?
- If we started this project again tomorrow, what would we do differently?
How to write a good lesson learned
A useful lesson follows a simple pattern: what happened, the impact, the root cause and a specific recommendation with an owner. Avoid vague statements and blame.
| Weak lesson | Strong lesson |
|---|---|
| Communication was poor. | Sales managers did not know the training dates because invitations went only to a general mailing list, so 30% of users missed the first wave. Next time, brief managers directly and add training dates to the communication plan (owner: PM). |
| Testing was late. | System testing started three weeks late because the test environment was not booked until build finished. Book environments during planning and add an environment health check to the schedule (owner: test lead). |
| The supplier was good. | Weekly joint defect reviews with the vendor, using a shared issue log, found most defects before user testing. Repeat this routine on future vendor projects (owner: procurement). |
Lessons learned register template
A register can be a spreadsheet, a list in your project tool or a page in a shared wiki. These columns work for most projects:
| Column | What to record |
|---|---|
| ID | Unique reference, for example LL-001 |
| Date | When the lesson was identified |
| Phase or area | Planning, design, build, testing, handover, or a category such as scope, schedule, cost, quality, risk, people, supplier, communication |
| What happened | A short factual description |
| Went well or needs improvement | Whether this is a practice to repeat or a problem to prevent |
| Impact | Effect on objectives, ideally with numbers |
| Root cause | Why it happened |
| Recommendation | The specific action for this or future projects |
| Owner | Who will make sure the recommendation is applied |
| Action status | Not started, in progress or done |
Our free lessons learned template has these columns ready to use in Google Sheets, Excel or PDF, with dropdowns for impact and status. For deeper analysis of a single problem, use the root cause analysis template.
Lessons learned examples
These entries come from a fictional eight-month CRM implementation and a fictional office move. They show the level of detail to aim for.
| ID | Category | What happened | Impact | Root cause | Recommendation | Owner |
|---|---|---|---|---|---|---|
| LL-01 | Schedule | Data migration took 6 weeks instead of 3 | Go-live delayed by 3 weeks | Legacy data quality not assessed before estimating | Run a data quality audit during planning and include it in the estimate | PMO |
| LL-02 | Communication | Sales managers unaware of training dates | 30% of users missed the first training wave | Messages sent only to a general email list | Brief managers directly and add training to the communication plan | Project manager |
| LL-03 | Supplier | Weekly joint reviews with the vendor caught defects early | Fewer critical defects in user testing | Shared issue log and a fixed agenda | Repeat weekly joint reviews on future vendor projects | Procurement |
| LL-04 | Risk | Key analyst left mid-project | Two-week gap in reporting work | Single point of knowledge with no cover | Flag single points of knowledge in the risk register and assign backups | Resource manager |
| LL-05 | Scope | Furniture requirements changed after the order was placed | £12,000 in restocking fees | Department heads not consulted before sign-off | Get written sign-off on layouts from each department before ordering | Sponsor |
| LL-06 | Planning | Moving over a long weekend avoided disruption to customers | No lost trading days | Early agreement with facilities and IT on a cut-over plan | Use a weekend cut-over plan for future relocations | Facilities lead |
Lessons learned report outline
At the end of a phase or project, summarise the register in a short report for the sponsor and PMO.
| Section | What to include |
|---|---|
| Project summary | Purpose, dates, sponsor, project manager and overall result |
| Performance against objectives | Scope, schedule, cost, quality and benefits compared with plan |
| What went well | The three to five practices most worth repeating |
| What to improve | The three to five most important problems and their root causes |
| Recommendations | Actions for future projects and for the organisation's methods, each with an owner |
| Actions already taken | Changes made during the project in response to lessons |
| Where to find the detail | Link to the full register and supporting documents |
Keep the report short: two or three pages is usually enough. It is often included in the closure report; see our guide to project closure.
Lessons learned vs retrospective vs post-mortem
| Lessons learned review | Sprint retrospective | Post-mortem | |
|---|---|---|---|
| When | End of a phase or project, and throughout | End of every sprint | After a failure or incident, sometimes after a project |
| Scope | A phase or whole project | One sprint | One event or the whole project |
| Main audience | Future projects and the organisation | The same team, next sprint | The team and the organisation |
| Typical output | Register entries and a report | One or two improvement actions | Timeline, root causes and actions |
| Time needed | Often one to two hours or more | Up to three hours for a one-month sprint (Scrum Guide) | Varies with the incident |
They share the same purpose: learning and improvement. A practical approach is to treat retrospectives as the team-level habit and lessons learned as the way to pass the most useful findings to other teams.
How to make lessons learned stick
The most common failure is that lessons are captured and then never used. These habits help close the gap:
- Make reviewing past lessons a step in initiation. Add 'review relevant lessons' to the project charter checklist or the first stage gate.
- Store lessons in one searchable place with consistent categories and tags, owned by a PMO or knowledge lead.
- Turn recurring lessons into standards. If the same lesson appears on three projects, update the template, checklist or estimating guide instead of recording it a fourth time.
- Track recommendations like any other action, with an owner and a due date, and report on how many were applied.
- Share short stories, not long spreadsheets. A five-minute slot in a community of practice meeting reaches more people than a document nobody opens.
- Link lessons to risks. Feed relevant lessons straight into the new project's RAID log.
Common mistakes
- Waiting until the end of the project, when people have forgotten details or moved on.
- Turning the session into a blame exercise, so people stop being open.
- Recording symptoms ('testing was late') instead of root causes.
- Writing vague recommendations with no owner.
- Capturing only problems and ignoring successes worth repeating.
- Storing lessons where nobody looks, such as inside a closed project folder.
- Skipping lessons on cancelled projects, which often have the most to teach.
Start your next review with a ready-made structure: download the free lessons learned template or the sprint retrospective template for Agile teams.
Free templates for this topic
Frequently asked questions
What are lessons learned in project management?
Lessons learned are the documented knowledge gained during a project about what went well, what did not, why, and what should be done differently, so the same project and future ones can improve.
What are some examples of lessons learned?
Examples include running a data quality audit before estimating a migration, briefing managers directly about training dates, repeating weekly joint defect reviews with a supplier, and assigning backups for single points of knowledge.
When should lessons learned be captured?
Throughout the project, at the end of each phase, after significant issues or successes, at closure, and sometimes again a few months after go-live.
What is a lessons learned register?
A project document that records lessons as they are identified, with what happened, impact, root cause, recommendation, owner and status. The term comes from the PMBOK Guide sixth edition.
What is the difference between a lessons learned register and a repository?
The register belongs to one project and is updated while it runs. The repository is the organisation's store of lessons from many projects, which future projects search.
Who is responsible for lessons learned?
The project manager usually leads capture and facilitation, with input from the whole team and stakeholders. A PMO or knowledge lead often owns the repository and checks that recommendations are applied.
Who should attend a lessons learned meeting?
The core team, key stakeholders, suppliers where relevant and ideally the sponsor, with a neutral facilitator if the project was difficult.
What questions should I ask in a lessons learned session?
What was supposed to happen, what actually happened, why there was a difference, what went well, what should be improved, and what we would do differently if we started again.
How do you avoid blame in a lessons learned review?
Set ground rules, focus on processes and decisions rather than people, assume everyone acted on what they knew at the time, and use a neutral facilitator.
Is a retrospective the same as lessons learned?
They share a purpose. A retrospective is a regular, short Agile event for one team; a lessons learned review usually covers a phase or whole project and aims to help other projects too.
What is the PRINCE2 lessons log?
The PRINCE2 record of lessons gathered during a project. In PRINCE2 7 it is one of the records held in the project log, and its contents feed lessons reports at stage ends or project closure.
How do you write a lessons learned report?
Summarise the project and its results, list the most important things that went well and that need improving, give root causes and recommendations with owners, and link to the full register.
Why are lessons learned often ignored?
Because they are captured too late, written too vaguely, stored where nobody looks, or never turned into changes to templates, checklists and methods.
How long should a lessons learned meeting take?
For most projects 60 to 90 minutes is enough if input is collected in advance. Large or troubled projects may need a half-day session or several shorter ones by theme.