Skip to content

Lessons Learned Register

At a glance

  • Purpose: Capture what the project learned while the people who learned it are still available — and turn each lesson into a change that outlives the project.
  • Use it when: Continuously at checkpoints, not only at closure. A register written entirely at the end records only what people can still remember.
  • Owner: The project manager; each lesson has a named owner for the change it produces.
  • Related: Module 12 · Lab 25

How to use this template

  1. Write the lesson as situation → what we learned → what changes. Without the third part, the entry is an observation, not a lesson.
  2. Capture the context that made it true. Lessons applied outside their context are how teams copy practices that do not fit — a lesson from a two-person project may not transfer to a twenty-person one.
  3. Distinguish project-specific lessons from organisational ones, and route the second to whoever owns the process. Lessons that never leave the project file change nothing.
  4. Include what went well, with the reason. Otherwise the register becomes a list of complaints and the practices worth keeping are lost when the team disperses.
  5. Assign a verification date for each change. A lesson with no check is a wish, and this is the failure mode that gives lessons-learned a bad reputation.

Field descriptions

Column What goes in it Watch out for
ID Stable reference (LL-004) Lessons in meeting notes only
Phase When it arose: initiation, planning, delivery, closure Everything dated at closure
Situation What happened, factually Blame attributed to individuals
Lesson The generalisable insight Restating the situation
Evidence The measurement or artefact supporting it Anecdote presented as a pattern
Scope Project-specific or organisational Organisational lessons left unowned
Change The concrete change to practice "Be more careful"
Owner Who will make the change Owner who has no authority to change it
Verification How, and by when, you will know it worked No check
Status Open / in progress / embedded / not adopted Nothing ever marked embedded or not adopted

Blank template

# Lessons Learned Register — [Project name]

| | |
| --- | --- |
| **Compiled by** | [Who] |
| **Reviewed at** | [Checkpoints: dates] |
| **Last updated** | [YYYY-MM-DD] |

| ID | Phase | Situation | Lesson | Evidence | Scope | Change to practice | Owner | Verification | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| LL-001 | [Phase] | [What happened] | [Insight] | [Measure or artefact] | [Project / Organisation] | [Concrete change] | [Who] | [How and when it will be checked] | Open |

## What worked and why

| ID | What worked | Why it worked | Worth repeating when |
| --- | --- | --- | --- |

## Not adopted

| ID | Lesson | Why not adopted | Decided by | Revisit if |
| --- | --- | --- | --- | --- |

## Handover to the organisation

| ID | Change | Routed to | Date | Confirmed received |
| --- | --- | --- | --- | --- |

Worked example

From Lab 25, on the analytics dashboard — invented for teaching. Four entries at a mid-project checkpoint:

ID Situation Lesson Evidence Scope Change Status
LL-001 The baseline was front-loaded, so schedule performance looked healthy in week 6 and poor by week 14 A baseline whose early work is over-weighted hides slippage until the last third; track a plain milestone-day count alongside any ratio Both readings compared over the same period Project Add a milestone slip row to the dashboard and report it beside schedule performance Embedded
LL-002 Realistic record volumes arrived only in week 12, so a performance defect was found late Test data realism is a schedule dependency, not an environment detail The list-screen timeout appeared only at 1,200 records Organisation Add "realistic data available" as a definition-of-ready criterion on data-heavy items In progress
LL-003 Two developers edited the same integration module and a fix was overwritten Concurrent editing needs explicit ownership, not good intentions Merge conflict that dropped a verified fix Project Name a single owner per module in the resource plan Embedded
LL-004 Daily stand-ups ran 30 minutes for a six-person team The stand-up was absorbing problem-solving that belonged in a smaller follow-up Observed durations over three weeks Project Stand-up capped at 15 minutes; detailed discussion deferred to a daily block Embedded

Two of these are worth reading closely. LL-001 is a measurement lesson, and the change it produced is a second measure rather than an abandonment of the first — the correct response to a misleading indicator is usually a cross-check, not removal. LL-004 is a lesson about a well-known practice being misapplied: the team did not conclude that stand-ups are useless, but that the meeting had taken on work that needs a different setting. Drawing that distinction is exactly what distinguishes a lesson from a complaint.

Common mistakes

  • Written only at closure. Memory is unreliable and people have left, so the register records the last few weeks of the project.
  • Observations with no change attached. "Communication was poor" is not a lesson until it names an action someone owns.
  • Blame framed as a lesson. "The developer should have tested more" teaches nothing and ensures the next register will be sanitised.
  • Ignoring context. Copying a practice from a project with different constraints, because the lesson was recorded without its conditions.
  • Organisational lessons left unowned. If the change is to a process, someone outside the project must receive it — otherwise the lesson cannot be applied.
  • Successes omitted. Without them, the team dismantles practices that were working.
  • No verification. An unverified lesson is indistinguishable from an unadopted one, and that is why organisations conclude lessons-learned does not work.