Lessons learned questions survey for the end of a project
Twelve questions for the people who delivered one finished project: what held, what slipped, the first sign anybody saw, and one written lesson the next team can use. Take it, then open it in the editor.
- 12questions
- 6 minto complete
- 1 projectonce, at close
One finished project, asked once, while the team still exists
Name the project, its start and end dates, and what it was supposed to produce. That sentence goes in the survey title, where nobody can miss it and nobody has to guess which project you mean.
A lessons learned review has one subject and one moment: this project, now that it has stopped. Two things follow. The people who can answer are about to be reassigned, so the window is short. And the audience is not them: it is whoever runs the next project like this one, who was not in the room and will read the record cold.
That is what separates it from the retrospective the team may already hold, and the difference is cadence and audience rather than depth. A retrospective recurs inside a running piece of work, and its audience is the same team in the next iteration, so it can be informal, verbal and forgotten by design. If the work is still going and the question is how the next fortnight should run, sprint retrospective questions are the ones to ask instead. Neither survey is a lighter version of the other. One is a habit; this one is a record.
Post-mortem, project debrief and post-project review are three more names for what is on this page, and the template fits all of them. Two neighbours are genuinely different jobs, and both are a choice rather than a step down. If what ended was an unplanned incident rather than a planned project, the response sequence is the subject and a crisis management questionnaire asks about that. If the thing you are examining did not stop at all but keeps running week after week, process improvement questions follow the workflow instead of closing it. And if what ended was a programme run for participants rather than a project run by a team, a program evaluation survey template asks the people it served, not the people who delivered it.
Where this review is an obligation rather than a habit, it is run as an after-action review whose corrective actions are then monitored to completion.[6] You do not need that machinery to close a project. You do need its one useful idea: a lesson is not a lesson until somebody owns it and a date is attached.
The 12 lessons learned survey questions
Every question below is in the survey at the top of this page, in this order. Copy one group, copy all twelve, or open the template and reword them.
Who is answering, and which end of it they saw
Two classification items, both required, both first. Every rating below is read by cutting on these two, because a sponsor and a tester describe the same project from opposite ends.
- Which of these is closest to your part in this project?The cut that makes the rest readable. Rename these five to the role names your own organisation uses before you send it.
- Which phases of this project were you involved in? Tick every one.Somebody who joined at testing cannot rate the estimate, and this is how you know to leave them out of that line rather than reading their skip as neutral.
What held and what slipped
Five ratings, each about something that either happened or did not. All five are a 1 to 5 line with only the two ends labelled, which is the shape the editor builds.
- This project delivered what it set out to deliver.The headline rating, deliberately placed under the two classification items so that those get answered first. Read it per role, never as one number.
- The schedule we agreed at the start held.About the schedule that was agreed, not about whether the estimate was good: the first is a fact everyone in the room shares.
- When something changed, the people it affected heard in time to act on it.The item that separates delivery from sponsor. It is about the reporting path, which you can change, rather than about how anybody felt.
- Decisions on this project were taken by people who had the information they needed.Not whether the decisions were right. Whether the person taking them had what they needed, which the next project can fix in advance.
- The handover at the end left whoever now owns this able to run it.Handover gets left out of reviews because the reviewers have moved on. Ask the people who now own the thing.
When you first saw it
Two items about the first sign of trouble, written so that neither asks anybody to judge whether the ending was foreseeable. Outcome knowledge is exactly what a review has and the project did not.[2]
- At what point did you first think this project would miss something it had promised?A ladder of moments, not of severity. Put the answers beside question 1 and you can see whether the people who saw it first were the people who could act.
- Describe the earliest sign you saw that this project was going off track: what you saw, roughly when, and who you told.What you saw, roughly when, and who you told. It stands on its own, so somebody who skipped question 8 can still answer it, and the "who you told" half is where the reporting path shows up.
The lesson itself
One forced choice and two open boxes, last because nothing substantive should sit behind a general comments box. They are the part the next project actually reads.
- Which one of these cost this project the most?One cause, not a ranking, so it gives a count you can put in front of whoever owns it. The last option lets somebody say nothing stood out rather than inventing something.
- Write one lesson for whoever runs the next project like this one. Say what happened, what you would do differently, and at which point.The deliverable. Three parts on purpose, so the lesson lands somewhere in the next project rather than in a document nobody opens.
- What worked well enough here that the next project should copy it?A review that collects only failures teaches the next team nothing about what to keep. This is what stops the record being a list of complaints.
Only the first two questions are required. The five ratings are a 1 to 5 line with the two ends labelled, which is the shape the editor builds. Nothing here is scored, and a low answer locates a phase rather than judging a person.
Three of those twelve are rewrites of the question that gets asked instead, and the rewrite is the whole point. A review knows how the project ended; the project did not. Fischhoff's experiments asked two questions about exactly that gap, in his own words, "how does receipt of outcome knowledge affect judgment?" and "how aware are people of the effects that outcome knowledge has on their perceptions?"[2] So questions 8 and 9 ask what somebody saw and roughly when, which is a memory, instead of asking whether the ending was foreseeable, which is a judgement made with the answer already in hand. The general version of the rule is published guidance on writing survey questions.[4]
| Instead of asking | Ask this |
|---|---|
| What went wrong on this project? | Describe the earliest sign you saw that this project was going off track: what you saw, roughly when, and who you told. |
| Could we have seen this coming? | At what point did you first think this project would miss something it had promised? |
| Any lessons learned? | Write one lesson for whoever runs the next project like this one. Say what happened, what you would do differently, and at which point. |
The last of those three is the one to protect if you cut anything. Ratings tell you where to look; question 11 is the only item that produces something the next team can act on, and it asks for three parts on purpose: what happened, what you would do differently, and at which point in the next project it would have to happen.
Turning the answers into a record
Twelve answers are a conversation. Forty are a record, and the record is built by cutting on the first two questions.
Cut by role, then by phase. Questions 1 and 2 exist so that the five ratings can be read per group rather than averaged into one number. Check question 5 for a split first: it is about the reporting path, and delivery and sponsor sit at opposite ends of that path, so a gap there names something you can change before the next project starts.
Put question 8 beside question 1. Question 8 says when people first thought something would be missed. Question 1 says who they were. If the people who saw it first were not the people who could act, you have found a mechanism rather than a mood, and question 9 says who they told and what happened to it.
Count question 10, do not average it. One forced choice gives a count per cause. A cause two people picked can still be the expensive one, so read those counts beside the open boxes rather than treating the largest as the answer.
Then write the lessons up so a stranger can use them. Each needs the event that drove it and a recommendation attached, which is the shape NASA's lessons learned system uses for its entries.[7] Give every lesson an owner and a date, and put the file where the next project team will look. A review whose output nobody can find is a meeting, not a record. To rate the review session itself, which is a separate ask, use post meeting survey questions. Lessons about what to take on next rather than how to run it belong in the planning round, where a strategic planning questionnaire is the instrument.
Getting it out before the team disperses
Five decisions that belong to a review at project close rather than to surveys in general.
Send it in the window before people are reassigned
The project has closed and the team has not yet dispersed. Once it has, the invitation list stops being everybody who was there and becomes whoever is still reachable, and no amount of question design fixes that.
Put the project and its dates in the title
Not "Lessons Learned Survey". "Warehouse system rollout, January to August, lessons learned". Somebody who worked on three deliveries this year has to know which of them you are asking about before question 1, and the heading is where they will look for it.
Be honest about how small the team is
A dozen people and three open boxes is not an anonymous survey: a distinctive sentence identifies whoever wrote it, name field or no name field. Put one line at the top: who opens the responses, and whether a name stays attached to an answer once the findings are being talked about. Then keep to it. Published survey-research standards put that disclosure on whoever runs the survey, rather than leaving a respondent to work it out.[5]
Print the same length in all three places
6 minutes here, 6 in the invitation, 6 in the reminder. One experiment that varied the stated length found fewer people beginning and fewer finishing as the figure rose,[1] so the number you print is doing work whether you meant it to or not.
Say where the lessons will end up, then send it
One sentence naming the document, the wiki page or the checklist the answers will turn into, and when. Then create a free questionnaire from this template, put your own project name and role labels in, and send it to everyone who was on it, including the people who only joined for testing.
Lessons learned survey FAQ
What questions should be asked in a lessons learned meeting?
Ones whose answers a team that was not in the room can use. "What went wrong?" comes back as a list of complaints; "what happened, what would you do differently, and at which point" comes back as an instruction. The twelve above are built on that rule, and the last three do most of the work.
What is the difference between lessons learned and a retrospective?
Cadence and audience, not depth. A retrospective is a recurring ritual inside a running piece of work, and its audience is the same team in the next iteration, so it can be informal and it can be forgotten. A lessons learned review runs once, when a project closes, and its audience is a different team on a later project, so the output has to survive being read by a stranger. Neither is a smaller version of the other.
What is the difference between a lessons learned meeting and a post-mortem?
For a project that has finished, nothing much: post-mortem, project debrief and post-project review are three names for the same review, and this template fits all of them. An after-action review of an unplanned incident is a different job, because there the response sequence is the subject rather than the plan.
When should a lessons learned session be held?
In the window between the project closing and the team being reassigned. That window is short, and the invitation list is the only part of this you control: once people have moved on you are surveying whoever is still reachable.
How do you write a lesson the next team can use?
Give it the driving event and a recommendation, which is the shape NASA uses in its own lessons learned system: each entry carries "a summary of the original driving event and recommendations".[7] A line that names only a feeling cannot be acted on, and a line that names only an event cannot either.
Should the survey be anonymous?
Be careful what you promise. A project team is small, and an open box on a team of a dozen can carry a phrase that identifies who wrote it whether or not a name field exists. Say in one line who reads the raw answers and whether names are attached when results are discussed, then keep to it. That is worth more to whoever answers than the word anonymous.
Methods and sources
What this template is based on
All twelve questions were written for this template. Shipping twelve rather than thirty, and putting the three open boxes last, follows a web-survey experiment in which the longer the stated length, the fewer respondents started and completed the questionnaire, and answers placed later were faster, shorter and more uniform.[1] Questions 8 and 9 ask what a person saw and when, rather than whether the outcome was foreseeable, because a review holds outcome knowledge that the project did not.[2] The rewrite pairs follow published guidance on writing survey questions,[4] and the invitation advice follows published best practice for survey research.[5] The rule that a lesson is unfinished until it carries a recommendation and an owner comes from formal after-action practice[6] and from the way NASA records its own lessons.[7]
Question licensing
Nothing on this page reproduces a licensed instrument. The PMBOK Guide is Project Management Institute copyright and republication requires written permission; the PRINCE2 Lessons Log is AXELOS and PeopleCert copyright, and the template site that reprints its field set does so under an explicit permission that SuperSurvey does not hold. Neither is reproduced, paraphrased into a near-copy, or used as a section structure here. The FEMA improvement-planning material and the NASA lessons learned system are United States federal publications and are cited as method lineage only.
Limits and disclosure
The questionnaire-length experiment used a general web sample, not colleagues reviewing a project they had just delivered, so it is a reason for the design and not a forecast. The outcome-knowledge finding behind questions 8 and 9 has a mixed replication record: the FLoRA Replication Atlas lists three replication attempts of the original experiment, two failed and one supporting.[3] It is a reason for the shape of an item, not a claim about your team. There is no published norm for these twelve items, so the only honest comparisons are one role against another inside your own project, and this project against your last one.
SuperSurvey makes the editor this template opens in; everything on this page works with or without it.
References
- Galesic M, Bosnjak M. Effects of questionnaire length on participation and indicators of response quality in a web survey. Public Opinion Quarterly, 73(2), 349-360, 2009. DOI 10.1093/poq/nfp031. academic.oup.com
- Fischhoff B. Hindsight is not equal to foresight: the effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance, 1(3), 288-299, 1975. DOI 10.1037/0096-1523.1.3.288. Record: eric.ed.gov
- FORRT. FLoRA Replication Atlas entry for Fischhoff (1975). forrt.org
- Pew Research Center. Writing survey questions. pewresearch.org
- American Association for Public Opinion Research. Best practices for survey research. aapor.org
- Federal Emergency Management Agency. Improvement planning, HSEEP resources, Preparedness Toolkit. preptoolkit.fema.gov
- NASA. NASA Lessons Learned (Lessons Learned Information System). nasa.gov
Close the project with a record, not a meeting
Twelve questions, about 6 minutes, and the last three produce something the next project team can actually use. Open it in the editor, put your own project name in, and send it before everybody is reassigned.
Use this template