task-ops
The document gets written. A project ends, someone books ninety minutes, the team says what went well and what did not, and a tidy file appears in a folder called Project close. It is thorough. It is honest, mostly. And when the next project starts six weeks later, nobody opens it, and the same three problems happen again in the same order.
This is the normal outcome, not an unusual failure. The reason is that most lessons learned templates are built as a record of a conversation rather than as an input to a decision. A record is complete, neutral and organised by theme. An input is short, opinionated, and organised by the moment at which someone will need it. The template below is built for the second job, along with the two things no template can fix on its own: how the session is run, and where the result is kept so that it surfaces without anyone remembering it exists.
Before any fields, one filter removes most of what usually ends up in these documents. A lesson is only a lesson if it would change a decision on a future project. Everything else is commentary.
Applied honestly, this cuts hard. Communication could have been better does not pass, because no future decision changes as a result. The client review step took eleven days on average while the plan assumed three, so the next plan should budget two weeks per review round does pass, because it changes a specific number in a specific document.
Three kinds of entry fail the test predictably. Praise fails, and that is fine, since appreciation belongs in the session but not in the document that gets carried forward. Complaints about individuals fail, and they also poison the record, because a document that names people as problems is a document nobody will speak freely in front of again. Restatements of general good practice fail. Nobody needed telling that requirements should be clear.
What passes tends to look unglamorous and specific. A supplier's lead time was three weeks longer than quoted. The test environment was unavailable for the first two sprints because the request had to pass through a queue nobody knew about. The design approval needed a second person whose existence surfaced in week five. These are the entries that change a plan, and the point of a template is to make them easy to write and hard to avoid.
One consequence is worth stating plainly. A good lessons learned document is short. Thirty entries means the filter was not applied. Six to ten real entries, each with an owner and a next action, beats forty paragraphs of discussion every time.
Most templates in circulation have a field for what happened, a field for the impact, and a recommendation. That structure records a conversation well and produces nothing. The fields below are the smallest set that produces something actionable.
| Field | What goes in it | Why it exists |
|---|---|---|
| What happened | One or two sentences, factual, no names | The evidence for the lesson |
| Phase | Where in the project it occurred | Decides when this gets read next time |
| Category | Estimating, scope, suppliers, tooling, approvals, people | Makes the record searchable once there are several projects |
| Effect | Days, cost, rework, or quality, stated concretely | Sorts the serious from the annoying |
| What to do differently | A specific change to a specific artefact or step | The actual lesson |
| Where it lands | The checklist, template or process that changes | Prevents the entry from being advice to nobody |
| Owner | One named person | Someone has to make the change happen |
| Status | Proposed, agreed, applied | Shows whether anything was ever done |
The last three columns are what separate a lessons log from a diary, and they are missing from most freely available templates.
Where it lands is the most important and the least common. A recommendation such as engage suppliers earlier lands nowhere and will be repeated verbatim at the end of the next project. A recommendation that says add a supplier lead time confirmation step to the kickoff checklist has a home, and a week later someone can check whether the checklist changed.
Status matters because it makes the follow through visible. A lessons register in which every row still reads proposed after three projects is telling the organisation something useful about itself, and that message is lost when status is not recorded at all.
Two fields commonly included can be dropped. A severity score adds a ranking argument without changing what gets done, since the effect column already carries that information in plainer form. A field for who raised it discourages candour and serves no purpose once the entry is written.
The template collects what the session produces, so a weak session produces a weak document regardless of the form.
Collect before the meeting. Ask each person for their entries a day or two in advance, in writing. This removes the effect where the first opinion spoken anchors the room, and it surfaces the points that a quieter person would never raise in front of a group. The meeting then starts from a list rather than from a blank page.
Separate what happened from what to do about it. Move through the facts first and agree them. Discussion of remedies during fact gathering turns the session into a debate and the more confident voices win. Once the facts are agreed, the recommendations become much easier because they are argued against a shared record.
Keep blame out by construction, not by asking. Telling a room to be blameless rarely works. Writing entries in terms of the step rather than the person does work, because the language itself makes blame awkward to express. The approval took eleven days is a fact about a process. A named person was slow is a fact about a person, and it will end the usefulness of the session.
Ask about the things that went right that were not luck. This is not a morale exercise. A project that came in on time because someone built a shared status page in week one contains a repeatable practice, and repeatable practices are exactly as valuable as avoided mistakes and far less often recorded.
Finish with owners and dates, not with agreement. The session is not done when everyone agrees. It is done when each entry that is going to change something has a name against it and a date by which the change is made. Fifteen minutes at the end for this is a better use of the time than a fuller discussion of the sixth minor point.
Ninety minutes is a reasonable length for a project of a few months with a team of five to ten. Anything longer is usually a sign that facts and remedies were not separated.
The strongest single improvement to the whole practice has nothing to do with the template. It is timing.
A lessons session at the end of a project collects everything at the moment it can no longer help the project it came from. Detail has decayed, and what happened in month two is remembered as a mood rather than a sequence. The team is dispersing. And the people best placed to act are already committed elsewhere.
Running a short session at each phase boundary changes all three. Thirty minutes at the end of a design phase, with the events still fresh, produces better entries than three hours at the end. More importantly, the entries from the design phase can still change the delivery phase of the same project, which is the only way this practice ever pays back inside a single project rather than in some future one.
This also solves the recording problem quietly. Teams that keep a running log during the project, adding entries as they occur, arrive at the close session with a list already assembled. Adding an entry at the moment of discovery takes a minute. Reconstructing the same entry five months later takes a meeting.
The end of project session still happens. It just becomes a review and consolidation of what was already captured, which is a far more productive ninety minutes than an attempt at total recall.
There is one objection to phase boundary sessions worth answering, because it is the reason most teams skip them. Stopping to reflect in the middle of a project feels like an interruption when the schedule is already tight. In practice the thirty minutes is recovered within the same phase, because the entries that come out of an early session are almost always about a step that is going to repeat: a review cycle that takes longer than planned, an environment request that has to be raised earlier, an approver nobody had accounted for. Those corrections apply immediately. A lesson recorded at project close cannot correct anything at all, which makes the session held during the project the cheaper of the two.
Every field discussed above is wasted if the finished document is not read at the right moment, and the right moment is not when the project closes, it is when the next project plans the same phase.
| Where it is kept | What it is good at | Why it fails |
|---|---|---|
| Document in a project folder | Easy to write, reads well | Filed under the finished project, invisible to the next one |
| Slide deck for the close meeting | Good for a presentation | Not searchable, entries lose their detail |
| Shared spreadsheet across projects | Searchable, entries accumulate | No owners, no status, nobody is reminded |
| Cards on a board with owners and dates | Entries become trackable work | Needs a deliberate place so they are not mixed with delivery tasks |
| A step in the kickoff checklist | Forces retrieval at the right moment | Only works if there is something to retrieve |
The last two rows work together and are what actually break the cycle. Keep one register that spans projects rather than one document per project, so that the same supplier problem appearing three times becomes visible as a pattern instead of three isolated notes. Tag entries by phase and category so retrieval is possible. Then put a line in the kickoff checklist requiring that the entries for the phase about to start are read out.
Entries with an owner and a due date behave like work and can be tracked like work, which is why a board suits them better than a document. Whether that board is separate from delivery boards matters, since lessons mixed into a delivery board disappear within a week. Tools differ on whether additional boards cost anything, which is worth checking on the pricing page before the structure is designed around a limit that turns out to be paid.
Stop writing a document per project and start a single register that spans them, with a phase, an owner, a place the change lands, and a status on every row. Then add one line to the kickoff checklist: read the entries for this phase before planning it. If that register needs owners, dates and a place people already open daily, Pinateca is free for up to five people and ten boards.
At minimum: what happened, which phase it happened in, the concrete effect, what to do differently, where that change lands, one named owner, and a status. The first four appear in most templates. The last three are what turn a record of a conversation into something that changes the next project.
A retrospective looks at the last two weeks and acts on the same team immediately, so it can be informal and leave little behind. A lessons learned record targets future projects and different people, which means it has to be written so that someone who was not present can act on it. Teams running retrospectives still benefit from promoting the durable items into a cross project register.
At the end of each phase rather than only at project close. Detail is still accurate, and entries from an early phase can still change the later phases of the same project. A closing session is still worth holding, but it works better as a consolidation of entries already captured than as an attempt to remember five months at once.
Write every entry as a fact about a step rather than about a person, collect contributions in writing before the meeting, and agree the facts before discussing remedies. Those three mechanics do far more than asking people to be constructive, because they make blame awkward to express in the format itself.
One named person, and ideally not the project manager for every row. The owner is responsible for making the specific change land in the checklist, template or process named in the entry. Without a name, entries stay at proposed forever, which is the state most cross project registers are in when anyone finally checks.