Lessons Learned: Five Questions That Work, How to Run the Session and a One-Page Template Builder

Every team has learned the same lesson four times. It is called "lessons learned" in the way a revolving door is called "an exit": a lot of motion, a pleasant feeling of progress and, somehow, you end up on the same sidewalk.

The usual ritual goes like this. The project ends. Someone sends a calendar invite titled "Lessons Learned," forty minutes before lunch. Everyone says it went pretty well. Someone mentions that communication could be better, which is true of every project in history. A person with a laptop types "improve communication" into a document, the document is saved in a folder, and the next project starts with the same blind spots and a fresh set of snacks.

This guide explains how to run a lessons learned session that actually changes how you work. It covers why most of them fail, the five questions that make a session useful, how to run the conversation, how to find the cause behind a symptom, how to turn lessons into actions with an owner and a date and how to store them so the next team finds them. In the middle there is a builder that turns your answers into a one-page lessons learned summary. Nothing you type leaves your browser.

Why most lessons learned sessions fail

Before the fix, the diagnosis. Sessions go wrong in five predictable ways.

1. They happen too late. At the end of a long project, memories have faded, people have moved on and the energy is gone. The details that explain why something happened are already lost.
2. They become a blame session, or the opposite. Either someone is on trial, so everyone defends themselves, or nobody says anything real because nobody wants to be the person who spoiled the party.
3. They list symptoms. "Late deliveries." "Poor communication." "Scope changes." These are weather reports, not causes.
4. Nothing has an owner. A lesson without a name and a date is a wish.
5. Nobody looks at the notes again. The file is stored where the next team cannot find it, and even if it could, nobody would think to look.

The cure for all five is the same: a short, structured conversation, held early and often, that ends in a small number of actions with names. The rest of this guide shows how.

The five questions

The format below borrows from several well-known practices. The US Army's after-action review asks what was supposed to happen, what happened, why there was a difference and what to do next time. Agile teams use retrospectives, and engineering teams write blameless postmortems. They differ in detail and agree on the structure. Here it is in five questions, for any kind of project.

1. What did we set out to do, and what actually happened? Start with facts, in numbers where possible: the planned date and the real one, the budget and the actual cost, the scope promised and the scope delivered. If you wrote a project charter, it holds the plan. Put the two side by side. Do not explain yet.
2. What went well, and why? Many sessions skip this, which is a mistake. Success has causes too, and if you do not name them, you will not repeat them. "The weekly 20-minute call kept the vendor honest" is a lesson.
3. What did not go well, and why? Ask "why" until you reach something you can change. The first answer is nearly always a symptom.
4. What surprised us? Surprises are the best signal of a wrong assumption. A surprise is the distance between what you expected and what happened, and that distance is where learning lives.
5. What will we do differently next time, who owns it and by when? This is the only question that produces change. Aim for three to five actions, not twenty. Each action has a person and a date.

Write the five questions on a whiteboard, or set up three columns on a wall: keep, change and try. Everything people say goes into one of them.

Run the conversation

The format matters less than the room. A few practical rules turn a stiff meeting into a useful one.

• Do it soon. Within a week or two of a milestone or the end, while people can still remember details. For a long project, do a short one at each milestone.
• Invite the people who did the work, not only those who managed it. The best information is with the person who spent three days finding a workaround.
• Keep it small enough to talk. Four to ten people. Larger groups split into pairs first and then share.
• Pick a facilitator who was not the project's boss. Someone neutral keeps the time and asks "why." If the project manager facilitates their own session, everyone can feel it.
• Set the rule out loud: this is about the work and the decisions, not about the people. What did the process make easy, and what did it make hard?
• Give people silent time. Ten minutes of writing on notes before anyone speaks gives quiet people a voice and avoids the first loud opinion becoming everybody's opinion.
• Timebox it. Sixty to ninety minutes, with a clear end. Longer sessions drift.
• Bring the data. The plan, the schedule, the budget, the issue list and the status reports. Memory is generous with the good and forgetful about the bad.

A good opening sentence from the facilitator: "We are not here to decide who was right. We are here to decide what we will do differently on the next project." Say it, and mean it.

Dig for causes, not symptoms

The difference between a useful lesson and a useless one is usually one more "why."

Take a small, illustrative example: a bakery's second location opened two weeks late.

• Why did it open late? The health inspection was rescheduled. (Symptom.)
• Why was it rescheduled? The application had missing documents. (Closer.)
• Why were documents missing? Nobody was responsible for assembling the permit package. (Cause.)
• Why did nobody own it? The task was not on the plan, because the plan was built from the contractor's schedule, which covers only construction. (Root cause.)

The final answer produces a lesson you can use: "Build the plan from the opening day backward, including permits, hiring and inspections, not only from the construction schedule." Compare that with the original symptom, "inspection delay," which would have produced the equally useful action, "try to schedule inspections earlier."

A simple way to do it: ask "why" up to five times, stop when you reach something the team can control and write that down. If the answer is "bad luck," ask what would make you less exposed to it. Often there is something, like a buffer, a second supplier or an earlier decision date. For a related tool, our guide to the risk register shows how to turn a surprise into an early warning.

From lessons to actions

A lesson becomes real when it turns into a change in how the next project is run. Four tests help.

1. Is it specific? "Plan better" fails. "Add a permit package task to every plan, owned by the project manager, at week one" passes.
2. Does it have an owner? One person, by name, who can actually make the change.
3. Does it have a date? When will it be done, or when will it first be used?
4. Will it be seen at the right moment? The best lessons are built into something people already use: a checklist, a template, the project charter, the risk list or the kickoff agenda. A lesson in a report is a footnote. A lesson in the checklist is a habit.

If you keep a decision log, record the decision to adopt each lesson there, with the reason. It saves you from re-arguing it in a year.

What good lessons look like

A few examples, to calibrate the level of detail. All are illustrative.

• Keep: "The 20-minute Tuesday call with the contractor caught three problems before they reached the site. Keep it, and add the electrician."
• Keep: "We agreed on what 'done' meant for each deliverable at the start, and nobody argued at the end."
• Change: "Decisions waited for the owner for an average of nine days. For the next project, name a decision-maker and a backup, and promise answers in three working days."
• Change: "The budget did not include a contingency, so every surprise became a negotiation. Reserve a percentage at the start, and spend it on purpose."
• Try: "Test the checkout process with five real customers one week before launch, instead of with the team."
• Try: "Limit work in progress to three items per person. See what happens to cycle time." (The kanban guide explains why that can work.)

Notice the pattern: each describes something observable, gives the reason and says what to do.

Do it at every milestone, not only at the end

The most useful lessons for this project arrive while the project is still running. A thirty-minute mini-session at each milestone, with the same five questions, catches a pattern while there is still time to change it. If your project is longer than three months, put one on the calendar for every phase. For short projects, one at the end is enough, and a quick one at the halfway point is a bonus.

For a business that runs a continuous flow of work rather than projects, hold one every month or quarter. It is the same idea as the weekly rhythm described in Project Focus on one page: a short, regular conversation that keeps the system honest.

Where to keep the lessons

Lessons that nobody can find are lessons that did not happen. A few ideas that work for small teams:

• One shared document or sheet, with a row per lesson: project, date, category, the lesson, the action, the owner and a status. Short and searchable.
• A pointer in every kickoff agenda: "Before we start, we read the last three lessons for projects like this one." Fifteen minutes that save weeks.
• A tag for the type of project. If you run construction, software and events, tag each lesson so a team can filter.
• Links from the templates. When a lesson changes how you write a charter, update the charter template. The lesson lives where the work happens.
• A yearly review. Once a year, read all the lessons and ask: which ones keep showing up? A pattern is a process problem.

The benefits tracker and the weekly review in the free toolkit pair well with this practice. A free Excel lessons learned template is planned for the website, and the publishing calendar shows its date.

Common mistakes

• Running it only at the end, when everyone is tired and has already moved on.
• Letting the boss talk first. Hierarchy kills honesty. Let juniors speak first.
• Treating it as a complaint session. Balance every "what went wrong" with a "what should we keep."
• Too many actions. Twenty actions means none gets done. Pick the three that matter.
• No follow-up. Put a review of the previous session's actions at the start of the next one.
• Blaming people. The moment a name appears next to a failure, honesty stops.
• Keeping the lessons private. If only the project team sees them, the next team starts from zero.

Build your one-page summary

Use the builder below with your own project. The sample is a small website relaunch. Fill in the five answers and the tool writes a one-page summary you can copy into an email or a shared document. It also warns you when something that usually makes lessons useless is missing: no numbers in the comparison, no root cause, or actions without a date. Nothing you type leaves your browser.

Interactive tool

The lessons learned builder

Loading the tool…

What to do this week

Think of the last project your team finished, even a small one. Put thirty minutes on the calendar with the people who did the work. Bring three sheets of paper with the headings keep, change and try, and a pen for everybody. Write silently for ten minutes, read the notes aloud, pick the three actions that would matter most and give each one a name and a date. Then put a reminder to review them in a month. That is the entire method, and it will already be better than most. If you would like someone to facilitate a session for your team, or to build lessons into your next project plan, that is part of my work as a project manager, and you can tell me about it on the contact page.

What is the one lesson your team keeps learning and never seems to apply? Tell me in the comments.

More tools. The decision log, the weekly review and the benefits tracker are free in the toolkit.

Also read. How to end a project well, including the handover: closeout and lessons learned. And how to find out whether a project delivered the result it promised: benefits realization.

Frequently asked questions

What is a lessons learned session?

A structured conversation with the people who did the work, held at a milestone or at the end of a project, to decide what to keep, what to change and what to try next time. It ends with a short list of actions with owners and dates, not with a list of complaints.

What questions should a lessons learned session ask?

Five are enough: what did we set out to do and what happened, what went well and why, what did not go well and why, what surprised us, and what will we do differently next time, with a name and a date for each action.

When should a team hold a lessons learned meeting?

Within a week or two of a milestone or of the end of the project, while people still remember the details. For projects longer than three months, hold a short session at every phase, so the lessons help the current project and not only the next one.

How do you make sure lessons are actually used?

Turn each lesson into an action with an owner and a date, build it into something people already use (a checklist, a template, the kickoff agenda), store lessons where the next team can find them and review the previous actions at the start of every session.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

NameEmail (required, never shown)

What is the one lesson your team keeps learning and never seems to apply? Post comment

Your name and email create a small profile that shows you are a real person. The email is never shown. The first time, I send you a confirmation link, and every comment is reviewed before it appears. Please keep it respectful and leave links out.