Free Template · Excel · Updated March 2026
Free Lessons Learned Register Template
Excel Download
Most teams repeat the same mistakes on the next project. They write lessons down, but nobody can find them or act on them later. This template fixes that. For each lesson you record what happened, why it happened, the impact and, most important, what the next team should do differently. It follows the same structure I teach in my PMP training.
35 pre-numbered rows
LL-001 through LL-035. Unique IDs let you reference specific lessons in other project documents and the closure report without repeating the full text.
Category and impact drop-downs
8 lesson categories and Positive / Negative / Neutral impact, validated for filtering and trend analysis across projects in a shared PMO repository.
Root cause and recommendation
Dedicated columns for root cause and actionable recommendation. These two fields are what turn observations into organisational knowledge that future teams can actually use.
Lessons Learned Register
Free Excel template, instant download
Format
Excel (.xlsx)
Rows
35 pre-numbered entries
Columns
9 fields per lesson
Drop-downs
Category and Impact validated
Compatible
Excel, Google Sheets, LibreOffice
Price
Free, no signup needed
No email required. Instant Excel download.
Quick answer
A lessons learned register records what happened on a project, why it happened and what future teams should do differently. This free Excel template uses 9 columns with category and impact drop-downs, so lessons are structured, searchable and easy for the next project team to act on.
This page is for recording lessons during your project, so the next team does not repeat your mistakes. If you want to check, after go-live, whether the project delivered its benefits, use my post-implementation review template instead.
01: What's Included
What's in the lessons learned template?
The register is a single Excel sheet with a project details row and 35 numbered lesson rows. Two columns, Category and Impact, use drop-downs. This keeps every entry consistent, so you can filter lessons across many projects later.
| Column | Field | Notes |
|---|---|---|
| ID | Lesson Number | Pre-filled LL-001 to LL-035. The ID lets you reference specific lessons in the closure report, PIR or future project plans without repeating the full text. |
| Date | Date Captured | When the lesson was captured, not when it occurred. Lessons captured close to the event are more accurate than those recorded retrospectively at project closure. |
| Phase | Project Phase | Initiation, Planning, Execution, Monitoring, Closure. Grouping by phase helps future PMs identify where similar projects typically struggle. |
| Category | Drop-down | Planning / Execution / Monitoring / Risk / Communication / Technical / Procurement / Other. Validated drop-down that enables cross-project filtering by lesson type. |
| Lesson Description | What happened | A specific, factual description of the situation. Not "communication was poor" but "the integration team was not included in the scope review meeting in Week 3, resulting in a missed dependency that was discovered in testing." |
| Impact | Drop-down | Positive / Negative / Neutral. Positive lessons are as important as negative ones. What went well should be repeated, not just assumed. Validated drop-down. |
| Root Cause | Why it happened | The underlying reason, not the symptom. Asking "why" once is rarely enough. Use the 5 Whys to get past surface explanations. The root cause is what the recommendation must address. |
| Recommendation | What to do differently | A specific, actionable instruction for future project teams. Not "improve communication" but "include the integration lead in all scope review meetings from Week 1." Must be actionable by someone who was not on this project. |
| Owner | Name | Who captured this lesson and can be consulted for more context. Also the person responsible for ensuring the recommendation is communicated to the PMO or next project team. |
The Recommendation column is what makes this register useful. Without it, you have a complaint log. It says what went wrong but not what to do. Test every entry like this: could a project manager who was not on your project read it and know exactly what to do next time? If not, rewrite it until they can.
02: Writing Good Lessons
What does a good lesson entry look like?
A good entry depends on two things: a specific description and a recommendation someone can act on. Compare these two entries for the same event:
✗ Low-Value Entry
Description
"Stakeholder communication could have been better throughout the project."
Root Cause
"Poor communication planning."
Recommendation
"Communicate more with stakeholders on future projects."
Vague at every level. A future PM learns nothing actionable from this. It could apply to almost any project failure ever recorded.
High-Value Entry
Description
"Three senior stakeholders in the Finance directorate were not included in the status report distribution list until Week 8. When they joined a steering committee, they had no context for the project's current position and challenged several decisions that had already been made."
Root Cause
"The stakeholder register was created in Week 1 but not reviewed after the project was re-scoped in Week 4. New stakeholders added to scope were not added to the comms plan."
Recommendation
"Review and update the stakeholder register and communications plan at every change request approval and at each phase gate, not only at project start."
Positive lessons are just as important. A lessons learned register that only contains negative lessons is half a register. Capture what worked unusually well: a vendor who exceeded expectations, a risk management approach that prevented a significant issue, a team working practice that should be adopted as a standard. Future project teams need to know what to replicate, not just what to avoid.
How to fill it in: a worked example
Here are three filled rows so you can see the level of detail I expect. This is an example only, based on a typical mid-rise building project in the UAE. Copy the style, not the content.
| ID / Phase / Impact | What happened and why | Recommendation for the next team |
|---|---|---|
| LL-001 / Execution / Negative | Facade glazing arrived late because shop drawings were approved by the consultant much later than planned. Root cause: shop drawing submission and consultant review time were not in the baseline schedule. | Add submission, consultant review and resubmission for every long-lead item as separate activities in the baseline. Review them in the weekly progress meeting. |
| LL-002 / Execution / Negative | The first authority drainage inspection failed because test records were missing. Root cause: no internal check before booking the inspection. | Two days before every authority inspection, walk the area with the MEP subcontractor using the authority's own checklist. Book only when every item is ready. |
| LL-003 / Planning / Positive | No productivity was lost in summer because concrete pours were planned for early morning around the midday work break. Why it worked: the break was built into the plan from day one. | Plan heavy summer work in the early hours in the baseline schedule, not as a fix after the first hot week. |
Mistakes I see when people fill in this register
- Writing every lesson at closure from memory. By then the details are gone and the lessons are vague.
- Blaming a person or company ("the subcontractor was slow") instead of finding the cause in your own process.
- Recommendations that start with "improve" or "consider". If nobody can act on it tomorrow, rewrite it.
- Only recording what went wrong. The things that worked are the easiest to lose.
- Never opening the register again. Read the lessons from similar projects before you finish your next plan.
03: When to Capture
When should you capture lessons learned?
From my experience: on my construction projects in the UAE, the best lessons came from short reviews held right after something happened: a failed authority inspection, a late drawing approval, a snag list that grew too long at handover. When we waited until the end, half the team had moved to other sites and we were guessing. So capture lessons while the event is fresh, not only at closure.
After Every Risk Event
When a risk materialises
Capture why the risk was not prevented, what the mitigation did or did not do, and how the response could be improved. The context is immediate and specific.
After Each Phase Gate
At every phase transition
A 30-minute lessons review at the end of each phase captures fresh observations before the team moves on. Three questions: what went well, what was difficult, what would you change?
After Change Requests
When a CR reveals a gap
Every change request is a symptom of something: a planning assumption that was wrong, a requirement that was misunderstood, a risk that materialised. Capture the lesson at the time.
After Unexpected Success
When something works better than planned
When a task completes early, a vendor overdelivers or a new process saves significant time, capture why immediately. Positive lessons are the most often forgotten.
Project Closure Session
The formal lessons review
A dedicated session to review, consolidate and prioritise the lessons captured throughout the project. This is the last chance to add any that were missed, and to vote on which recommendations are most important for the PMO.
Post-Implementation Review
3 to 6 months after go-live
Additional lessons may emerge once the solution is in operation. The PIR often surfaces lessons about requirements quality, training effectiveness and benefits assumptions that were not visible at closure.
04: Making Lessons Count
How to Make Lessons Learned Actually Useful
Many lessons learned registers are filled in once and never opened again. A lesson stored in a folder nobody can find is not a lesson. To make the register useful, you need to do a few things after you fill it in.
1
Submit to a central, searchable repository
At project closure, submit the completed register to a central PMO repository, SharePoint library or Confluence space. Tag each lesson with project type, sector and category so they are discoverable by keyword search. A lessons register that lives only in the project archive is inaccessible to future teams.
2
Include a lessons review in every project planning phase
Build a mandatory step into the project planning process. Before finalising the project management plan, the PM reviews lessons from similar past projects in the repository. This is where the investment in capturing lessons pays off, and it takes 30 to 60 minutes, not days.
3
Synthesise patterns into organisational standards
The most valuable use of lessons learned is synthesis. When five projects all record the same lesson about integration testing being under-resourced, a PMO can turn that pattern into a standard: a minimum resourcing guide for integration testing on any future project. Individual lessons are valuable. Synthesised patterns become standards.
4
Name the recommendations as standards, not suggestions
The language in the Recommendation column matters. "Consider including the integration lead in scope reviews" is a suggestion that can be ignored. "Include the integration lead in all scope review meetings from Week 1. This is now mandatory for integration projects" is a standard. PMOs that treat their best lessons as mandatory standards see faster improvement than those that treat them as optional advice.
PMP exam note: The lessons learned register comes from PMBOK 6, and that content is still useful for learning. For the exam, remember two things: you collect lessons throughout the project, not only at the end, and at closure they go into the organisational process assets (OPAs) so future projects can use them. In PRINCE2, the Lessons Report is produced during Closing a Project. Try our 200 PMP practice questions for scenario questions on lessons learned and OPAs.
05: FAQ
Lessons Learned: 4 Common Questions
A lessons learned register records what went well and what did not on a project, so future teams can learn from it. Each entry has a description, phase, root cause, impact and a clear recommendation. You update it throughout the project and hand it to the organisation's process assets at closure. In PRINCE2, the equivalent is the Lessons Report, produced in Closing a Project.
Capture lessons all through the project, not just at the end. Good moments are right after a risk happens, at the end of each phase, when a change request shows a planning gap, or when something works better than expected. Hold a closure session too, but use it to tidy up lessons you already have. Lessons written from memory at the end are usually vague.
A good lesson learned has four components. First, a specific description of what happened, not "communication was poor" but a factual account of the specific event. Second, the root cause: why it happened, discovered through root cause analysis. Third, the impact: what effect it had on the project. Fourth, a specific, actionable recommendation. "Do this differently next time" with enough detail that a PM who was not on the project can act on it. Lessons that describe the problem without a concrete recommendation have little value for future teams.
A lesson only has value if the next team can find it. Put the register in a shared, searchable PMO folder at closure. Tag each lesson by project type and category. Make "review past lessons" a step in planning every new project. And ask someone in the PMO to spot repeated lessons and turn them into standards. A register nobody reads is just paperwork.
Explore More Free PM Resources
Keep learning
- Free KPI Tracker Template: Excel Download
- Free Budget Variance Report Template: Excel Download
- Free Project Closure Report Template: Word Download
- Free Post-Implementation Review Template: Word Download
- Free Project Handover Document Template: Word Download
- Free Project Sign-Off Form Template: Word Download