Project delivery
Lessons learned register
The situation, what was done, what resulted and what to do differently, with a category so the entry can be found later and an acted on column so the register is not a diary. Filled in during the project rather than at closure.
What it is
Most lessons registers are written at closure, which means they benefit a different project with different people while the project that learned the lesson gets nothing. Filling it in during delivery is the single change that makes the practice worth the effort.
The four columns that matter are the situation, what was done, what resulted and what to do differently. Registers usually hold the first and the last and skip the middle two, which is why they are useless to a reader who was not there. What was done tells them what has already been tried, and what resulted is the evidence that the recommendation is worth following.
The acted on column separates a register from a diary. A lesson with a recommendation and nothing in that column has been recorded rather than learned, and the three honest destinations are something this project changes now, something the organisation's standard changes, or knowledge for the next team.
When to use it
- Something went wrong and the same thing went wrong on the last project too.
- A project is closing and the team disperses within a fortnight.
- You want the current project to benefit from what it has learned rather than the next one.
- The organisation has a lessons repository that nobody searches.
The columns
- Ref
- Date
- Category
- Situation
- What we did
- What resulted
- What to do differently
- Applies to
- Raised by
- Acted on
The template
| Ref | Date | Category | Situation | What we did | What resulted | What to do differently | Applies to | Raised by | Acted on |
|---|---|---|---|---|---|---|---|---|---|
| L-01 | 2026-01-19 | Estimating | A custom transformer with a sixteen week lead was specified in the design phase scheduled for month six | Worked backwards from the need date and found the design freeze was already late | Design freeze pulled forward to month three, which forced a replan of everything feeding it | Run a lead time pass over every procured item before the schedule is baselined, not after | Any project with manufactured or bespoke items | Procurement | Yes, added to the planning checklist |
| L-02 | 2026-01-26 | Environments | Environment provisioning took six weeks and had been assumed to take one | Escalated per request, each time resolved in a few days | Roughly four weeks lost across three requests before anybody looked at the pattern | Request environments at initiation, and treat a repeated blocker as a systemic issue rather than a series of events | Every project in this organisation | Delivery lead | Raised with platform owner |
| L-03 | 2026-02-02 | Stakeholders | Regulatory affairs raised objections in month eight that required design changes | Reopened the design with them and reworked two components | Six weeks of rework that a month three conversation would have avoided | Revisit the stakeholder register whenever the plan is revisited, asking who is affected by what has been decided since | Any regulated delivery | Project manager | Yes, register review added to phase gates |
| L-04 | 2026-02-05 | Requirements | Requirements arrived incomplete from an analyst in another department for two months | Reported it in status for two months, then went to their manager with the delivery cost | The specific cost got a readiness standard agreed within a week | Escalate with the cost attached rather than the complaint, and go to whoever can act rather than through the report | Any cross department dependency | Project manager | Yes |
| L-05 | 2026-02-11 | Integration | Two teams built incompatible interfaces after coordination artefacts were dropped as unnecessary overhead | Adopted one interface as the standard and reworked the other | Two cycles of rework | When removing an artefact, name the job it was doing and say what now does that job | Any multi team delivery | Architecture | Yes, tailoring record now requires it |
Written during the project rather than at closure, because a lesson recorded in month two can still be applied by this project.
The four columns that matter
The situation, what was done, what resulted, and what to do differently. Most registers hold the first and the last and skip the middle two, which is why so few of them are useful to a reader who was not there.
What we did matters because the reader needs to know what has already been tried. What resulted matters because it is the evidence that the recommendation is worth following, and a recommendation with no observed consequence behind it is an opinion.
Write for a stranger
The test is whether somebody starting a project next year, who has never met you, could act on the row. That rules out shorthand, internal system names without explanation, and anything that assumes the reader remembers the context.
It also rules out the two failure modes registers usually contain. Blame, which stops people contributing honestly, and platitudes, since better communication is needed is true of every project ever run and tells nobody what to do on Monday.
Categorise so it can be found
The category column is what makes the register searchable later, which is the difference between a repository and a graveyard. Keep the list short and reuse it. Estimating, environments, stakeholders, requirements, integration, procurement, governance and testing will cover most of what a delivery project produces.
Applies to is the other half of retrieval. A lesson that only holds for regulated work should say so, and one that holds for every project in the organisation is a candidate for changing the standard rather than for filing.
The Acted on column
This is the one that separates a register from a diary. A lesson with a recommendation and nothing in this column has been recorded and not learned.
Acting on it has three destinations. Something this project changes now, which is the whole reason to keep the register during delivery. Something that changes the organisation's standard, which goes to whoever owns it. Something that is genuinely just knowledge for the next team, which is fine, and should be honest about being that.
When the same lesson appears three times
Three teams independently recording the same finding is not three lessons. It is evidence that the system produces the problem, and the fix belongs to whoever owns the thing causing it.
Carrying that pattern upward is a project manager's job rather than a team's, because no individual team can see across the others. Adding the workaround to a checklist is worth doing and it settles for coping, and the outcome to seek is that the cause goes away.
Questions people ask
- How do you write a lesson somebody else can use?
- Assume a stranger starting a project next year who has never met you. That rules out shorthand, internal system names without explanation, and anything assuming the reader remembers the context.
- What if the same lesson appears from three teams?
- Then it is not three lessons, it is evidence that the system produces the problem. The fix belongs to whoever owns the cause, and carrying that upward is a project manager's job because no single team can see across the others.
- Is this different from a retrospective?
- A retrospective is the meeting that produces the finding and decides one change the team will make. This is where findings worth keeping beyond the team are recorded so they can be found later.