The checklist existed, but nobody used it. It lived in an old document, three clicks away from the pull request, and people remembered it only after something escaped. The team did not have a checklist problem. It had a distance problem.
Checklists are easy to admire and hard to keep alive. They start with good intent after an incident, a missed test, or a painful handoff. Then the work moves on, the checklist stays somewhere else, and memory becomes the real process again.
A useful checklist sits close to the work. If it guides pull requests, it belongs in the PR template or review habit. If it guides release, it belongs near the deploy command and rollback note. If it guides customer migration, it belongs beside the runbook people actually open.
Closeness is not only about location. The checklist should use the language of the task. Confirm tenant scope. Verify empty-state copy. Link the migration rollback. These are better than broad reminders like be careful or test thoroughly. Specific checks reduce interpretation at the moment of pressure.
The best checklists are short enough to survive. A twenty-five item list may be useful for a rare launch, but it will not fit every small change. A daily checklist should protect the most expensive mistakes, not prove that the team remembered every possible concern.
Checklists also need ownership. Someone should be allowed to remove stale items, add a lesson after a miss, and split a checklist when it starts serving two different kinds of work. Without ownership, checklists become historical artifacts.
Used well, a checklist does not replace judgment. It protects judgment from fatigue. It catches the simple things so people have more attention for the unusual things.
When a team says people keep forgetting a step, first look at where that step lives. Move the reminder closer to the decision, make it concrete, and keep it small enough to use. A checklist that is near the work has a chance to become part of the work.