Skip to main content

Checklists

How do you prevent a critical omission without turning skilled work into box-ticking?

Problem: A critical step is easy to miss, but a longer procedure or more training does not reliably protect the moment of risk.

Question: What is the smallest team control that prevents the dangerous omission and learns from real use?

Decision: Install a checklist only at an exact pause point, pilot it against baseline evidence, and revise the owning process when catches repeat.

A checklist is a Control instrument for repeated work. It coordinates attention at a moment when omission matters; it does not contain the whole procedure or replace professional judgment.

Inputs​

  • A validated process map or observed way the job is performed.
  • One prevented failure, its consequence, and evidence that the risk is real.
  • One intended outcome and one-to-three observable success conditions.
  • The approved governing standard or an explicitly proposed setpoint, plus its revision authority.
  • A named pause point, owner, coordinator, participants, and revision owner.
  • Baseline process and outcome evidence against which a pilot can be compared.

Design Deployment​

  1. Bound the job. Name the job, outcome, prevented failure, success conditions, and primary loop: Value, Belief, or Control. Checklists primarily serve Control. Route unresolved Value questions—who benefits and what good means—or Belief questions—what is true and what would change the model—upstream instead of encoding them as more items. Output: a bounded design brief.
  2. Place the pause point. State the trigger and exact moment the team stops. Use a separate page or screen for each pause point. Output: a checklist that appears when action can still change the outcome.
  3. Choose the mode. Use READ-DO when consequence is high, order matters, the work is unfamiliar, or failure is hard to recover. Use DO-CONFIRM when skilled participants need discretion and can safely complete a familiar block before confirming it. Record the rationale. Output: a mode suited to the work.
  4. Define choreography. Name the coordinator, participants, verbal confirmations, and person with authority to stop continuation. Output: an executable team interaction, not a private reminder list.
  5. Write critical controls. Label each item GATE when missing or failed evidence blocks continuation, and trace it to a named standard requirement or prevented failure. Label it PROMPT when an expert must assess conditions and state a judgment. Write a direct verb, familiar language, and observable evidence for each. Keep the protocol sequence in its owning procedure; the checklist may verify a critical handshake but never contains the whole protocol. Output: a testable set of controls.
  6. Compress. Remove background teaching, edge cases, preferences, and actions practitioners reliably remember. Aim for five-to-nine critical items and one page or screen per pause point. These are design heuristics, not universal limits; split or justify exceptions when the work requires more. Output: a checklist that can be used under real conditions.
  7. Plan the pilot. Define pilot status, process measures, outcome measures, run-state recording, revision owner, review date, and retirement falsifier before rollout. Output: a deployment-and-learning contract.

Public Checklist Interface​

Copy and adapt this text. It is a teaching instrument, not a machine schema.

Job:
Outcome:
Governing standard or setpoint:
Prevented failure:
Success conditions (1–3):
Primary loop: Value | Belief | Control

Mode: READ-DO | DO-CONFIRM
Mode rationale:
Trigger:
Pause point:
Owner:

Coordinator:
Participants:
Verbal items:
Stop authority:

[ ] GATE | PROMPT — Direct critical action — Requirement or failure trace: — Evidence:
[ ] GATE | PROMPT — Direct critical action — Requirement or failure trace: — Evidence:
[ ] GATE | PROMPT — Direct critical action — Requirement or failure trace: — Evidence:
[ ] GATE | PROMPT — Direct critical action — Requirement or failure trace: — Evidence:
[ ] GATE | PROMPT — Direct critical action — Requirement or failure trace: — Evidence:

Pilot status: PROPOSED | PILOTING | ADOPTED | RETIRED
Run status: USED | SKIPPED | OVERRIDDEN | UNTESTED
Verdict: PASS | CONDITIONAL | STOP | UNTESTED
Variance:
Correction owner: Pattern | Process | Platform | Standard
Next-run assertion:
Revision owner:

A pass requires evidence for every applicable GATE. A skipped, overridden, failed, blank, or untested gate cannot produce PASS. A PROMPT requires the named expert assessment and its evidence; it must not be converted into a pretend yes/no control simply to make scoring easier.

Pilot It​

Test with the people and agents who perform the job:

  1. Observe whether the checklist appears at the intended trigger and pause point.
  2. Record whether each run was used, skipped, overridden, or untested and why.
  3. Observe timing, interruption, coordination, ambiguity, and workarounds.
  4. Compare process measures—use, delay, stops, catches, overrides—with the baseline.
  5. Compare outcome measures with the success conditions; do not infer outcome improvement from compliance alone.
  6. Revise with the practitioners, removing noise before adding controls.
  7. Change the earliest Pattern, Process, or Platform owner when the same control catches the same structural defect repeatedly.

The theatre test is observed change from baseline: did use alter the targeted omission, coordination, recovery, or outcome? Guessed failure percentages, activity counts, or an arbitrary number of repetitions do not establish effectiveness.

Checks​

  • The checklist has one prevented failure and no more than three success conditions.
  • The mode rationale reflects consequence, ordering, familiarity, and recoverability.
  • A named person can stop work when a GATE fails.
  • Every item is critical, observable, and intelligible without its author.
  • Every GATE traces to a named standard requirement or prevented failure; no item silently redefines the standard.
  • Protocol choreography stays in its owning process or procedure rather than expanding the checklist body.
  • Run status and verdict cannot hide skipped, overridden, failed, or untested controls.
  • Process and outcome measures remain distinct.
  • The revision owner knows what evidence would change or retire the checklist.

Failure Modes​

  • Checklist theatre: boxes are checked without observable evidence or baseline change.
  • Checklist bloat: training, doctrine, or reliably remembered work hides the critical controls.
  • Wrong mode: READ-DO suppresses expert judgment, or DO-CONFIRM leaves ordered high-consequence work to memory.
  • No choreography: nobody coordinates confirmations or knows who may stop continuation.
  • False pass: skipped, overridden, failed, blank, or untested gates disappear into a pass score.
  • Value or belief laundering: a disputed outcome or uncertain model is encoded as another control item.
  • Recurring catch: the checklist grows because the producing process or platform never changes.

Proof Of Done​

A real pilot shows whether the checklist was used at its pause point, whether gates and prompts changed action, and whether process and outcome measures moved from baseline. The run records variance, correction, next-run assertion, and revision owner. A repeated catch produces an upstream change rather than another reminder.

Changes my mind: retire or redesign the checklist when the process makes the omission impossible, a reliable automated invariant replaces it, observed use adds more risk than it removes, or the targeted outcome does not improve despite valid use.

Evidence Labels​

  • Implementation guidance: WHO recommends local adaptation, team involvement, testing in real conditions, explicit verbal checks, measurement, and staged rollout.
  • Design heuristics: five-to-nine items, one page or screen per pause point, typography, and layout are useful compression prompts associated with checklist practice, including Atul Gawande's work. They are not universal safety laws.
  • Local evidence: only observed pilot runs can show whether a checklist improves this process in this setting.

Source Trail​

  • WHO Surgical Safety Checklist implementation guidance — primary implementation guidance for adaptation, team communication, testing, measurement, and rollout.
  • ISO 9001 process approach — primary guidance for ownership, interactions, controls, evaluation, and improvement.
  • Atul Gawande, The Checklist Manifesto — secondary design influence for pause points, checklist modes, brevity, and usability; treat presentation advice as heuristic.

Context​

  • depends-on Process Modelling — place the checklist inside an intended flow with ownership and measures.
  • depends-on Standards — name the contract or proposed setpoint each critical gate protects.
  • pairs-with Quality Assurance — automate invariants and preserve human judgment around the checklist.
  • contrasts-with Business Process Reengineering — redesign when the process cannot meet the outcome.
  • proved-by Performance Reality — compare process and outcome measures with the observed baseline.
  • applies-to Navigation System — route Value and Belief uncertainty upstream; use checklists for Control.

Questions​

Next question: Which real job will pilot this checklist, and what baseline change would justify adoption?

  • Which repeated catch should change its owning process or platform before another item is added?