Home · Templates · Lessons log
Lessons learned log template
A free, editable Excel log for capturing what worked and what didn't — while people still remember. Structured recommendation-first, because a lesson nobody can act on is not a lesson, it is a feeling.
Lessons log template — Excel (.xlsx)
Went well / went badly / near miss categories, recommendation-first structure, worked example and a how-to sheet. No email wall.
The most-written, least-read document in project management
Almost every project produces a lessons learned log. Almost no project reads one.
It is worth being honest about why, because the usual explanation — people are lazy, organisations don't care about learning — is wrong, and it leads to useless remedies like "we must have a stronger lessons culture". The real reasons are structural, and they are fixable:
- They are written at the end, when the detail has evaporated and everyone has moved on.
- They are written to be filed, as a closure deliverable, rather than to be used.
- They contain observations, not recommendations. "Communication could have been better" is true of literally every project ever run, and tells the next team nothing at all.
Fix those three and the log starts earning its place. Nothing else is required.
Capture continuously, not at the end
The single highest-leverage change: write the lesson within days of the thing happening, and review the log at every stage boundary rather than saving it all for a post-mortem workshop.
Why the end is too late. By closure, the specifics have gone, the people who felt the pain have rolled off, and what survives is a diplomatic account in which nothing was anybody's fault. Lessons captured in the moment are specific and slightly uncomfortable — which is exactly what makes them useful. Lessons reconstructed six months later are platitudes everyone can safely agree with, which is why they change nothing.
Write the recommendation first
This is the whole technique, and it is why the template is shaped the way it is. Start with what you want the next project to do, then justify it with what happened to you. Not the other way round.
| Useless | Usable |
|---|---|
| "Data migration was more difficult than expected." | "Run a data-migration spike in week one, before committing the build. We assumed the legacy stock system could export cleanly; we discovered in week six that it could not, and lost three weeks re-planning." |
| "Stakeholder communication could have been better." | "Give the client's operations lead a standing 15-minute slot in the weekly call. She found two scope misunderstandings the moment she was actually in the room, both of which had been sitting in the plan for a month." |
| "The team worked well together." | "Keep the daily 10-minute stand-up even on a three-person project. It caught the duplicate work on the reservations module on day two rather than at code review." |
The test is brutally simple: could someone who was never on this project act on this sentence? If not, it is an observation, and observations do not transfer.
Three categories, and why the good ones matter
| Category | What it captures |
|---|---|
| Went well | A practice worth repeating — and why it worked, so it can be reproduced rather than just admired. A log of only failures teaches the next team what to fear, not what to do. |
| Went badly | The obvious one. Be specific about the cause, not the symptom — "we were late" is a symptom. |
| Near miss | The problem you nearly had. The cheapest lesson available anywhere, and almost nobody records them, because nothing went wrong so nobody feels the need. This is the category that quietly separates teams who learn from teams who merely survive. |
What each entry needs
- The recommendation — specific, actionable, first.
- What actually happened — the evidence, in enough detail to be credible.
- Category and stage — so a future project can filter to the phase it is in.
- Who raised it — the person to ask when the recommendation needs context.
- Date — proximity to the event is a quality signal in itself.
Notably not required: blame. A lessons log that reads as an inquest stops receiving honest entries within about a fortnight, and from that point on it is a fiction that costs you time to maintain.
Making lessons actually get learned
A lesson is captured when it becomes a specific recommendation. It is learned only when a later project does something differently because of it. Those are very different things, and most organisations do the first and call it the second.
Two mechanisms close the gap, and neither requires a culture change:
- Read the log at initiation, not at closure. Make "review lessons from comparable projects" a line item when writing the PID. A lesson consulted before the plan is set can still change the plan.
- Turn relevant lessons into risks. If a previous project lost three weeks to a broken data export, that is not history — it is a live entry on your risk register, with a probability you can now estimate rather unusually well.
A template is a snapshot. A project moves.
The hard part of lessons isn't the spreadsheet — it's remembering to write them down while they still hurt, and remembering to read them when it would help. In Guddle the lessons log lives with the project, is prompted at stage boundaries and closure, and the overnight analyst nudges you when a project is finishing without one.
Start free — first project on usThe other templates
Common questions
Is a lessons log the same as a retrospective?
They overlap but they are not the same thing. A retrospective is an event — a conversation, usually at the end of an iteration. The lessons log is the durable record, and it should be fed continuously, including by retrospectives. Running retros without a log means the learning never leaves the room.
Who owns the lessons log?
The project manager maintains it, but anyone should be able to add to it — and if only the PM ever writes in it, you are getting one person's view of what went wrong.
Is this an official PRINCE2 template?
No. It is an independent template written from scratch, aligned with the method's principle of learning from experience. It is not affiliated with, endorsed by, or copied from PeopleCert or AXELOS materials.