Theoretical background based on Atul Gawande

When you’re making a checklist, Boorman explained, 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 checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, 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. Boorman didn’t think one had to be religious on this point. “It all depends on the context,” he said. “In some situations you have only twenty seconds. In others, you may have several minutes.” But after about sixty to ninety seconds at a given pause point, the checklist often becomes a distraction from other things. People start “shortcutting.” Steps get missed. So you want to keep the list short by focusing on what he called “the killer items”—the steps that are most dangerous to skip and sometimes overlooked nonetheless.

Gawande, Atul. The Checklist Manifesto (pp. 122-123).

Implementation in our software

We calculate a bureaucracy overhead for each checklist. If you stay below this calculated overhead when filling out a checklist, we assume that this was a "do-confirm" flow. If it takes longer, we assume it's a "read-do"-flow.