A lesson learned is knowledge produced by doing the work and recorded so that somebody else can use it. Nearly every part of that sentence is where the practice breaks down in real organisations, beginning with when it happens.
Continuous, not a workshop at the end
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
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 of these 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
A reusable lesson has three parts and a platitude has none of them. 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
Entries have to be findable by the situation they came out of rather than by the project that produced them. 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.