Skip to main content

Checklists

How do you catch the dangerous omission without turning judgment into box-ticking?

A checklist is a cognitive net for repeated work. It protects attention from memory failure at the moment an omission would matter. It does not perform the work, teach the whole method, or make the decision.

Use one when a job repeats, a critical step is easy to miss, or a completion claim lacks evidence. Do not create one for a process that should be removed or redesigned. Use Business Process Reengineering when the structure itself creates the failure.

Inputs​

  • One repeated job with a named owner and intended outcome.
  • Evidence from a real omission, near miss, defect, or unexplained variance.
  • The procedure or observed way the work is actually done.
  • The consequence of missing each candidate control.

Design The Checklist​

  1. Name the pause point. State the exact moment when the operator must stop and check.
  2. Choose the mode. Use READ-DO for unfamiliar, ordered, or high-risk work. Use DO-CONFIRM for expert work that allows judgment before verification.
  3. Keep critical controls only. Include five to nine actions whose omission can change the outcome. Put teaching and edge cases in the owning procedure.
  4. Require observable evidence. Each control names what proves it happened: a reading, artifact, decision, source, owner, or witnessed state.
  5. Close the variance. Record what failed, why, what changed, and what the next run will test.

Write one direct action per line in the order the work or risk appears. Use familiar language. A practitioner should understand the checklist without its author present.

Choose The Mode​

Use READ-DO as a step-by-step control: read one item, act, then advance. Use it for unfamiliar, high-consequence, or order-dependent work. Pause before irreversible actions and at handoffs where missing evidence changes the decision.

Use DO-CONFIRM as a professional safety net: complete a familiar block of work, then confirm the critical controls at a named pause point. Switch to READ-DO when errors repeat, conditions change, or expertise is absent.

Checklist Shape​

Job:
Owner:
Mode: READ-DO | DO-CONFIRM
Pause point:
Setpoint:

[ ] Critical action — Evidence:
[ ] Critical action — Evidence:
[ ] Critical action — Evidence:
[ ] Critical action — Evidence:
[ ] Critical action — Evidence:

Verdict: PASS | CONDITIONAL | STOP | UNTESTED
Variance:
Correction:
Next-run assertion:

Blank boxes are not evidence. A score without cited proof is not a verdict. Keep recognition, comprehension, behaviour, and business outcomes UNTESTED until observed directly.

Preserve The Setpoint​

A checklist is the durable setpoint for repeated work. A completed scorecard is one run's gauge reading. Never delete or replace the checklist because a run is complete, because its scorecard was rewritten, or because its controls appear elsewhere in prose.

Improve the checklist in place. Preserve effective controls, add missing controls, merge genuine duplicates without losing their test, and keep the prior intent recoverable in version history. The mutable run record may be replaced; the checklist template must survive to seed the next run.

“Remove” means retire a weak control only after its protective function is replaced or evidence proves it unnecessary. It never means delete the checklist itself.

Run And Improve​

Test the checklist with the people who perform the work:

  1. Observe where they hesitate, skip, reinterpret, or work around a control.
  2. Ask which critical step is missing and which listed step adds no safety.
  3. Separate input failure, execution failure, local exception, and shared-standard failure.
  4. Remove noise before adding another control.
  5. Change the owning process when the checklist keeps catching the same structural defect.

Failure Modes​

  • Checklist theatre — boxes are checked without evidence.
  • Checklist bloat — doctrine and edge cases bury the critical controls.
  • Wrong mode — DO-CONFIRM is used where ordered execution is safety-critical, or READ-DO suppresses expert judgment.
  • No pause point — the list exists, but nobody knows when to use it.
  • Outcome inflation — source checks pass, so human or business outcomes are claimed without observation.
  • Recurring catch — the same defect returns because the process or platform never changes.

Proof Of Done​

The checklist passes when:

  • one owner can run it at the named pause point without coaching;
  • every checked control has observable evidence;
  • blank, failed, conditional, and UNTESTED states remain visible;
  • it catches the known dangerous omission without creating a new delay; and
  • the next real run tests whether the correction raised the baseline.

Changes my mind: remove the checklist when the process makes the omission impossible, a reliable automated control replaces it, or real runs show the list adds more risk than it removes.

Context​

Questions​

Which checklist in your current workflow is actually DO-CONFIRM—and which is READ-DO being treated as DO-CONFIRM?

  • Which control repeatedly catches the same defect, and what upstream change would make it unnecessary?
  • What is the smallest checklist that catches the most important failure without creating compliance theatre?
  • Which step does everyone skip, and what does that reveal about the process design?

Next question: Which recurring omission needs an evidence-bearing control at the next pause point?