Lessons Learned
Lessons learned is a structured review, held at the close of a project or phase, in which the team records what worked, what failed, the causes of each and recommendations for the work that follows. BABOK also calls this technique a retrospective, and in practice it is known as a project debrief or after-action review. Its raw material is honest speech about what went wrong, and that speech is what goes missing when participants fear being held to blame. Psychological safety is the condition without which the technique produces only platitudes.
Goal
Lessons learned serves to compile and document the successes, opportunities for improvement, failures and recommendations that will improve the performance of later projects or phases. It is a retrospective evaluation technique: it looks back on completed work so the next piece runs better, and it produces a lessons-learned register the organisation reuses.
What sets it apart is what it depends on. An interview or a document analysis draws its value from facts that already exist. A lessons-learned session draws its value from what participants agree to say, and that material is fragile. BABOK states this among the technique's limitations: honest discussion does not happen if participants are looking to assign blame, and they are often reluctant to document and debate problems. The PMBOK Guide files lessons learned among the organisation's knowledge repositories, but a repository fed by guarded speech mostly records what could be said without risk.
The technique has a double object. It aims at a deliverable, the register, and at a condition, the safety that makes that deliverable honest. Running a session means first managing that condition, which separates it from an end-of-project report.
Usage
When to use it
- Close of a project or milestone: while memory is fresh, before the team disperses.
- End of an iteration or sprint: the agile retrospective is the same technique, held at short cadence to raise quality and effectiveness.
- After an incident or a difficult go-live: turn a costly episode into traceable recommendations.
- Stable team running project after project: accumulated trust makes speech franker at each session.
- Continuous improvement backed by management: a setting where raising a problem stays without consequence for the person who raises it.
When not to use it
- A blame climate that facilitation cannot defuse: in the wake of layoffs, for instance, honest speech will not come; use anonymous collection, an external facilitator or defer the session.
- No channel where recommendations land: with no owner, no improvement backlog and no repository anyone consults, the register stays a dead letter; fix the follow-through mechanism first or hold a simple check-in.
- A short, low-stakes task: the cost of a facilitated session exceeds its return; a two-line note suffices, and the technique is reserved for milestones there is something to learn from.
Description
The format is free, and BABOK insists on it: the session takes whatever shape the key stakeholders accept, a facilitated meeting with an agenda and assigned roles or an informal working session. It is held at a project's close as much as at the end of any internal milestone. The review covers the business analysis activities and deliverables, the final solution, the technologies introduced or retired, the effects on processes, the gap between expected and actual performance, the variances, the root causes that weighed on the results and the recommendations for what follows. When the work has counted notable successes, a share of celebration has its place and rebalances a session that problems pull toward the negative.
The condition first: honest speech
The whole technique rests on a social fact. A participant who thinks an admission will be held against them will not voice it, and the register will inherit that silence. Two rules held by the facilitator open up speech. The first separates the person from the process: you examine why a step failed, not who ran it, and a sentence that starts to name a culprit is steered back to the mechanism. The second anchors the discussion on evidence prepared in advance, metrics, variances and deliverable data, because a shared number moves the debate from a quarrel of memories toward a finding no one owns personally.
The facilitator's role
BABOK notes that proactive facilitation is often needed to keep the discussion turned toward solutions and improvements. This calls for a neutral facilitator with no personal stake in the findings, which argues for someone outside the team's reporting line when the subject is sensitive. Their concrete work is to gather both halves, successes and problems, to keep the room from settling on the first person named and to push each finding through to its root cause, drawing on root cause analysis where needed, then on to a recommendation. A finding that stops at the symptom, "the tests missed the slowness", is not yet a lesson as long as the cause is not named.
When safety is thin
When trust is not enough to secure candour, collection precedes the session and is done anonymously. A questionnaire distributed before the meeting gathers findings without tying them to a name, and the session then works on an already-consolidated list rather than requiring each person to expose themselves live. It is the same choice that leads to having the retrospective run by a third party rather than by the project manager, whose mere presence can hold back half the findings.
What the session produces
The deliverable is the lessons-learned register, where each finding carries its root cause, a recommendation and an owner. Two columns make it a lesson rather than a complaint: the cause, without which a finding says nothing actionable, and the owner, without which a recommendation has no addressee. Once speech has been secured, the trap moves to follow-through: a register written and then filed away, that no start-up review reopens, is the quietest failure mode, because the document looks finished while the loop has stayed open.
AI considerations
Help sits before and after the session. Beforehand, a model gathers scattered observations drawn from tickets, logs and iteration reports, then proposes candidate findings no participant would have voiced from memory. Prior anonymous collection benefits from this pre-processing: it consolidates the feedback without exposing its authors. Afterward, a model shapes the recommendations, checks that each carries an owner and a due date, then flags the line that stays a finding for want of a cause or a recommendation.
The limit is the very condition of the technique. Psychological safety is built between people in a room, and no tool manufactures it. A root cause a model proposes is plausible and still to be verified: it enters the session as a hypothesis to test against the project's real context. The material, finally, is often named or sensitive, team assessments, incidents, HR elements, and injecting it into an external tool would betray the confidentiality on which candour rests, outside the legal basis and the authorisation that data protection requires.
Examples
Two failure rows, the ones that acknowledge an inadequate test and a poorly framed scope, appear in the register only because the room was safe enough to name them without looking for a culprit. Each row carries a finding, its root cause, a recommendation and an owner. It reads as the passage from an observation to an action entrusted to someone.
The setting: a closing review after the go-live of an online statement portal at a health insurer in French-speaking Switzerland.
| Finding | Root cause | Recommendation | Owner |
|---|---|---|---|
| The slowness that surfaced in production had not been seen in acceptance testing. | The test dataset did not reflect the real volume of statements. | Provision a production-scale dataset before acceptance testing. | Test lead |
| Two iterations spent reframing the scope. | The acceptance criteria had not been validated with the business at start-up. | Have the acceptance criteria validated by the business owner before development. | Business analyst |
| Strong take-up of self-service by the insured members from day one. | Usability workshops held early with a panel of insured members. | Repeat these user workshops upstream on the coming projects. | Product owner |
| The previous project's register was not consulted at launch. | No review of prior lessons is scheduled at a project's opening. | Open every project with a review of the register from comparable projects. | Project management office |
Visualisations
The register is made of rows and columns, so it is written as a table kept in a document, one that sorts and reopens at the next project. A second figure lights up the circuit the table does not show, from the milestone to the start of the next project, with its two break points: the finding recorded with no cause or owner and the register written and then never reopened. These two breaks are specific to this technique, and a generic continuous-improvement wheel would not mark them.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Gather metrics and variances, but also prepare the safety setting: choice of facilitator, prior anonymous collection when candour is not a given. |
| Execution | Low | A two-hour session suffices for a mid-sized project. The cost lies in the facilitator's attention. |
| Documentation | High | The register is written, linked to the improvement backlog and tracked until every recommendation is handled. This follow-through is the lasting load. |
Tools
The session asks only for a surface held live, a flip chart, whiteboard or shared document, and remotely a digital whiteboard (Miro, Mural) plays the part of the wall. When safety is thin, the tool that matters is the one for anonymous collection: an online questionnaire gathers findings before the session without tying them to a name.
The register lives in a spreadsheet or in the organisation's document space, where the owner and due-date columns become visible constraints. Follow-through gains from moving into the usual work tool, each recommendation becoming an item on the improvement backlog or a tracked ticket. Incident-management platforms offer blame-free post-mortem templates where the analysis and actions are structured fields, useful when the session follows an incident.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.27 Lessons Learned: the purpose, the free format, the objects under review, the strengths and above all the limitations tied to honest discussion and to facilitation.
- PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th edition: pmi.org/standards/pmbok. Lessons learned as one of the organisation's knowledge repositories.
- Schwaber and Sutherland, The Scrum Guide (2020), Sprint Retrospective: scrumguides.org. The recurring form of the technique, held at every sprint to raise quality and effectiveness.
- Swiss Confederation, Federal Chancellery, HERMES 2022, Closure phase: hermes.admin.ch. The end-of-project assessment and the project experience recorded at closure.