Maintenance
Part of A practical reference for building operational checklists that hold up
Operational checklists template: what each field is for
An operational checklists template field by field: header, items, stop line, sign-off and problem line, plus the one field each task type adds.
A blank template is a set of fields, and every field either earns its place or gets ticked without thought. Start from the skeleton in the operational checklists overview, then decide what each field is for and what to leave off.
What to take away
- Every item needs an observable state, not an intention.
- The header and footer fields make a list traceableversion, who completed it, when, and what was wrong.
- Each task type adds one field the generic list lacks. Add that field and nothing else.
- The handover checklist is the one most businesses are missing and the one that pays back fastest.
One master template, field by field
The fields below come from the opening and closing skeleton. Square brackets are yours to fill. The table beside it says what goes in each field and what to leave out.
[SITE] OPENING Version [n] [date]
Done by [role] Target time [n] minutes
[ ] [Item] -> [What you should see]
[ ] [Item] -> [What you should see]
[ ] [Item] -> [What you should see]
STOP IF: [condition] -> do not continue, call [role]
[ ] [Item]
[ ] [Item]
Completed by [name] Time [ : ]
Anything not right: [one line, and who was told]
| Field | What goes in it | What to leave out |
|---|---|---|
| Version and date | The edition in use | A date nobody updates |
| Done by | A role | A named person, which breaks when staff change |
| Target time | The time the list should take | A target nobody can meet |
| Item and "what you should see" | One action and its observable state | An intention such as "check the stock" |
| Stop if | The condition, and who to call | A stop line placed at the end |
| Completed by and time | A name and a time | A signature block nobody reads |
| Anything not right | One line, and who was told | A blank space with no prompt |
Opening and closing template
- Site opening, version, date, done by
- Target time in minutes
- Item -> what you should see
- STOP IFcondition -> call role
- Completed by, time, anything not right
The header and footer fields do the traceable work
The items are the part people design. The fields around them decide whether the list still means something later.
The target time keeps the list from growing without limit: when it no longer fits, something must come off. How to set the time out on the page is in operational checklists format.
The stop condition sits in the middle, where the decision actually occurs, not at the end.
The last line matters more than the ticks. A list with nowhere to record a problem trains people to tick and move on.
The one field each task type adds
The master template suits a routine task. The other shapes keep its header and footer and add a single field where a generic list breaks down.
If the task is / Add this field
- Rare, or costly to get wrong
- A confirm line under each step
- Familiar, with a consequential moment
- A named pause point
- Passed between people
- Not done, and received by
- Going wrong right now
- An item that says what not to do
A confirm line works because the steps are performed while reading. The instruction not to work from memory does real work: without it, a familiar operator runs on habit and treats the list as a receipt, one of the patterns in operational checklists mistakes.
Read and do sequence
- Do not work from memory
- Read each line, then do it
- Single action, then confirm what you see
- Decisionif A continue, if B stop
- Keep under about ten items
Read-and-do lists must be short. Past about ten items, people stop reading and start remembering.
The pause point is the whole design of a do-and-confirm list. It has to be a named event: before the first cut, before the vehicle moves, before the transfer is released. One person reads each item aloud and another answers with the observed state.
Do and confirm at pause
- Work done from expertise
- Run list at named pause point
- One person reads, one answers
- Anything not confirmed: stop here
The World Health Organization developed its surgical checklist after extensive consultation aiming to decrease errors and adverse events, and the read-aloud step is not optional.
A handover list exists because the cost of a bad handover lands on someone who was not there to prevent it. The "Not done" field is what people leave off, and that is why handovers fail. Recording it is not an admission. It is the only way the next person can prioritize.
Handover template fields
- State nowrunning, paused, overdue
- Watch forlikely failure, customer waiting
- Not donewhat I did not get to
- Confirmed received by name and time
The received-by field makes the handover an event with two parties, not a desk note. In the same way, an action in a meeting record needs an owner who said the words out loud.
The first-five-minutes list is not an incident procedure. It covers the period before anyone senior has arrived, when the natural response is to do something rather than the right thing. Its last item names the tempting action not to take.
First five minutes
- Make it safespecific action or no action
- Stop what, so it does not get worse
- Tell role, by route, now
- Write down time and what you saw
- Do not do the tempting destructive action
Item four, writing down the time and what you saw, makes later review possible, but people always skip it unless it is on the list. Keep the list to five items, because it is read by someone whose attention is already gone.
The UK's Health and Safety Executive groups the most common causes of serious injury at work, such as slips and trips or working at height, and that is a fair place to look for the tempting action.
Rules that apply to every skeleton
Settle these once and every list in the business stays consistent.
- Signature.A name and a time, where the completion matters to someone else. A signature block on a list nobody checks turns the exercise into paperwork.
- Item count.For read-and-do, about ten. For do-and-confirm at a pause, about seven. Beyond that the list stops being run and starts being signed.
- Shared roles.One list can cover two roles only if each item names its role. Unattributed items in a shared list are the ones everyone assumes the other person did.
What to do with completed lists
Decide before you start how long you keep completed lists, who looks at them, and what happens when one shows a problem. Without that decision the problem line is a field nobody reads.
A pile of completed lists nobody reads is the strongest argument against the whole practice. The build order covers how to set up that review. For filled-in versions of these fields, the worked examples show what a completed list looks like.
When a checklist is the wrong document
Where a task needs teaching rather than confirming, the answer is a written procedure instead. The two documents are often confused, and a procedure used as a checklist is ignored within a month.
Common questions
Should the checklist be signed?
A name and a time, where the completion matters to someone else. Anything more is paperwork.
How many items is too many?
For read-and-do, about ten. For do-and-confirm at a pause, about seven. Beyond that the list stops being run and starts being signed.
Can one list cover two roles?
Only if each item names its role. Unattributed items in a shared list are the ones everyone assumes the other person did.
Why keep a problem line?
The last line matters more than the ticks. A list with nowhere to write what was not right trains people to tick and move on.
