A reusable lesson needs the situation, evidence, practical principle, and conditions for applying it. Write the lesson so another team can assess its fit before adding it to a checklist. This template follows a fictional poster handoff into two different future-project situations.
Keep the event and its evidence intact
The original teaching example supplies three records:
| Record | Supplied fact |
|---|---|
| E1 | Approved V3 has the title “Room B.” |
| P1 | The print packet contains V2 with the title “Room A.” |
| E2 | A review note identifies the mismatch before printing. |
The review caught a mismatch. The records do not explain why V2 was selected. A lesson about the handoff can preserve that uncertainty while proposing a more explicit review reference.
NASA's lessons-learned lifecycle distinguishes collecting, recording, disseminating, and applying lessons. Its application stage includes changes to processes and checklists. The poster example here is original and uses that distinction between recording a lesson and actually changing practice.
Write the transferable principle separately from the recommendation
Compare the short event-only note with a complete record:
| Part | Worked entry |
|---|---|
| Context | A poster handoff contains more than one version of the source. |
| Event | P1 contains V2, while approved V3 has different title wording. E2 catches the mismatch before printing. |
| Candidate lesson L1 | When a handoff contains several versions, identify the exact source version beside the review item instead of relying on the folder name. |
| Recommendation | Add a source-version field to the next handoff checklist and rehearse a comparison with the supplied item. |
| Limit | The selection cause is not established, and this proposed change has not been shown to prevent a later mismatch. |
L1 states a condition and a principle another team can examine. The recommendation names one way to try it. Keeping them separate leaves room for a different team to apply the principle through its own tools.
Check the fit in the next project
Select Case A in the example. The next team uses multiple versioned source files. That resembles the condition behind L1, so the team has a reason to examine the proposed source-version field.
Ask which reference the reviewer can access and how it identifies the exact approved source. Then rehearse the comparison before treating the checklist edit as settled practice.
Select Case B. This team uses a fixed single source file. It still needs a review, but the supplied case has not shown the same multiple-version selection problem. Do not add L1 automatically just because its wording sounds sensible.
The applicability question is concrete: does this team's handoff contain the condition the lesson addresses? Record a decision to apply, adapt, investigate, or leave the lesson unused, with the reason.
Keep proposed reuse separate from actual adoption
The next-project area includes an owner, the proposed checklist change, an adoption record, and later evidence. The example leaves actual adoption and results blank.
A lesson can be recorded and shared before anyone changes a checklist. Even after a change is adopted, you need later observations to assess how it worked. Keep those stages visible so a published note does not become an invented success story.
For your own record, include the original context and evidence reference, the lesson, its limits, the intended audience, applicability questions, recommendation, reuse owner, actual adoption, and later results. That is enough for the next team to make an informed choice without reconstructing the original review meeting.
Prepare your own reusable lesson note
Create one complete, self-contained HTML lessons-learned record.
Original project and context: [DESCRIBE]
Event and source evidence with IDs: [PASTE]
Candidate transferable lesson and its conditions: [PASTE]
Proposed recommendation: [PASTE]
Known limits and unanswered cause questions: [PASTE]
Next-project context A and context B: [PASTE]
Reuse owner and actual adoption/results, if available: [PASTE OR LEAVE BLANK]
Separate event, lesson, recommendation, and actual application. Make
the condition for reuse explicit. Keep source facts unchanged and do
not invent a cause, adoption, measured benefit, or prevented recurrence.
Compare an event-only note with the complete lesson record. Let a
reader select each new-project context to inspect the applicability
question. Show a proposed checklist edit separately from actual
adoption and later result fields. Leave unsupplied records blank.
Include a blank reusable note with missing context/evidence/lesson
feedback and temporary draft notes. Preserve notes across cases,
mark old review output stale after edits, and ask before resetting.
No Mark learned, approval, automatic checklist update, or saved-record
claim. Keep input local to the open page.
Use text of at least 16px, labeled keyboard-accessible controls, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline with no external dependencies. Return complete HTML.
Give the next team a decision to make
Send L1 with its original condition and ask the next team whether their handoff has the same version-selection problem. The useful response is an applicability decision and a proposed check, not agreement with a general warning to be careful.
In an HTML lesson note in NOS, you can refine the lesson's visible wording after that discussion. Keep “when a handoff contains several versions” in the sentence so the condition survives when the note is shared beyond the original team. Add the next team's actual decision to the maintained reuse record.