Preventable Errors are just that—preventable. The Checklist Manifesto teaches a process that keeps these errors within a more favorable statistical range.
"This has never been a problem before," people say, until one day it is."
Every instance involved an instance of an undesired outcome (failure of some system operating within its normal capabilities) followed by an analysis of why the system prematurely failed. Once the factor(s) is identified, the "best practices" steps to prevent it are written out and followed.
When you're making a checklist you have a number of key decisions. You must define a clear pause point at which the checklist is supposed to be used (unless the moment is obvious, like when a warning light goes on or an engine fails). You must decide whether you want a DO-CONFIRM or a READ-CONFIRM checklist. With a DO-CONFIRM checklist team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off—it's more like a recipe. So for any new checklist created from scratch, you have to pick the type that makes the most sense for the situation.
The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.
The wording should be simple and exact. Use the language of the profession. Even the look of the checklist matters. Ideally, it should fit on one page. It should be free of clutter and unnecessary colors. It should use both uppercase and lowercase text for ease of reading.
Test you checklist
After a failure, run a post moretem to establish what went wrong. Then, enumerate the preventative steps that would have kept the failure from happening.
Do you have clear, concise objectives for your checklist?
Is each item:
Have you considered:
Does the checklist:
Does the checklist