# Lessons Learned Register: [Project name]

> Register of what the project learned, positive and negative, captured
> through structured workshops and turned into owned actions that change
> how future work is done. Based on common project management practice.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Capture lessons throughout the project (at least at every stage gate), not only at
  closure when memories have faded and people have moved on.
- Focus on processes and decisions, not individuals. A lesson that blames a person
  will stop people from contributing next time.
- A lesson is only learned when it changes something: every recommendation needs an
  owner and a place where it will be applied.
- Record what went well too; repeating successes is as valuable as avoiding failures.
-->

| Field | Value |
|---|---|
| Document ID | [LL-PROJECT-001] |
| Project | [Project name] |
| Facilitator | [@name] |
| Owner | [@project-manager] |
| Capture points | [End of each stage and project closure] |
| Shared with | [PMO knowledge base, sponsor] |
| Last updated | YYYY-MM-DD |

## 1. Workshop method

<!-- Guidance: Describe how lessons were collected so readers can judge how representative they are. -->

Lessons are gathered in a facilitated workshop of [90] minutes at the end of each stage, with input from a short anonymous survey sent one week before. Participants include the core team, at least one representative of the business users, and key suppliers where relevant.

| Step | Activity | Time |
|---|---|---|
| 1 | Set the ground rules: no blame, focus on systems and decisions | 5 min |
| 2 | Build a timeline of key events and decisions for the period | 15 min |
| 3 | Silent brainstorm: what went well, what did not, what surprised us | 15 min |
| 4 | Group similar items and vote on the most important | 15 min |
| 5 | Root cause analysis of the top items (five whys) | 25 min |
| 6 | Agree recommendations, owners and where each will be applied | 15 min |

## 2. Workshop record

<!-- Guidance: One row per workshop, so the register shows coverage over time. -->

Workshops held:

| Date | Stage covered | Participants | Facilitator | Items raised | Lessons recorded |
|---|---|---|---|---|---|
| YYYY-MM-DD | *Example:* Initiation and design | 11 (team, operations, compliance) | [@name] | 34 | 7 |
| YYYY-MM-DD | *Example:* Build and test | 14 (team, vendor, operations) | [@name] | 41 | 9 |
| YYYY-MM-DD | [Stage] | [n] | [@name] | [n] | [n] |

## 3. Categories

<!-- Guidance: Use stable categories so lessons can be searched across projects. -->

Lessons are classified using these categories: Governance, Scope and requirements, Schedule, Cost, Quality, Resources and team, Communication and stakeholders, Risk, Procurement and suppliers, Technology, Change and adoption.

## 4. Lessons register

<!-- Guidance: Write "what happened" as facts, "root cause" as the underlying reason, and the recommendation as an action someone can take. Type is Positive (repeat) or Negative (avoid). -->

The register records each lesson with its cause and the recommended change.

| ID | Category | Type | What happened | Impact | Root cause | Recommendation | Owner | Applied to | Status |
|---|---|---|---|---|---|---|---|---|---|
| LL-01 | *Example:* Procurement and suppliers | Negative | Vendor started build with 2 of 3 named developers | Front-end build 6 days late | Contract named the team but had no remedy for absence | Include named-team clause with substitution approval and service credits | Head of procurement | Standard IT services contract template | Applied |
| LL-02 | *Example:* Communication and stakeholders | Positive | Branch managers co-designed the process in two workshops | Resistance turned into support; pilot volunteers found quickly | Early involvement gave them ownership | Run co-design workshops with affected managers in the design stage | PMO lead | PMO project lifecycle guide | Applied |
| LL-03 | *Example:* Quality | Negative | Accessibility requirement found late, needing a change request | +18,000 EUR, buffer reduced | No accessibility check in requirements template | Add regulatory and accessibility checklist to requirements template | Head of business analysis | Requirements template v3 | In progress |
| LL-04 | *Example:* Schedule | Positive | Project buffer absorbed two delays without moving go-live | Go-live held | Explicit buffer with consumption tracking | Keep a visible project buffer and report its consumption | PMO lead | Schedule template | Applied |
| [LL-nn] | [Category] | [Positive / Negative] | [Facts] | [Impact] | [Cause] | [Action] | [@owner] | [Process, template or project] | [Open / In progress / Applied / Rejected] |

## 5. Positive lessons to repeat

<!-- Guidance: Summarise the practices that worked, in a form another project can copy. -->

Practices that worked and should be repeated:

- *Example:* Co-design with the people who will run the new process (LL-02).
- *Example:* Visible project buffer, reported as a percentage in every status report (LL-04).
- *Example:* Weekly vendor progress meeting with a shared action log, which cut issue resolution time from 9 to 4 days.
- [Practice and reference]

## 6. Negative lessons to avoid

<!-- Guidance: Summarise the problems and the specific change that prevents them. -->

Problems that should not recur, and the change that prevents them:

- *Example:* Late discovery of regulatory requirements; prevented by a regulatory checklist in requirements elicitation (LL-03).
- *Example:* Supplier staffing gaps; prevented by enforceable named-team clauses (LL-01).
- *Example:* Test environment outages blocking testing; prevented by an environment service level agreed before the test stage.
- [Problem and preventive change]

## 7. Root cause summary

<!-- Guidance: Look across lessons for repeating causes. Repeated causes point to organisational fixes rather than project fixes. -->

Causes that appear in more than one lesson:

| Root cause theme | Lessons | Suggested organisational fix | Raised with |
|---|---|---|---|
| *Example:* Templates do not prompt for regulatory needs | LL-03, LL-07 | Update requirements and charter templates | PMO, business analysis practice |
| *Example:* Supplier contracts lack delivery remedies | LL-01, LL-09 | Revise IT services contract template | Procurement, legal |
| [Theme] | [IDs] | [Fix] | [Forum] |

## 8. Actions

<!-- Guidance: Track the actions that apply the lessons. Close them only when the change is in place. -->

Actions arising from the lessons:

| Action ID | Lesson | Action | Owner | Due | Status | Evidence of completion |
|---|---|---|---|---|---|---|
| ACT-01 | LL-01 | *Example:* Add named-team clause to contract template | Head of procurement | YYYY-MM-DD | Done | Template v4.2 published |
| ACT-02 | LL-03 | *Example:* Add accessibility and regulatory checklist to requirements template | Head of business analysis | YYYY-MM-DD | In progress | |
| [ACT-nn] | [LL-nn] | [Action] | [@owner] | YYYY-MM-DD | [Status] | [Evidence] |

## 9. Sharing and follow-up

<!-- Guidance: Say where the lessons go and when someone checks they were applied. -->

The register is published to [PMO knowledge base] after each workshop. The PMO reviews open actions quarterly and reports in the portfolio review. New projects of a similar type are asked to read this register during initiation and to confirm which lessons they apply.

## Standard and licence note

Based on common project management practice for lessons learned capture,
retrospective workshops and knowledge transfer. This template is original
text written for this collection. Template licence: MIT.