Workplace safetyMulti-site operations
Local checklist variations: record why a site differs
A local-variation register should explain which shared requirement differs, why, who reviewed it and when it applies. Without that context, an intentional adaptation can look like a missed task or an unauthorised removal.
At a glance
A local-variation register should explain which shared requirement differs, why, who reviewed it and when it applies. Without that context, an intentional adaptation can look like a missed task or an unauthorised removal.
Define the decision behind the record
Distinguish a local wording change from a change in what is checked. Record the relevant site activity or layout and responsible approval. The register should not become a convenient way to mark difficult work as permanently not applicable.
Record what differs and which comparisons remain valid
Identify the baseline question and the exact local difference. Record the operational reason, affected site and responsible review. A wording change may alter the observation, criterion or task boundary, so it should not automatically be treated as cosmetic.
Keep the approved variation, effective version and review trigger linked to the shared definition. Preserve the context of completed records and communicate the applicable instruction. Pending proposals should remain distinguishable from implemented local practice.
Test a cross-site report using records before and after the variation. Another reviewer should recognise which results can be compared and where scope differs. Do not remove relevant local detail simply to make percentages align; make the comparison boundary explicit.
Worked example
A site has a different equipment arrangement from the standard checklist. The responsible people document the proposed variation and review its meaning. Reports can distinguish this controlled change from a blank result on a shared question.
Build a usable record
Use the fields below to capture the facts needed for this particular decision. Keep the actual observation separate from any later correction or approval.
- Site and shared check identifier
- Proposed variation
- Operational reason and scope
- Review and effective date
- Next review trigger
Example record and review decision
Fictional record example: VAR-08 / SITE-B: baseline question, local wording, reason, approver and review trigger.
Identify the operational reason for the difference and determine which comparisons remain valid across sites.
Treating every wording change as harmless can conceal a different task boundary or acceptance criterion.
Test the review, not just the form
Compare the variation register with the active form. Confirm that retired variations do not remain in use and that dashboards describe them accurately. Review repeated not-applicable results to see whether the underlying template needs a controlled change.
A few useful answers
Is not applicable the same as an approved variation?
No. Make the basis and review of persistent differences explicit.
Should every local difference be removed for consistent reporting?
Not if the difference reflects a justified operational need. Control and explain it, then identify which measures remain comparable instead of hiding the local scope.
Sources and further reading
MarkdownExplore starter templates
Start with a useful checklist
English
