Lessons learned template

What a lessons learned log is for

A lessons learned log records what a project would do again and what it would change, written for the next person who runs something similar. Most logs fail in the same way: they get written in the last week, filed in a closure folder, and never read. The template is built against that. Every lesson to do differently ends in a recommendation someone can act on and an owner who carries it into the next plan.

How to write a lesson

Compare two versions of the same lesson from the made-up example above:

• Vague: “Communication could have been better.”
• Useful: “Task status lived in three spreadsheets, so the weekly report took about half a day to put together. Two steering meetings saw numbers that were a week old. Next time: one task list, one owner per task, a fixed day for updates.”

The second one has a fact you could check, a cost (half a day a week, stale numbers at two decisions), and a change the next project can put in its plan on day one. If a lesson has no date, number or name of a document in it, it's usually an opinion. Ask “what exactly happened?” until it has one.

What goes in each column

• Type: went well (repeat it) or do differently. Keep both. The things that worked are the ones most likely to be dropped on the next project, because nobody wrote them down.
• Category: planning, schedule, cost, scope, quality, stakeholders, communication, team, supplier, technical or other. Three or more lessons to change in one category is where the next plan needs the most attention.
• What happened: the facts, with a date, a number or a document. Not who was at fault.
• Effect on the project: days, money, quality or people. “Go-live moved from Sep 8 to Sep 29” is enough.
• Recommendation: one thing the next project should do or keep doing, in a sentence that could go straight into a plan or a checklist.
• Action owner, due date and status: who makes sure the recommendation lands (in a template, a checklist, a contract clause) and by when. “No action” is fine for lessons that only need to be read.

Example: a lessons learned summary for the closure report

This is the example from the builder above, as plain text. The project, numbers and names are made up.

Lessons learned: Warehouse scanner rollout
Review held Nov 10, 2026
7 lessons: 3 went well, 4 to do differently. 5 actions open, 1 overdue

Do differently next time:
L1. [Schedule] The Wi-Fi survey was booked after the scanners arrived, and it found dead zones in aisles 14 to 22.
    Effect: Go-live moved from Sep 8 to Sep 29; two shifts stayed on paper pick lists for three weeks. Next time: Survey the site before ordering hardware and put the survey on the critical path. Action: Priya Shah, due Dec 1.
L3. [Supplier] The scanner vendor's lead time went from 4 weeks to 9 after the purchase order, and the project only heard in week 5.
    Effect: The pilot started 5 weeks late. Next time: Put a committed ship date in the purchase order and ask the vendor for order status every week until delivery. Action: Dana Fox, due Nov 6 (overdue).
L5. [Cost] The extra access points the survey called for weren't in the budget.
    Effect: $11,400 over the $86,000 budget, approved as a change request in week 9. Next time: Hold a contingency line for infrastructure the site survey finds. Action: Dana Fox, due Dec 15.
L6. [Communication] Task status lived in three spreadsheets, so the weekly report took about half a day to put together.
    Effect: Two steering meetings saw numbers that were a week old. Next time: Keep one task list with one owner per task and a fixed day for updates. Action: Priya Shah, due Nov 24.

What went well (repeat it):
L2. [Planning] The rollout went one zone at a time, starting with the cold store.
    Effect: Label and login problems found in zone 1 were fixed before zones 2 and 3; no shift missed its pick target after week one. Keep doing: Phase physical rollouts by zone and leave a week between zones. Action: Luis Romero, due Nov 3 (done).
L4. [Team] Floor supervisors tested the pick screens two weeks before training.
    Effect: They caught 6 confusing labels, and training took 45 minutes a shift instead of the planned 2 hours. Keep doing: Add a supervisor test week to the rollout plan template. Action: Luis Romero, due Nov 20.
L7. [Stakeholders] The site manager signed off each phase in a 15-minute walk-through instead of by email.
    Effect: No phase waited more than a day for approval. Keep doing: Use walk-through sign-offs on physical rollouts.

Open actions:
- L3, Dana Fox by Nov 6 (overdue): Put a committed ship date in the purchase order and ask the vendor for order status every week until delivery.
- L4, Luis Romero by Nov 20: Add a supervisor test week to the rollout plan template.
- L6, Priya Shah by Nov 24: Keep one task list with one owner per task and a fixed day for updates.
- L1, Priya Shah by Dec 1: Survey the site before ordering hardware and put the survey on the critical path.
- L5, Dana Fox by Dec 15: Hold a contingency line for infrastructure the site survey finds.

Read it the way the next project manager would. The site survey and the access point budget are the same root cause (the survey came too late), so on the next rollout that is one change to the plan, not two. The supplier action is past its due date, which is the one to chase this week.

Running the review meeting

• Hold it within two weeks of handover. After that, people have moved on and the details are gone.
• Bring the numbers. Planned and actual finish dates, budget and actual cost, and the change log. They turn “it felt late” into “these three tasks slipped 18 days between them”.
• Collect lessons before the meeting. Ask each person for two that went well and two to do differently, each with a date or a number. The meeting is then for grouping and agreeing recommendations, not for remembering.
• Talk about the work, not the people. “The vendor's lead time changed and the project heard in week 5” leads to a fix. “Procurement dropped the ball” leads to a defensive hour.
• Finish with owners. Every lesson to do differently leaves the room with a name and a date, or a decision that it needs no action.

The Excel and Word templates include a page of review questions in this order: before the meeting, goals and scope, schedule and cost, people and suppliers, close.

Making lessons get used

• Read the last log at kickoff. The best moment for a lesson is the first planning session of the next similar project, not the closure meeting of this one.
• Turn recommendations into artifacts. A lesson that becomes a line in the plan template, a question on the kickoff checklist or a clause in the purchase order keeps working without anyone remembering it.
• Feed the risk register. Most lessons to do differently are risks for the next project. The supplier lead time above belongs in the next risk register on day one, with a trigger date.
• Keep one log across projects. The CSV has a Project column, so logs can be pasted into one sheet and filtered by category.

Lessons learned, retrospective or RAID log?

• Lessons learned: a look back at a whole project or phase, written for people who weren't there.
• Retrospective: a short, regular meeting where the same team adjusts how it works for the next iteration.
• RAID log: the live list of risks, assumptions, issues and dependencies while the project runs. Closed issues in the RAID log are a good source of lessons, because each one already has a date and an effect.

The Excel and Word versions

• Excel template (.xlsx, 11 KB): a Summary sheet with live counts (went well, do differently, open, overdue and unowned actions) and a table by category. The Lessons sheet has 60 numbered rows with drop-down lists for type, category and action status; an open action due before the review date on the Summary turns red. A third sheet has the review questions. Opens in Excel or Google Sheets.
• Word template (.docx, 38 KB): project details with baseline and actual, a table for lessons to do differently and one for what went well, and the review questions on landscape pages, for teams that file the closure report as a document. Opens in Word or Google Docs.

Both are blank apart from gray example rows.

Questions

Have the dates when you need them

The strongest lessons come with numbers: what was planned, what happened, and when the team knew. PingCadence keeps that record as the project runs. It emails each task owner a short check-in on the cadence you set, from your own Outlook or Gmail after you approve the batch, and logs “on track” or a new date against your baseline, so the slip history is there at closure. The project status report template is the free version of the weekly half. See how it works.