Lessons Learned Register

What this tool does

CM8-259 is a lessons learned register built around re-use rather than collection. Each lesson records what happened, why, and — the field that does the work — a recommendation someone who was not there can follow. Alongside it goes the document that recommendation was written into, who owned the change, and when somebody will check it stuck.

The tool then measures the one thing worth measuring: what share of your lessons actually changed something. It runs inside this single file, with no account and no network request — which matters, because an honest register names projects that went badly.

Why most lessons learned registers are write-only memorials

Here is the blunt version. On most projects the lessons session happens at closeout, when the delivery team has dispersed to the next job and half the people who lived the problem have left the room. Someone types the discussion into a spreadsheet; the spreadsheet is attached to the closeout report; the report is filed; nobody opens either again. The next project starts, hits the same utility connection problem or the same late data migration, and holds its own closeout session about it. The register grows and nothing changes. It is a memorial rather than a knowledge base. If your register runs to twenty entries and you cannot name one document that changed because of it, that is what you have.

The only metric that matters is the embedded rate

A lesson that has not changed a checklist, a template, a standard or an induction pack has not been learned. It has been noticed. The difference is enormous, and it is invisible in a register that records only what was discussed.

The reason is simple: nobody reads registers, and everybody reads the document in front of them when they do the work. A project manager starting an installation opens the start-up checklist and works down it; they do not search an archive for lessons from three years ago. If the utility connection lesson is a line on that checklist, it is followed. If it is entry 47 in a register, it is not. The register is the audit trail of your learning; the checklist is the learning.

So the tool puts one number above the rest: the share of live lessons that reached a named document. Every lesson still at captured or agreed past your target is named in the "Not yet embedded" table, because that table is the actual work. A register with a high count and a low embedded rate is worse than none — it lets an organisation believe it learns.

Capture during the project, not just at the end

Every lesson carries a phase, and that field exists to push capture earlier. The best moment to write a lesson down is the week it happens, while the detail is still exact — the twelve-week lead time, the eleven thousand orphaned records, the forty minutes a day of waiting. By closeout those have softened into "it took ages" and "the data was a mess", and a recommendation built on that is useless.

Some lessons can also still help the project that produced them. One captured in planning about how bidders read drawings can change the next package on the same job; one captured at closeout can only help somebody else. So make lessons a three-minute standing item on the monthly project review. The lessons-per-month chart then shows whether it is happening — a single spike at the end is the write-only pattern drawn as a picture.

Writing a recommendation a stranger can follow

This is the craft skill of the whole discipline, and most registers fail at it. Compare:

• Useless: "Communicate better with suppliers." Nobody disagrees, nobody can act on it, and it will be written again after the next project.
• Useless: "Start data migration earlier." Earlier than what? By how much?
• Usable: "Issue the utility connection request at contract award. Allow twelve weeks and name the connection in the scope matrix with one owner against it."
• Usable: "Run a full trial data migration at the end of design and repeat it twice before go-live. The first trial exists to find out how bad the data is, not to prove the migration works."

The test: could somebody who has never met you, on a different project in two years, follow it without asking a question? That usually means it holds a trigger (at contract award, at design sign-off), an action in the imperative, and a number — a duration, a count, a threshold. No number and no trigger means you have written a sentiment. The tool will not save a high-impact lesson without a recommendation: high impact with nothing actionable attached is the most expensive kind of nothing.

Capture what worked, not only failures

A register containing only failures becomes a blame log. People work out quickly that contributing means naming a colleague's mistake in a document their director will read, and contributions stop — first the awkward ones, then all of them. What survives is only the failures too obvious to hide.

Recording what worked fixes that, and is more useful anyway. Good practice is as fragile as bad: the single point of contact that made an installation run smoothly disappears the moment that person moves on, unless somebody wrote down that it was deliberate. The tool tracks the split on a tile and flags a register that has become all failures. The third type — surprise — covers what nobody predicted: the unannounced audit, the clause nobody had read. Those often point at a gap in how you plan rather than how you execute.

The embedding step, in practice

Embedding is three decisions, and the register asks for all three:

1. Which document? Specific enough that somebody could open it. "Tender template — section 2, pre-tender site visit" is a location; "procurement process" is a gesture. Aim at the shortest, most-read artefact touching the moment of the mistake: a start-up checklist, a runbook, an induction pack.
2. Who owns the change? One name — whoever can edit that document and make the edit stick, often not the person who captured the lesson. A lesson owned by a department is owned by nobody.
3. When is it verified? A review date, far enough out that the changed document has been used once in anger.

The tool refuses a lesson marked embedded without a named location: "embedded" with no document is the commonest self-deception in this discipline.

Not every lesson deserves embedding. Some are local, some are wrong on examination, some cost more to prevent than to suffer. Mark those rejected and put the reason in the root cause field — the tool insists. A rejected lesson with a reason is a decision the next team can rely on; one without gets re-litigated every two years.

Reviewing whether it stuck

Embedding is not the end. Documents get rewritten, templates replaced, checklists worked around. The review date exists so somebody goes and looks: is the line still in the document, and did the last project that used it actually do the thing? If it is there and being followed, move the review date out — you have a standard. If it was quietly removed or is being ignored, the lesson has come undone, and why is the interesting question. Usually the recommendation was more burdensome than the problem it prevented, which is itself worth capturing.

When a lesson is replaced by something broader, mark the original superseded rather than deleting it. Superseded and rejected lessons are both excluded from the embedded rate, so retiring an entry honestly does not distort the number.

Running a 45-minute lessons session

The failure mode of a lessons workshop is the complaints meeting: everyone describes what annoyed them, someone types it up, nothing is decided. A tight structure prevents it.

1. Five minutes — the rule. Say it out loud: we are here to leave with instructions for the next team. Every item ends in a recommendation or it is not an item.
2. Ten minutes — what worked. Deliberately first; it stops the session becoming a post-mortem. Ask what you would insist on doing again.
3. Fifteen minutes — what went wrong. Facts and sequence only. When somebody names a person, ask what the process allowed: the missing owner, the missing gate, the untested assumption.
4. Ten minutes — the surprises. What did nobody see coming?
5. Five minutes — assign. For each surviving item: which document, whose name, what date. If nobody will own the change, the item is captured rather than agreed, and it sits on the not-embedded list until somebody deals with it. That is honest, and better than a false consensus.

Anything that cannot become a recommendation in the room goes on as captured, with a named person to draft one within a fortnight. A second short session two weeks later, reviewing drafted recommendations, produces more than ninety unbroken minutes ever will.

How the figures are worked out

Rejected and superseded lessons are excluded from the denominator because neither should be embedded; counting them would punish you for retiring entries honestly. The rate is calculated across whatever the current filter shows, so filtering to one project gives that project's rate, and the printed report states the filter in force.

FAQ

How many lessons should a project produce? Fewer than you think. Five to fifteen from a substantial project, each with a real recommendation, beats sixty bullet points. A session producing forty items has produced observations, not lessons.

What if the same lesson appears on three projects? That is the most important signal in the register: the first two were captured and never embedded. Keep one entry, note the repeat, raise the impact and get it into a document.

Should lessons name individuals? No — name roles and processes. A register that names people is sanitised within a year, and a sanitised register is a memorial.

What is a good embedded rate? There is no universal figure, and anyone quoting one is guessing. Measure your own and watch the direction. Below half, the register is being written, not used.

Can I use it beyond projects? Yes — the project field is free text, so it suits incidents, lost tenders, audits or any recurring activity where mistakes repeat.

Saving your work

Lessons, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything stored, with no undo. A candid register describes projects that went badly, so treat exports accordingly.

Accuracy & disclaimer

The arithmetic here is counting and division, and the tool does it faithfully. Everything that matters sits underneath it: the tool cannot tell whether a recommendation is any good, whether the root cause is the real one, or whether the document named in the "embedded into" field was ever actually changed. A lesson marked embedded is a claim somebody made — the embedded rate is a prompt to go and check, not evidence.

Capturing a lesson is bookkeeping. Changing the document the next team reads is the learning. This is a record-keeping and prioritisation aid, not project-management, legal or contractual advice.