What is a lessons learned log?

A running record of what happened on a project, why it happened, and the recommended change. Each entry has a category, an impact, a root cause, a recommendation, an owner and a status.

When should lessons learned be captured?

Continuously, within about a week of the event, and reviewed at each stage gate or sprint boundary. Capturing only at closure means writing from memory, which loses the detail that makes a lesson reusable.

How do you run a lessons learned session?

Set a blame-free frame, give everyone five silent minutes to write entries, group and vote on the top three to five, ask why until you reach a process or information cause, then assign an owner and status to each recommendation.

What is the difference between lessons learned and a retrospective?

A retrospective is a short, recurring team session focused on the next iteration. A lessons learned log is the durable record that spans the whole project and feeds the organisation's templates and standards. Run both: retrospectives feed the log.

Who owns the lessons learned log?

The project manager maintains it, but each recommendation needs its own owner — often the sponsor, a functional lead or a PMO role — because most changes sit outside the project manager's authority.

PMI standard template · Word & PDF · Toolkit only

Lessons Learned Template (PMI Standard Word & PDF)

7 min read · Reviewed August 2026 by Dan Sunil Kumar

A lessons learned log records what happened on a project, why it happened and what should change as a result. Each entry pairs an observation with a root cause, a recommendation and a named owner.

The reason most logs fail is timing. They get written in the last week of the project, from memory, by one person, and then filed where nobody reads them. This template is built to be opened during delivery and reviewed at every stage gate, so entries keep the detail that makes them reusable.

PMI standard alignment

Standard followed: PMBOK Guide 7th ed. / PMI Organizational Project Management Maturity Model
Performance domain: Measurement & Delivery
Process group: Closing
Knowledge area: Integration Management

The Word & PDF files for this template are part of the paid PM Delivery Toolkit — there is no free download. The full walkthrough, worked example and section guidance below stay open to read.

Get the lessons learned log in the toolkit

When to use it

You are starting a project and want a log open from day one rather than at closure.
You run sprint retrospectives and need somewhere durable for the themes that outlive one sprint.
A stage gate or phase end is approaching and the sponsor expects evidence of improvement.
A project has gone badly and you need a factual, blame-free record of the causes.

Every section, and what good looks like

Section 1
Header block
Project name, project manager, sponsor, date the log was opened and the date it was last reviewed.
The last-reviewed date is recent — a stale date is the clearest signal the log is not being used.
Section 2
Date and phase
When the event happened and which stage or sprint it occurred in.
Recorded within a week of the event, while the specifics are still known.
Section 3
Category
A short tag: estimation, stakeholders, quality, vendor, scope, tooling, people.
A small fixed list, so you can spot the theme that keeps repeating across projects.
Section 4
What happened
A factual description of the event, without interpretation or blame.
Written so someone outside the project understands it in one read, with no names attached to failures.
Section 5
Impact
The measured consequence — days lost, cost, defects, reputation, morale.
Quantified wherever possible; that number is what earns the recommendation attention.
Section 6
Root cause
Why it happened, traced to a process, information gap or unclear decision right.
The cause is something you can change. If the answer is a person's name, keep asking why.
Section 7
Recommendation
The specific change to make next time — a checklist item, a template change, a gate criterion.
Concrete enough to be actioned by someone who was not on this project.
Section 8
Owner and status
Who is taking the recommendation forward and whether it is proposed, adopted or rejected.
Every kept lesson has an owner. A lesson with no owner is a complaint, not a lesson.

A filled-in example

A realistic lessons learned log from a delivery close-out, so you can see how an observation becomes a reusable recommendation.

Worked lessons learned log example
Date / phase	12 Mar / Planning
Category	Estimation
What happened	Integration effort was estimated from a single vendor call.
Impact	Three-week slip and roughly £18k of rework.
Root cause	No reference-class data used for a first-time integration.
Recommendation	Require two independent estimates for any first-time integration.
Owner	Project manager
Status	Adopted — added to the planning checklist

Mistakes that turn a lessons learned log into a filing exercise

Waiting until closure, when the team has moved on and the detail is gone.
Recording observations with no root cause, so nothing can actually be changed.
Naming individuals instead of causes, which stops people contributing honestly.
Listing forty items and analysing none — pick the three to five that matter.
No owner or status, so adopted recommendations quietly never happen.
Filing the log in a folder nobody opens instead of feeding it into templates, checklists and the next project's risk register.

Paid toolkit

26 more artifacts, ready to fill in

The PM Delivery Toolkit packages the RAID log, status pack, estimation and earned value workbooks, capacity planner, agile sprint tools and 150 PMP-style questions — Word, Excel and print-ready PDF.

Status pack and steering deck with RAG logic built in
Estimation and EVM workbook: CPI, SPI and EAC calculated
Capacity planner with an over-allocation heatmap
Agile set: sprint planning, user stories, retros, backlog, WSJF

What’s inside all 26 artifacts

One payment · lifetime updates · 14-day refund. Files unlock on your download page as soon as payment clears.

Questions people ask

What is a lessons learned log?: A running record of what happened on a project, why it happened, and the recommended change. Each entry has a category, an impact, a root cause, a recommendation, an owner and a status.
When should lessons learned be captured?: Continuously, within about a week of the event, and reviewed at each stage gate or sprint boundary. Capturing only at closure means writing from memory, which loses the detail that makes a lesson reusable.
How do you run a lessons learned session?: Set a blame-free frame, give everyone five silent minutes to write entries, group and vote on the top three to five, ask why until you reach a process or information cause, then assign an owner and status to each recommendation.
What is the difference between lessons learned and a retrospective?: A retrospective is a short, recurring team session focused on the next iteration. A lessons learned log is the durable record that spans the whole project and feeds the organisation's templates and standards. Run both: retrospectives feed the log.
Who owns the lessons learned log?: The project manager maintains it, but each recommendation needs its own owner — often the sponsor, a functional lead or a PMO role — because most changes sit outside the project manager's authority.

Other PMI-standard templates

Every one has the same walkthrough, worked example and PMI mapping, and every file ships inside the PM Delivery Toolkit.

Keep going on the site

The hubs and tools that pair with this lessons learned log.

Free tips

Get five PM habits that quietly save projects

Baselines, critical path discipline, RAID logs that people read, range estimating and status packs sponsors act on — sent straight to your inbox, free.

One email, no spam, unsubscribe any time.

Lessons Learned Template (PMI Standard Word & PDF)

When to use it

Every section, and what good looks like

Header block

Date and phase

Category

What happened

Impact

Root cause

Recommendation

Owner and status