Project Lessons Learned: A Practical How-To Guide
Ask most project managers about their last lessons learned session and you will hear a familiar story: a ninety-minute meeting at project close, a list of things that went wrong, a document uploaded to a shared drive, and nothing that changed on the next project. The lessons learned process is one of the most consistently underperformed practices in project management — not because organisations lack the intention but because they lack a structured approach. This guide offers one.
Why Lessons Learned Are Often Done Poorly
Three structural failures account for most of the damage. First, timing: lessons learned are treated as a close-out activity, conducted weeks or months after the events that generated the lessons, when memories have faded and the team has dispersed. Second, documentation: the output is a flat list of items in a spreadsheet or a Word document, with no owner, no action, and no connection to the processes that need to change. Third, transfer: the lessons sit in a repository that no one consults when the next project starts. The knowledge exists on paper but not in practice.
There is also a psychological barrier. Lessons learned sessions that are conducted without adequate preparation frequently devolve into blame attribution. Team members who fear that honest contributions will be held against them in performance reviews simply do not contribute honestly. The facilitator's job is to create the conditions in which candour is safe.
When to Conduct Lessons Learned
Project close is not the only — or even the best — time to run a lessons learned exercise. Consider the following cadence:
After each major phase or milestone: a brief retrospective (30–60 minutes) while the experience is fresh. Capture what worked, what did not, and what should be adjusted for the next phase.
Following a significant issue or escalation: an immediate after-action review focused on that specific event. The goal is to understand the cause and prevent recurrence, not to wait until close to discuss it.
At project close: a comprehensive session that synthesises the phase-level reviews and adds any final observations. This is the session that feeds the organisational knowledge base.
Post-implementation: three to six months after go-live, when the benefits (or absence thereof) are visible. This review captures lessons about the quality of the project's outputs, not just its delivery process.
How to Facilitate a Productive Session
Structure and psychological safety are the two levers that determine whether a lessons learned session produces genuine insight or defensive noise.
On structure: prepare participants in advance with the questions they will be asked. Typical structured questions include: What went well that we should deliberately repeat? What did not go as planned, and what was the root cause? What would we do differently if we were starting again? What risks or issues did we not anticipate, and how would we catch them earlier next time? Providing these questions ahead of time allows participants to reflect rather than improvise.
On psychological safety: separate the lessons learned session from any performance review process, explicitly and publicly. Make it clear that the goal is to improve the system, not to evaluate individuals. A useful facilitation technique is to frame every contribution in systemic terms — not "the estimating was poor" but "our estimating process did not account for X." This shifts the conversation from who did what to what the process allows or prevents.
Keep the group to eight to twelve people — large enough to capture diverse perspectives, small enough to allow genuine discussion. If the project was large, run separate sessions by workstream and then synthesise.
What to Capture
A lessons learned record that is genuinely useful has four elements for each lesson: a clear description of what happened, the root cause or contributing factors, the recommended action or process change, and an owner and target date for that action. Without the last two, the lesson is an observation, not an actionable finding.
Categorise lessons: delivery process, stakeholder management, risk management, resource management, technology and tools, scope management. Categories make the knowledge base searchable and reveal patterns across projects over time.
How to Make Lessons Transfer
The transfer problem is a design problem, not a motivation problem. Lessons do not transfer because the knowledge base is not consulted at the start of new projects. Fix the design: build a mandatory "lessons from similar projects" review into the project initiation checklist. Assign the PMO or a project coordinator to pull relevant lessons and present them at the kickoff. Assign action owners for systemic changes (process updates, template revisions, training) and track completion.
Lessons that generate changes to standards, templates, or processes have transferred. Lessons that sit in a document have not.
XNM Consulting helps organisations strengthen project delivery through structured processes, coaching, and knowledge management. Learn more about our programme and project delivery services.