Projects

Lessons Learned Template

Most lessons learned documents are written once and never read again. This template compares plan to actual, writes each lesson as an instruction for next time with its evidence, and ends by naming the checklist, template or estimate each lesson should change.

Updated 2026-10-27

Copy and adapt

The template

Lessons learnedTemplate

[Project name] lessons learned, {{date}}

Project: [[Project name]] Dates: [start] to [end] Owner of this document: [name] Input from: [names, and how: review session, survey, interviews]

Plan versus actual

End date: planned [date], actual [date]
Budget: planned [amount], actual [amount]
Scope: [delivered as planned / cut / added]
Outcome measure: target [number], actual [number]

What worked (repeat it)

[Practice] because [evidence it helped]

What did not work

[What happened]. Root cause: [why, not who]. Impact: [days, money, quality]

Lessons

[Lesson written as an instruction for next time] Evidence: [what happened on this project] Applies to: [kind of project or phase]
[Lesson] Evidence: Applies to:

Where each lesson goes

[Change to a checklist, template, contract, estimate or plan] (@[owner]) @due(YYYY-MM-DD)

Read this before

[The kind of project or decision where someone should reread this note]

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Software migration that finished late and over budget

When it fits: Use this when an internal IT project slipped badly, people are defensive about why, and the lessons need to be about the plan and the process rather than about who was slow.

Software migration that finished late and over budgetExample 1

Billing system migration lessons learned, 2026-11-12

Project: [[Billing migration]] Dates: 2026-04-06 to 2026-10-30 Owner of this document: Farah (PMO) Input from: review session on Nov 10 (9 people), survey (14 of 17 replied), interview with the finance controller

Plan versus actual

End date: planned Sep 18, actual Oct 30 (6 weeks late)
Budget: planned $210,000, actual $258,000 (23 percent over)
Scope: delivered as planned, except the custom dunning emails, moved to Q1
Outcome measure: invoice errors after cutover, target under 0.5 percent, actual 0.3 percent

What worked (repeat it)

Parallel run for two billing cycles. It caught 41 rounding differences before customers did.
Finance had a named person on the project two days a week.

What did not work

Data mapping took 7 weeks instead of 3. Root cause: the old system had 212 custom fields and nobody inventoried them before estimating. Impact: 4 weeks of the delay, about $30,000.
Vendor change requests took 9 days each to approve. Root cause: the contract had no turnaround time. Impact: 2 weeks.

Lessons

Inventory the source data before estimating a migration. Evidence: 212 unlisted fields doubled the mapping phase. Applies to: any system migration.
Put a change request turnaround time in vendor contracts. Evidence: 9 days per change request, 6 requests. Applies to: vendor-led implementations.
Keep the parallel run, even under schedule pressure. Evidence: 41 errors caught. Applies to: anything that touches invoices or payroll.

Where each lesson goes

Add a data inventory step to the migration estimate template (@Farah) @due(2026-11-30)
Add a 3-business-day change request clause to the vendor contract template (@Gustavo, procurement) @due(2026-12-15)

Read this before

Estimating any migration, and signing any implementation contract.

2.Annual customer conference

When it fits: Use this for an event, where the project ends on one day, the team disbands the next week, and next year's organizer may be someone who was not there.

Annual customer conferenceExample 2

Customer Summit 2026 lessons learned, 2026-10-21

Project: [[Customer Summit 2026]] Dates: planning from 2026-03-02, event 2026-10-08 Owner of this document: Leila (events) Input from: debrief with the 6-person events team, attendee survey (212 of 380 replied), venue walkthrough notes

Plan versus actual

Attendance: target 350, actual 380
Budget: planned $145,000, actual $151,500
Attendee satisfaction: target 4.3 of 5, actual 4.1

What worked (repeat it)

Customer-led sessions scored 4.6, the highest of the day. Attendees want peers, not slides from us.
Badge pickup by QR code: no queue longer than 5 minutes.

What did not work

Keynote audio failed for 12 minutes. Root cause: the venue AV team had no rehearsal with our laptop and adapter. Impact: the lowest-rated part of the day, 3.2.
Lunch ran out for the last 40 people. Root cause: catering numbers were fixed at 340 two weeks before, and late registrations were not passed on. Impact: dozens of survey complaints, $1,800 emergency order.

Lessons

Book a full technical rehearsal with the venue AV team on the day before. Evidence: 12-minute keynote failure. Applies to: any event with a stage.
Give catering a final number 72 hours before, and keep registration open only until then. Evidence: 40 people without lunch. Applies to: any catered event.
Make half the agenda customer-led. Evidence: 4.6 versus 3.9 for our own sessions.

Where each lesson goes

Add AV rehearsal and 72-hour catering cutoff to the event checklist (@Leila) @due(2026-11-01)
Start recruiting customer speakers in March, not June (@Ravi) @due(2027-03-01)

Read this before

Booking the 2027 venue, and building the 2027 agenda.

3.Successful pilot that is about to scale

When it fits: Use this when the project went well, everyone wants to expand it, and the risk is copying the things that happened to work at small scale without knowing which ones mattered.

Successful pilot that is about to scaleExample 3

After-school tutoring pilot lessons learned, 2026-12-02

Project: [[Tutoring pilot, Eastside Middle]] Dates: 2026-09-08 to 2026-11-25 Owner of this document: Marisol (program lead) Input from: tutor focus group (11 tutors), interviews with the principal and 6 parents, attendance and quiz data

Plan versus actual

Students enrolled: target 60, actual 58
Average attendance: target 70 percent, actual 84 percent
Math quiz scores: target +10 percent, actual +14 percent
Budget: planned $38,000, actual $35,200

What worked (repeat it)

Same tutor with the same 4 students all term. Students with a tutor change attended 22 points less often.
Snacks at 3:15. Tutors say it is the reason students stayed instead of going home.
The vice principal personally texted parents after two missed sessions.

What did not work

Tutor recruitment took 5 weeks. Root cause: we recruited only through one university. Impact: started 2 weeks late.

Lessons

Keep tutor and student groups fixed for the full term. Evidence: 22-point attendance gap. Applies to: every school in the expansion.
Find the person in each school who will call parents, before launch. Evidence: the vice principal's texts. Applies to: every new school; without this role, do not launch there yet.
Recruit tutors from at least three sources. Evidence: 5-week delay.

Where each lesson goes

Add "named parent contact in the school" as a launch requirement in the expansion plan (@Marisol) @due(2026-12-15)
Contact two more universities and a retirees' volunteer network (@Dele) @due(2027-01-10)

Read this before

Choosing the four schools for the spring expansion.

4.Clinic renovation delayed by permits

When it fits: Use this for a physical project with contractors and inspections, where most delays came from outside the team and the useful lessons are about sequencing and lead times.

Clinic renovation delayed by permitsExample 4

Westside clinic renovation lessons learned, 2026-11-19

Project: [[Westside clinic renovation]] Dates: 2026-05-11 to 2026-10-23 Owner of this document: Graham (facilities) Input from: walkthrough with the general contractor, clinic manager interview, budget reconciliation

Plan versus actual

Reopening: planned Sep 1, actual Oct 26 (8 weeks late)
Budget: planned $420,000, actual $447,000
Scope: two exam rooms added during construction at the clinic's request

What worked (repeat it)

Weekly site meeting with photos in a shared note. The clinic manager knew what was happening without visiting.
Temporary space in the pharmacy building kept 80 percent of appointments running.

What did not work

Mechanical permit took 7 weeks. Root cause: we applied after the design was final instead of in parallel with design. Impact: 5 weeks.
Two exam rooms added in July. Root cause: the clinical team saw the floor plan for the first time in June. Impact: $19,000 and 3 weeks.

Lessons

File for permits during design, not after. Evidence: 5 weeks lost. Applies to: any renovation that touches mechanical or electrical.
Have the people who will use the space sign off the floor plan before construction starts. Evidence: $19,000 change. Applies to: every clinical space.

Where each lesson goes

Move permit application into the design phase of the renovation plan template (@Graham) @due(2026-12-05)
Add clinical staff sign-off as a gate before contractor mobilization (@Graham) @due(2026-12-05)

Read this before

Scoping the Northside clinic renovation planned for 2027.

5.Mid-project lessons at the end of a phase

When it fits: Use this when the project is not over, a phase just closed, and the lessons can still change the rest of this project rather than waiting a year to help the next one.

Mid-project lessons at the end of a phaseExample 5

Brand refresh, discovery phase lessons learned, 2026-11-05

Project: [[Brand refresh 2027]] Dates: discovery 2026-09-14 to 2026-10-30; project runs to 2027-03 Owner of this document: Tess (marketing) Input from: 45-minute session with the agency and the 4 internal stakeholders

Plan versus actual

Discovery end: planned Oct 16, actual Oct 30
Customer interviews: planned 20, actual 12
Budget for the phase: on plan

What worked (repeat it)

Sales sat in on customer interviews. They now argue for the research instead of against it.

What did not work

Interviews short by 8. Root cause: we recruited through account managers, who were busy with renewals in October. Impact: thinner evidence on the enterprise segment.
Two weeks lost waiting for the CEO's input. Root cause: no review date was booked in advance.

Lessons

Book the CEO review dates for every remaining phase now. Evidence: 2 weeks of waiting. Applies to: this project, from the design phase on.
Recruit interviewees through a research panel, not account managers, in renewal season. Evidence: 12 of 20.

Where each lesson goes

Book CEO reviews for Dec 3, Jan 21 and Feb 25 (@Tess) @due(2026-11-07)
Add 6 enterprise interviews via a panel to the design phase (@Joon, agency) @due(2026-11-20)

Read this before

The design phase kickoff on Nov 10, and the end of every phase until March.

What makes a lessons learned template useful

A lessons learned template is easy to fill in and hard to make useful. The documents that get read again share three traits: they say what actually happened in numbers, they phrase lessons as instructions someone can follow, and they name the place each lesson will change. The template above is built around those three.

Plan versus actual. Dates, budget, scope and the one outcome measure that mattered. It gives every lesson a scale.
What worked. Practices to repeat, with the reason you believe they helped.
What did not work. Each item with a root cause and an impact. The impact decides which lessons are worth writing.
Lessons. Three to five instructions, each with evidence and the kind of project it applies to.
Where each lesson goes. The checklist, template, contract or estimate that changes, with an owner and a date.
Read this before. The decision or project type where someone should open this note.

How to run the lessons learned session

Send a short survey first. Three questions: what should we repeat, what should we never do again, what surprised you. It lets quieter people contribute and gives the session a starting list.
Ask someone other than the project manager to facilitate. People are more candid when the person who ran the project is not also running the review.
Start with plan versus actual. Five minutes of facts focuses the discussion on the biggest gaps.
Ask why until you reach a process. "The permit was late" becomes "we applied after design", which becomes a lesson.
Agree the lessons and owners in the room. A document written alone afterwards rarely gets anyone to change anything.

Making lessons reusable

This is the question every top-ranking lessons learned page leaves open. They say to store lessons in a central place and review them before the next project, but not how anyone will find the right lesson at the right time.

Two things work better than a repository. First, change the artifact, not just the document. A lesson about permits belongs in the renovation plan template as a step. A lesson about vendor turnaround belongs in the contract template as a clause. Once the checklist changes, nobody needs to remember the lesson. The Where each lesson goes section exists so that every lesson ends up somewhere people already look.

Second, write when to reread it. The Read this before line names the trigger: estimating a migration, booking a venue, choosing schools. Tag the note and link it to the project, so a search for the trigger finds the lesson.

Common mistakes

Vague lessons. "Improve communication" changes nothing. Name the meeting, the document or the step.
Blame. A document that names people stops people from talking in the next session.
Only failures. Successful projects have the most to teach about what to keep.
Waiting until the very end. Phase-end sessions catch lessons while they can still help.
Filing and forgetting. If no checklist or template changed, nothing was learned.

When to use a different template

For a two-week sprint, the sprint retrospective template is shorter and focused on the team's next iteration. For one incident, the post-mortem template adds a timeline and a detailed root cause. And when the next project starts, put the relevant lessons straight into its project kickoff meeting under risks and assumptions, where they will actually be discussed.

Customization tips

Write lessons as instructions
"Communication could have been better" is an observation nobody can act on. "File for permits during design, not after" is a lesson someone can follow on the next project. If a lesson does not start with a verb, rewrite it.
Every lesson needs evidence
Attach what actually happened: the number of days, the dollar amount, the survey score. Evidence is what persuades the next project manager to follow a lesson instead of treating it as one person's opinion.
Root cause, not culprit
Write why something happened in terms of process or information ("catering numbers were fixed two weeks before"), never in terms of a person. People share more in the review session when they know the document will not name them.
Record what worked as carefully as what failed
Successful practices disappear just as easily as mistakes repeat. The pilot example above would have scaled the wrong things if nobody had written down why attendance was high.
Capture at each phase, not only at the end
By the end of a nine-month project, the first three months are a blur and some people have left. A 45-minute session at each phase end catches lessons while they can still help this project.
Keep it to five lessons or fewer
A document with 30 lessons is a list nobody reads. Pick the ones with the biggest impact and the clearest instruction. The rest can stay in the session notes.

In the app

How to do this in Scribelet

Open Desk Settings, then Templates, tap Add Template, paste the template above and set the category to Planning with #lessons-learned as a default tag. Every lessons document is then one tag away when you start the next project.
Link the document to the project with [[Billing migration]]. The project note's backlinks panel shows the lessons next to the plan, status reports and meeting notes, so the full story is in one place.
Write the changes in Where each lesson goes as tasks with @due(2026-11-30). They appear in the Tasks view until done, so the lessons turn into changed checklists instead of a closed file.
When a new project starts, ask the AI chat "what lessons have we recorded about vendor contracts?" It answers from your notes and cites the lessons documents it used.
On Pro, the stale checker flags notes that may need review, a useful nudge for the checklists and plan templates your lessons changed, since those go out of date too.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

How do you structure a lessons learned document?

Start with the project facts and plan versus actual, so readers know what happened. Then list what worked and what did not, each with a root cause and impact. Turn the most important findings into three to five lessons written as instructions, and end with who will change which checklist, template or plan. The template above follows that order.

What is the definition of lessons learned?

Lessons learned are the knowledge a team gains from doing a project, recorded so that future projects can repeat what worked and avoid what did not. A lesson is only learned when something changes because of it, which is why the template ends with where each lesson goes.

What are some examples of lessons learned in a project?

Good examples are specific and actionable: "inventory the source data before estimating a migration", "book a technical rehearsal with the venue the day before", "file for permits during design". Each of the five examples above contains two or three lessons like these, with the evidence that produced them.

What is the difference between lessons learned, a retrospective and a post-mortem?

A sprint retrospective looks at a short iteration and changes how the same team works next sprint. A post-mortem analyzes one incident in depth. A lessons learned review covers a whole project or phase and is written for future projects, often run by different people. Many teams use "project retrospective" and "lessons learned" for the same thing.

When should you hold a lessons learned session?

Within two weeks of the project or phase ending, while people remember and before the team disperses. For long projects, hold a short session at each phase end as well, as the fifth example shows. Send a short survey first so the session starts from what people already wrote down.

Lessons that show up when the next project starts

Keep your lessons learned documents in Scribelet, link them to the project, turn each lesson into a dated change, and ask your notes what you learned last time before you plan the next one. Encrypted, free to start.

Start your lessons learned log

or get the app

Download on theApp Store

Free plan, no credit card. See pricing

Meetings

Sprint Retrospective Template

A retrospective is only as good as what changes afterwards. This template opens by checking whether last retro's actions worked, grounds the discussion in sprint facts, and ends with at most two actions, each with an owner, a date and a sign that it worked.

Engineering

Post Mortem Template for Incidents

A post-mortem is worth writing only if it changes something. This template keeps the timeline factual, pushes the whys to a cause the team can fix, and ends with action items that have owners, dates and a 30-day check. Copy it, or start from the postmortem example closest to your incident.

Meetings

Project Kickoff Meeting Template

A kickoff meeting should leave behind one page everyone can point to later: why the project exists, what success looks like, what is in and out of scope, who decides what, and which assumptions could sink it. This template is the agenda before the meeting and that page after it.

Projects

Project Plan Template

A project plan says what will be true when the project is done, what is in and out of scope, which milestones get you there by when, who owns each one, and what could go wrong. This template adds the part most plans skip: a dated record of every change.

Projects

Project Status Report Template

A status report tells readers in thirty seconds whether the project is on track, what changed since last time, and what you need from them. This template defines green, amber and red up front, so the color means the same thing every week.

Article

Knowledge decay

From the Scribelet blog