Lessons learned: capturing them so the next project is different

A lessons learned review looks back at a project or a period and asks what should be done differently next time. Almost every organisation runs them and almost none benefits, because the output is a document filed in a folder that the next project team does not know exists — and would not read if they did.

The failure is not the meeting. It is that a lesson written as a general observation cannot be applied, and that nobody has decided who would apply it or when. "Communication could have been better" is not a lesson; "the client's legal review took three weeks and we had planned for three days — add it to the schedule template" is.

What makes a lesson usable

• A specific situation, described concretely enough that someone recognises it when it recurs.
• What happened, including the size of the consequence — days lost, money, a relationship damaged.
• Why it happened, at the level of the process rather than the person.
• The recommended change, stated as an action someone can take.
• Where it should be applied: which document, template, checklist or decision it changes.
• An owner for making that change, and a date.
• A category, so lessons can be found by the situation that would trigger them.
• Whether the change was actually made — a status field, checked later, without which the whole exercise is optional.

The test of a lesson is whether it can be attached to something. A lesson that changes the estimating template, the kick-off checklist, the standard contract or the onboarding form will be applied automatically the next time someone uses that artefact. A lesson that lives only in a document relies on someone remembering to read it, which is the mechanism that has already failed.

Running the review

1. Hold it within a week of the milestone or project ending, while detail is fresh and before the team disperses.
2. Invite the people who did the work, not only the leads. The most useful observations come from whoever hit the problem.
3. Ask people to write privately for five minutes before discussing. Group discussion first converges on the loudest view.
4. Cover both directions: what worked and should be repeated is as actionable as what failed.
5. Keep it blameless in framing and specific in content — those are compatible, and the second is what makes it worth doing.
6. Cut the list to the three to five lessons with real consequences. A list of twenty is a list nobody acts on.
7. For each, name the artefact it changes and who changes it, with a date.
8. Circulate the changes, not the document. "We have added a three-week legal review to the schedule template" is read; a ten-page report is not.
9. Check the actions a month later, and record which were made.

Where lessons should live

The instinct is a central repository of lessons learned, searchable by project. In practice these become archives — comprehensive, well-intentioned, and unopened. The alternative is to push each lesson into the place where the relevant decision is made: the estimating spreadsheet, the kick-off checklist, the statement of work template, the onboarding form. The repository still has value as a record, but the mechanism that actually changes behaviour is embedding, not filing. If you only have energy for one, embed.

In Ettex, the session notes fit Ettex Notes — one note per review, with checklists inside the note so each lesson's action becomes an item with visible progress, tags to keep a project series together, backlinks so a lesson can point at the document it changes, reminders for the follow-up check, and version history showing what was added after the meeting. The artefacts the lessons modify live in Ettex Docs with version history, so a change is traceable to the review that caused it; the actions can be tracked as cards in Ettex Board; and a register of lessons across projects, if you want one, fits Ettex Records as a typed table.

The boundary: Ettex has no knowledge-management or retrospective feature. There is no lessons repository, no tagging engine that surfaces relevant past lessons when a new project starts, no prompts and no analytics across projects. Notes, checklists and links are what you get — and the discipline of embedding a lesson into a template is a habit rather than a feature.

Collecting them is only useful if somebody checks the outcome later. A post implementation review does that three to six months after go-live: benefits measured against what was promised at approval, and each finding converted into one owned change.

Capturing what happened is only half of it. A decision log records what was chosen, by whom, and — the part always left out — which options were rejected and why, which is what settles the argument when somebody proposes one of them again two years later.

Why lessons learned achieve nothing

• Held months later, when only the outcome is remembered and not the causes.
• Attended by leads only, so the people who hit the problems are absent.
• Lessons written as general observations that cannot be acted on.
• Twenty lessons instead of four, which guarantees none is implemented.
• No owner or date attached to the change.
• Filed in a repository nobody opens rather than embedded in a template someone uses.
• Blame framing, after which people stop contributing anything real.
• Actions never checked, so the same lesson is learned again next year.

A lessons learned review is worth an hour if it produces four lessons, each attached to a template someone will use again, with an owner and a date — and a check a month later that the change was actually made.