Guides › Guide

Lessons learned template

Most lessons learned documents are written once, filed carefully and never opened again. Here is a template built so that something actually changes on the next project.

Why most lessons never get learned

A lesson counts as learned when someone does something differently. A paragraph that says communication could have been better changes nothing, because nobody owns it and nobody can tell if it worked.

So the template below asks for evidence, a cause and an owned action for every lesson. If it cannot answer those, it is a moan, not a lesson.

The template: columns to copy

Use a simple table with one row per lesson. Keep the wording factual and blameless.

• Reference number and project phase (initiation, planning, delivery, closure).
• Category: scope, schedule, cost, people, suppliers, governance, technology or communication.
• What happened, in one or two factual sentences.
• Impact: days lost, cost added or benefit affected, if you know it.
• Root cause: the reason behind the reason, not the symptom.
• Recommendation, action owner and the team or process it applies to.

Running the session

Hold it while memories are fresh, ideally within a few weeks of go-live, and invite the people who did the work as well as the sponsor. Ask someone outside the delivery team to facilitate if you can, since the project manager is rarely neutral about their own project.

Run it as three questions, each with ten minutes of silent writing before any discussion, so the loudest voice does not set the agenda.

• What went well and should be repeated?
• What did not go well, and what was the root cause?
• What would we do differently, and who will make that happen?
• Ask why five times on the biggest two or three problems.
• Agree a rule up front: we discuss processes and decisions, not people.

Turning lessons into change

Sort the output into lessons you can act on and lessons that are merely interesting. Actionable ones need an owner and a date, and they go somewhere people will see them again, such as the PMO playbook, a project start checklist or the risk register template for the next project.

• Add recurring problems to the standard risk list for new projects.
• Update templates and checklists the same week, not eventually.
• Send the top five lessons to the PMO and to the next project manager by name.
• Review the log at the start of every new project kickoff.

Capture lessons as you go

The best lessons logs start in week one. A line added each time something goes wrong is worth more than a heroic memory exercise at the end. In Senshin you can keep this alongside the RAID log, so closed issues and decisions are already waiting when the review comes round.

Where this lives in Senshin

Frequently asked questions

More guides

Last updated: 2026-10-22