Lessons Learned Meeting and Agenda Template

What is a Lessons Learned Meeting?

A lessons learned meeting is a structured session where a project team decides what to repeat and what to change next time. Its purpose is to convert experience into actions somebody owns.

A lessons learned meeting is also called a lessons learned workshop, lessons learned session, post-mortem, project retrospective, project debrief or post-project review. The output goes into the lessons learned register.

Lessons Learned Meeting Example

Here is a good example of a lessons learned meeting capture sheet, with eighteen observations recorded during a session on a retail center redevelopment.

When to Hold a Lessons Learned Meeting

Conduct a lessons learned meeting at each phase gate, after major milestones, and within four weeks of completion. Not only at the end.

PMI's best-practice guidance is to hold lessons-learned sessions at various times throughout the life of your project, and to review lessons from previous projects at the beginning of the next one. PMBOK's sixth edition added Manage Project Knowledge for the same reason: lessons should be captured continuously rather than only at closeout.

The Association for Project Management quotes Dr Penny Pullan arguing that a session held after a project ends is too late to change anything, and the report only gets filed.

Match the length to the occasion: ninety minutes for a full retrospective, an hour for many projects, ten minutes as a standing slot in a team meeting.

Lessons Learned Agenda: The 90-Minute Run Sheet

The silent write-down at item 2 is how the quietest person gets heard. The near misses at item 6 are the lessons nobody paid for. Reading actions back at item 8 is what stops the session ending in observations.

For a phase-gate review, run items 2, 4, 5 and 7 only. That fits an hour.

Questions to Ask in a Lessons Learned Meeting

Write the question before the meeting. PMI lists asking focused open-ended questions as a standard best practice, and an agenda of topic headings produces generalities.

• Purpose: We are here to change how the next project runs, not to decide whose fault it was.
• Silent write-down: Two things that worked and two that did not, on your own, before anyone speaks.
• Baseline: What did we say we would do on cost, time and scope, and what did we actually do?
• What worked: What would you do again, and what specifically made it work?
• What did not: Where did we lose time or money, and what was the first sign it was going wrong?
• Near misses: What nearly went wrong and did not?
• Actions: What changes, who owns it, and by when?
• Read back: Anything without a name against it will not happen. Is this list right?
• Where it goes: Who reviews the register, and before which project?

Question 5 produces the most useful answers, because "what was the first sign" moves the room from what happened to when it became knowable. PMI also recommends root-cause analysis on project problems.

Lessons Learned Meeting Ground Rules

Ground rules keep the session focused on what changes rather than who was at fault. Five cover it, read out at the start rather than attached to the invitation.

1. No names. Describe what happened, not who did it. Recording the role keeps the record safe to circulate afterward.
2. Everyone writes before anyone talks.
3. A complaint with no proposed change does not become an action. A complaint costs nothing to make. A proposed change means the person thought about the alternative.
4. Near misses count.
5. The facilitator reads every action and owner back before anyone leaves.

Who to Invite and What to Send With the Invitation

Invite the project manager, sponsor, cost manager, contract administrator, design manager, field representative and end user, plus a facilitator who was not running the project. Keep it to five to ten people. Send the agenda three days ahead, naming what each person brings.

PMI lists having someone other than the project manager facilitate as a best practice. Give them a separate note-taker, since facilitating and participating objectively at the same time does not work. For a troubled project, run an anonymous survey first and present the results without names.

How to Conduct a Lessons Learned Workshop Using This Template

Appoint a neutral facilitator, send the agenda three days ahead, run the session against fixed questions, and convert every agreed observation into a change with an owner and a date before anyone leaves.

1. Schedule it for the occasion: a phase gate, a milestone, or within four weeks of completion.
2. Appoint a facilitator who was not running the project, and a separate note-taker.
3. Send the Agenda sheet three days ahead, naming what each person brings.
4. For a troubled project, run an anonymous survey first.
5. Read the ground rules out at the start.
6. Run the silent write-down before any discussion.
7. Record what was observed on the Capture sheet, against the role that raised it, never the person.
8. Mark whether the room agreed, since a lesson one person holds is not yet a lesson.
9. Convert each agreed observation into an Actions row with a change, an owner and a date. Reject anything missing one.
10. Read every action and owner back before anyone leaves.
11. Move the actions into the register and name who reviews them, and before which project.

What's Included in This Lessons Learned Meeting Template

Five sheets, from invitation to owned actions.

Capture records the role, never the person. That is what makes the record safe to circulate.

Related Articles and Templates

Explore these resources for lessons learned meetings, project reviews, closeout, and continuous improvement:

• Project Meeting Agenda Template
• Project Meeting Minutes Template
• Construction Project Closeout Checklist
• Project Meeting Guide: Running Effective Construction Meetings
• Project Completion: Everything You Need to Know Before It Happens!
• Contract Closeout: Best Practices for Closing Out a Contract
• The Role of Project Governance in Construction Project Success