Why Lessons Learned Records Do Not Produce Learning

A lessons learned record is usually written at the end of a project. It captures what was achieved and what the team would now do differently. Its audience is the project file. The next engineer who faces a similar decision is not its audience, and rarely finds it.

Why the record fails the next engineer

The lesson is written as the post-effect of one project. It describes what happened there, in the circumstances of that project. By the time it could be useful, those circumstances have gone. The person who wrote it has moved on. A new engineer has started from the beginning. The product line has changed.

The principle behind the lesson has not changed at all. It is simply buried inside a story about a project nobody on the new team remembers.

Writing the lesson at the level of the principle

A lesson that can be reused is written as a principle. It is objective. It sits alongside general design guidelines and does not depend on a particular product, person or project.

There is a simple test. Would the lesson still make sense if the people, the product and the project had all changed? If it would, it is a principle. If it would not, it is a story.

What a usable lesson contains

Three things matter. First, how the lesson satisfies the requirements. Second, how it makes the design better. Third, how the designer’s approach changed, meaning what is now checked or asked earlier. The third is the easiest to leave out and the most useful to keep. It shows the reader what to do differently on their own design.

The difference the lesson makes

A lesson is more convincing when it shows what changes if it is followed. A short comparison of the design with the lesson and without it does this. It covers three things: the design margin, the safety position, and whether the rigour of detailed analysis before implementation was kept or given away.

This comparison is a reasoned estimate. Nobody can observe the design that did not follow the lesson. So it should state its basis and stay qualitative. It should not carry a score.

It should also never imply that more margin is automatically safer. Margin is the result of an honest comparison, not a safety allowance. The comparison shows where the margin sits and whether the safety position is demonstrated.

Lessons that travel

A lesson from another organisation does not disappear when the engineer who learned it moves on. It stays with the person as a way of spotting problems and resolving them against good design guidelines. Lessons written at the level of the principle can also be developed on a shared platform that any company uses, and improved by many people.

This only works if the lesson carries no project, client or confidential detail. What travels is the principle and the method of spotting the problem. The circumstances stay behind.

Ownership and retrieval

A lesson has to be carried to the point of decision. That might be a review, a requirement check or a design brief. Someone needs to own that job.

Without an owner, the record waits in an archive to be found. It is only found by someone who already suspects the problem exists. That is the person who needed it least.

A lesson has to change something

A lesson that changes nothing is only a memory. To teach, it has to change a guideline, a checklist or a process. Once it has, anyone can cross-check a design against it at any time, whoever they are and however long ago the lesson was learned. That is the real use of a lesson. How to build these checks properly is a subject of its own.

The test

There is a plain way to tell whether a record is producing learning. Ask whether it has changed anything since it was written. Ask who used it last. Ask whether it would still make sense if the people and the product had all changed. A record that cannot answer these is a record of a project. It is not yet a lesson.