How to Write Project Lessons Learned: A Practical Guide
A lessons-learned document captures what a project taught the team, what worked, what did not, and what to do differently next time. Every project is an expensive education; the lessons-learned document is how you keep the tuition from going to waste. Without it, the next project makes the same mistakes with a different team.
When to Use This
Write it at the end of every project, as part of the closure process, ideally within two weeks of the project finishing, while memories are fresh. For long projects, capture lessons at major milestones too, so early insights are not forgotten by the end. It applies to successes as well as failures: understanding why something went well is just as valuable as understanding why it did not. Even a small project deserves a one-page version, the team that ran a flawless event should write down why it was flawless.
How to Fill It Out
Section 1: Project summary. Write three or four lines: what the project was, when it ran, what it cost, and whether it met its objectives. “Warehouse refit, January–June 2027. Budget £120,000, final cost £126,400. Completed two weeks late; all objectives met.” This gives future readers the context they need to judge whether the lessons apply to their project.
Section 2: What went well. List the things the team should repeat. Be specific about causes, not just outcomes. Not “the team worked hard” but “the weekly 30-minute stand-up with the contractor caught the electrical issue in week 3, saving an estimated £8,000 in rework.” Specific causes become repeatable practices; vague praise becomes nothing. Ask each team member for their top two, the project manager does not see everything.
Section 3: What did not go well. List the problems honestly, with root causes. “The till-system testing started three weeks late because we assumed the supplier’s test environment would be ready; it was not, and we had no backup plan. Impact: launch delayed by two weeks.” The rule: describe problems without blaming people. “Testing started late because the environment was not ready” invites a fix; “Tom failed to arrange testing” invites defensiveness and silence. People only contribute honest lessons in a blame-free setting.
Section 4: Recommendations for next time. Turn every significant lesson into a concrete recommendation with an owner. “Recommendation: for any project depending on a supplier’s test environment, confirm availability in writing eight weeks before it is needed, with a named backup contact. Owner: IT lead to add to the project checklist.” A lesson with no recommendation and no owner is just a story. Aim for five to ten recommendations, enough to matter, few enough to act on.
Section 5: Surprises. Note anything unexpected, good or bad. “Surprise: the night-shift staff, who were not consulted in planning, identified a layout problem in week 2 that the day team had missed. Lesson: include all shifts in the design review.” Surprises are where the most valuable lessons hide, because they reveal the gaps in how the team thinks.
Section 6: Distribution. Record who received the document and where it is stored. Lessons that sit in one person’s folder help nobody. Send the summary to the teams that run similar projects, store the full document where future project managers will find it, and present the top three lessons at the next team meeting.
Common Mistakes
1. Doing it six months later. Memories fade and people move on. A lessons-learned session held half a year after the project ends produces polite generalities, not real insight. Schedule it within two weeks of completion, while the frustrations and the fixes are still vivid.
2. Turning it into a blame exercise. The moment the session becomes about who messed up, honesty stops. Set the ground rule up front: we discuss processes and decisions, not people. The project manager should model this by naming their own mistakes first, it gives everyone else permission to be honest.
3. Collecting lessons nobody reads. A 20-page document filed and forgotten is wasted effort. Keep it short, two to four pages, lead with the recommendations, and actively share them with the teams starting similar work. The test of a lessons-learned document is whether the next project does something differently because of it.
4. Only recording failures. Teams remember the disasters and forget the wins. But knowing why the supplier relationship worked brilliantly is exactly the knowledge that prevents the next project from choosing badly. Capture successes with the same rigour as failures, and name the practices worth repeating.
Who Needs to Sign Off
The project manager drafts the document after a lessons-learned session with the core team, everyone who did significant work should contribute. The sponsor reviews and approves it, confirming the recommendations are fair and actionable. For cross-department lessons (for example, a recommendation that changes how IT and operations work together), the affected department heads should agree before it is published.
How Often to Review and Update
The document is written once, at project close (or at major milestones for long projects). But its recommendations should be reviewed quarterly by whoever owns the team’s project practices: which recommendations were adopted, which worked, which were ignored and why. Each new project’s kickoff should include a five-minute review of relevant past lessons, that is the moment the document earns its keep.
Download the free Project Lessons Learned Template.