PWPM Wiki
✅ Quality & Continuous Improvement

Lessons Learned

Lessons learned is the practice of capturing what went well and what went badly on a project — and, crucially, feeding those insights back so the next project does not repeat the same mistakes.

Lessons learned is the knowledge gained from a project — both successes to repeat and problems to avoid — captured deliberately so it can improve future work. It is gathered throughout the project and consolidated at closure, covering what happened, why, and what should be done differently. The value is realised only when lessons are stored where others can find them and actually applied — otherwise organisations relearn the same painful lessons on every project. It sits at the heart of organisational project knowledge and continuous improvement.

Lessons Learned at a glance

Category
Quality & Continuous Improvement
Type
Concept
Appears in
1 section
Related
Benchmarking, Quality Improvement, Operational Excellence

Why it matters

Every project is a source of hard-won knowledge; without a lessons-learned practice, that knowledge walks out of the door when the team disbands. Capturing and reusing it makes each project a little smarter than the last — estimates get more realistic, known risks get planned for, successful approaches get repeated. It is one of the cheapest, highest-leverage practices available, yet the most commonly skipped under end-of-project pressure.

When to use it

Capture lessons continuously — noting them when they happen, not just at the end when memory has faded — and formally review them at phase boundaries and project closure. Apply them at the start of new projects (during planning and risk identification) by consulting the lessons repository. On Agile teams, retrospectives are a continuous lessons-learned mechanism.

How to use it

  1. Capture lessons throughout the project as they occur, not only at the end.
  2. At closure (and phase gates), hold a review with the team and key stakeholders.
  3. For each lesson, record what happened, the impact, the root cause, and the recommended action.
  4. Store lessons in a shared, searchable repository so future projects can find them.
  5. Close the loop: consult the repository when planning new projects and act on relevant lessons.

Example

At the close of an app launch, the team records that the third-party payment integration took three times its estimate because of undocumented API limits. The lesson — "add a spike to validate third-party APIs before estimating integration work" — is stored in the PMO repository. The next project’s planning includes exactly that spike, and its estimate holds.

Template

A lessons-learned template captures, per lesson: category, what happened, impact, root cause, recommendation and owner; feed it into a lessons register.

Browse templates →

Tools

ConfluenceSharePointNotionExcelPMO knowledge base

FAQs

When should lessons learned be captured?
Continuously, throughout the project, and formally consolidated at phase boundaries and closure. Waiting until the very end loses detail and honesty as memories fade and the team scatters.
Why do lessons learned so often fail to add value?
Because they are captured but never reused. Lessons only help if they are stored somewhere findable and actively consulted when planning future projects — closing that loop is the hard part.
How is a retrospective different from lessons learned?
A retrospective is an Agile team’s regular, short reflection at the end of each iteration; lessons learned is the broader (often end-of-project) practice. Retrospectives are effectively continuous lessons learned.

Alternatives

  • Agile retrospective — frequent, iteration-level continuous improvement
  • Post-implementation review — a formal post-delivery evaluation
  • After-action review — a structured military-origin debrief format