Lessons Learned: What the Record Should Contain
Lessons learned are recorded observations about what worked and what did not during delivery, captured so that later projects can act on them. A usable lesson names what happened, the effect it had, the cause, and the specific change recommended, with an owner for that change. Without the recommendation and the owner it is an anecdote.
What a lesson record holds
| Field | Why it is needed |
|---|---|
| What happened | The event or pattern, factually and without attribution of blame |
| Effect | What it cost in time, money, quality or reputation |
| Root cause | Why it happened, one level below the symptom |
| Category | Planning, requirements, vendor, testing, data, governance, resourcing |
| Recommendation | The specific change proposed, phrased so someone could act on it |
| Applies to | Who this is relevant for: future projects, the PMO, a vendor relationship |
| Owner of the change | Who takes the recommendation forward. Blank means it will not happen |
| Status | Raised, accepted, actioned, rejected with reason |
How it is used
Lessons are captured continuously and reviewed at points, not gathered once at the end. Waiting until closure means the people involved in the early phases have moved on and the detail is gone; it also means the project itself never benefits from anything it learned. Practically, that means a lessons line in the log whenever something notable happens, plus a review at each stage boundary and at closure.
The output that matters is not the log. It is the set of accepted recommendations with owners attached, held somewhere that a future project will encounter them — a PMO checklist, a standard risk list, a revised template, a changed contract clause. A lessons log filed in a project folder is read by nobody. The project closure report carries the log alongside the closure report and the handover checklist, and the project closure guide covers how the review is run and what makes a lesson worth writing down.
There is also a live use. Lessons from one workstream frequently apply to another still in flight, and the fastest route is into the risk register: a lesson from an early wave becomes a named risk with a mitigation on the next. Logged that way in the RAID log template, the lesson gets acted on while it still matters. Where the lesson concerns stabilisation after go-live, it usually belongs with the material in the hypercare guide.
Where it goes wrong
- Captured only at closure. The end-of-project session recovers the last two months and loses the rest.
- Written as generalities. "Communication could have been better" cannot be acted on by anyone.
- No owner for the recommendation. An accepted lesson without a name against it changes nothing.
- Blame in the record. Once lessons name individuals, contributions dry up and the honest ones stop being written.
- Positive lessons omitted. What worked is as reusable as what failed, and cheaper to repeat.
- Never read. If nothing in the organisation consults the log before a new project starts, the exercise is archival.
- Same lesson every time. A recurring lesson across projects is not a lesson; it is an unaddressed organisational problem.
Related terms
Project closure — the point at which the final review is held and the log is handed over. Retrospective — the agile equivalent, run per iteration rather than per project. Post-implementation review — the later review of whether the outcome was achieved. RAID log — where live lessons are most usefully converted into risks for work still running.
Questions
When should lessons be captured?
Continuously, with reviews at each stage boundary and at closure. Capturing only at the end loses the early material and prevents the project from acting on its own findings.
Who runs a lessons learned session?
Someone not accountable for the outcome being discussed — a PMO representative or another project manager. A session facilitated by the person whose decisions are under review tends to produce polite lessons.
What makes a lesson useful?
A specific recommendation someone can act on, with an owner. "Involve the data team before mapping starts, not after" is actionable. "Better planning needed" is not.
Where should lessons be stored?
Somewhere a future project will actually encounter them: a PMO standard risk list, a revised template, a kickoff checklist. A log in a closed project's folder does not get found.