SiliciumHex FieldKit

Problem Solving & Quality · Sustain

Lessons Learned Register

Turn each closed problem into a short, searchable record — symptom, cause, fix, where it applies — and feed it into design rules, FMEAs and training.

  • Time1 h
  • FormatTeam
  • StageSustain

Lessons Learned Register: what it is and why it works

A lessons learned register turns each closed problem or completed project into a short, searchable record: the symptom, the verified cause, the countermeasure, where else it applies and keywords that help others find it. The record is written after a brief review that asks what happened, why, what worked and what the team would do differently, similar to a military after-action review. Each lesson is then routed to a permanent home, such as a standard, an FMEA, a design rule, a checklist or a training module, and the register is reviewed as a formal step at the start of new projects.

Organizations often pay twice, or many times, for the same lesson because knowledge stays with the people who experienced it and leaves when they move on. A register alone does not fix this: databases full of unread entries are common. The practice works when lessons are stored where people already search, are short enough to read, and are embedded in the documents that actually govern work. Its value is measured by use, not by volume. It complements yokoten, which pushes a fix to current operations, by preserving the knowledge for future projects, and it feeds FMEAs with real failure history. An A3 report often provides a ready-made summary for the record.

What you need

  • A closed problem, incident or project phase
  • The people involved and a facilitator for a short review
  • Supporting records: the A3, 8D, incident report or project data
  • A fixed record format and a storage location people already use

What you get

  • A short, searchable record in a fixed format
  • Each lesson routed to a home: standard, FMEA, design rule or training
  • A list of lessons to review at the start of related projects
  • Use statistics that show whether the register is actually consulted

When to use it

When the organization keeps paying twice for the same lesson.

How to do it, step by step

  1. Hold a short review when the problem closes: what happened, why, what worked, what we would do differently.
  2. Write one record in a fixed format: symptom, verified cause, countermeasure, where else it applies, keywords.
  3. Store it in a place people already search — the maintenance system, the project database, the design checklist.
  4. Route each lesson to a “home”: a standard, an FMEA, a design rule, a training module — a lesson without a home is lost.
  5. At the start of each new project or campaign, review the relevant lessons as a formal step.

Worked example: Thermal expansion of HDPE lines in water treatment projects

Illustrative scenario — figures are realistic but not from a real company.

An engineering and construction contractor builds water and wastewater treatment plants. On one project, above-ground HDPE chemical lines pulled out of their fittings during the first summer because thermal expansion had not been accommodated; repairs cost around $120,000 and delayed handover. At a lessons review, a senior piping designer recalled a similar issue on a project six years earlier.

  1. A one-hour review with the piping lead, the site supervisor and the commissioning engineer established the facts: long straight runs of HDPE exposed to sun, fixed at both ends, with no expansion loops or guided supports.
  2. The record was written in the standard format: symptom, cause, countermeasure, where it applies (above-ground thermoplastic lines exposed to temperature swings) and keywords such as HDPE, expansion, supports and pull-out.
  3. The lesson was routed to three homes: the piping design checklist got an expansion calculation step for thermoplastic lines, the pipe support standard got guided and anchor support details, and the design review agenda gained a specific question.
  4. Project kickoff procedures were updated so that the lead engineer reviews lessons tagged with the relevant materials and plant types.

Result. On the next two water treatment projects, expansion loops and guided supports were included in the design, and no pull-outs occurred. The register was checked at kickoff on both. The contractor's engineering manager noted that the lesson from six years earlier had existed only in one person's memory.

Open it in the FieldKit Problem Solving app → Get the Problem Solving template pack — join the waitlist

Common pitfalls and how to avoid them

  • Writing long narrative reports that nobody reads.Use a short, fixed format with symptom, cause, countermeasure, where it applies and keywords.
  • Storing lessons in a separate database that nobody visits.Store them where people already search, such as the maintenance system, design checklists or project templates.
  • Recording lessons without routing them to a standard, FMEA or training module.Give each lesson a home in a governing document, and track that the update was made.
  • Collecting lessons only at the end of long projects, when details are forgotten.Hold short reviews at the close of each problem and at key project milestones.

Frequently asked questions

What should a lessons learned record include?

At minimum: a short description of what happened (the symptom), the verified cause, the countermeasure that worked, where else the lesson applies and keywords for searching. Useful additions are the date, the project or area, the owner and links to supporting documents such as an A3 or 8D. Keeping the format fixed and brief makes records easy to write and read.

Why do lessons learned programs fail?

Usually because lessons are recorded but not used. Records are too long, stored in places nobody checks, written in local terms others cannot relate to, or never turned into changes in standards and designs. A lessons learned process succeeds when each lesson is embedded in a governing document and when reviewing lessons is a required step at project start.

What is an after-action review?

An after-action review is a short, structured discussion held after an event or activity, originating in military practice. It asks what was supposed to happen, what actually happened, why there was a difference and what to sustain or change next time. It is a practical format for the review meeting that feeds a lessons learned register.

Origin

Lessons-learned practice — project management (PMI PMBOK Guide) and military after-action reviews; no single author.

Used in these playbooks

Major breakdown investigation 1 week

One week after a trip, a leak or a critical equipment failure: rebuild the sequence, map the failure combinations, dig to the cause, choose strong barriers and record the lesson.

  1. Event Timeline Reconstruction
  2. Fault Tree Analysis
  3. 5 Whys
  4. Hierarchy of Controls
  5. Lessons Learned Register

Related methods

More in “Sustain”

Verify the result, lock it into standards and spread the lesson so it never comes back.