A lesson learned is knowledge produced by doing the work and recorded so that somebody else can use it. PMI gives it a register of its own, kept from the start of a project, and a repository at organisational level that the register feeds at closure. Nearly every part of the opening sentence is where the practice breaks down in real organisations, beginning with when it happens.
The sections below take the parts in order. When lessons are captured, where they are kept, why the process usually fails, what makes a single lesson reusable and what makes a repository worth searching.
Why lessons are captured continuously
An end of project workshop produces lessons at the moment they can no longer help the project that produced them. The estimating error visible in month two, the supplier onboarding that ran three weeks past what was assumed, the environment that was never ready when the plan said it would be, every one of those was knowable while there was still time to use it.
Capturing continuously changes what the record is for. A lesson raised in month two gets applied in month three by the same team, and anything still standing at closure has been tested at least once already. It also removes the recall problem, because a workshop held eighteen months after a decision produces a reconstructed version of events shaped by how the project happened to end.
The register and the repository
Continuous capture needs somewhere to go, and there are two places. The lessons learned register belongs to this project. It is opened early, added to throughout, reviewed on the same rhythm as the risk register, and it is where a lesson goes in the week somebody notices it.
The repository belongs to the organisation. It is where the register's contents go at closure, and it is the only part of the mechanism that serves anybody outside the team that wrote it. Conflating the two is why so many organisations hold a repository of end of project reports and no register anywhere. A register can be terse because its readers share the context, while a repository entry has to carry enough context to make sense to somebody who was not there.
Why most lessons learned processes fail
Capture is the part organisations already do well. They run the workshop, fill in the template and file the document, on time and to the standard the governance function asked for. What fails is that nothing reads the output.
Nothing in the surrounding process obliges anybody to. A charter is approved without a search of the repository, an estimate is signed off without being reconciled against what comparable work actually cost, and a supplier is chosen without anybody checking how that supplier performed last time. The repository accumulates and nothing consumes it, and within a couple of years the capture degrades too, because people stop spending effort on a document that has no reader.
The remedy sits on the consumption side. A planning step that obliges somebody to look up the three most comparable previous projects and state what was taken from them turns a repository into an input. Everything else in the process can be mediocre and it will still pay. Nothing else in the process compensates when this step is absent.
What makes a lesson reusable
The lookup only helps if the entries it finds can be used, and a reusable lesson has three parts that a platitude lacks. It describes the situation precisely enough that a reader can tell whether it matches theirs, it says what was actually done, and it says what resulted, with a figure wherever one exists.
Set the two side by side and the difference stops being a matter of opinion.
| Part of the entry | A decorative entry | A reusable entry |
|---|---|---|
| The situation | Stakeholder communication on Project Alpha | A fourteen month regulatory programme with a steering group of eleven, of whom four could actually decide anything |
| What was done | Not recorded | Weekly written updates went to all eleven for the first four months |
| What resulted | Not recorded | No questions came back for two months, and the escalation in month four surprised half the group |
| What was changed | Communicate better with stakeholders next time | The written update was replaced by a fortnightly thirty minute call with the four who could decide |
| What the change produced | Not recorded | Two objections surfaced in the first session, both of which would have arrived as escalations later |
| How it is filed | Under the project name | Under steering group design, which is the decision it bears on |
| Where it applies | Everywhere, by implication | One programme in one organisation, and untested where the group sits across time zones |
Communicate better with stakeholders fails the first three rows outright. It names no situation, no action and no result, which is precisely why it survives review, since there is nothing in it anybody could disagree with.
The right hand column is longer and the length is incidental. What it contains is a situation somebody can match, an action somebody can copy and an outcome somebody can weigh, which is the difference between a reusable record and a decorative one. The last row earns its place as much as the first, because a reader who knows where a lesson has been tested knows how far to trust it.
Making the repository worth searching
The last row is also how the entry is filed, and entries have to be findable by the situation they came out of. Filing by project name is how a repository becomes unusable, because nobody with a problem knows which project met it first. Filing by the decision a lesson bears on, such as fixed price supplier selection or data migration sequencing, is how the person facing that decision finds it.
The other half is pruning. Nine thousand entries return noise and two hundred maintained ones return answers, so somebody has to own the removal. Where nobody does, a repository grows until it is quietly replaced by asking a colleague who was there.