Don’t know, but checklists have been a part of “best practice” approaches in many different disciplines going back decades. Some instantiations have been codified into “hardware,” as in double-key activation procedures in banking, military and industrial operations, where sequential attention of multiple people are synchronized by force.

“The US financial advisor who attempted to fake his own death in a light aircraft crash will certainly not be elevated to the pantheon of criminal masterminds, after police yesterday revealed he’d left a bullet-point list of his fake distress call in the plane before bailing out.”

Police found

“evidence including a book of campsites in America missing its pages on Alabama and Florida, and a bullet-point list scribbled on the back of a book that read: ‘cracked windshield, window imploded, bleeding profusely’.”

Need I say more on checking checklists! :-)

Fair warning. That’s why I emphasized “without hopefully making the system too brittle”.

The difference, however, is that in complex systems I design, the computer with a rules engine can consider a range of I/O, criteria, rules, datasets, analytics and workflow far, far larger than any homo sapien can in real time.

A moderately complex decision tree can produce a permutation of several million decision points. Even if you eliminate all redundancies, there would remain literally thousands of inter-related decision points to cut through to arrive at a final action. Computers can do this better than homo sapiens. There are things like pattern recognition that humans are better at in certain situations, but I fear not for too long.

So, yes, there’s no fool-proof “checklist processor,” machine or human. But while homo sapiens often forget, machines don’t. I suppose our last defense against the machine is “creativity.” :-)

The first is dependencies. “If this task is of this certain type, perform these subtasks. Otherwise, don’t.” That’s hard to communicate in a static, printed checklist, and you end up with lots of crossed-out items and un-filled-out fields. You can’t glance at the list and quickly see what’s left to do. Not a huge deal, but a shortcoming nonetheless.

The second is that, since the checklist generally prevented people from making minor blunders, the mistakes that *did* occur were major. Perhaps this is more of a morale issue, because when people screwed up, it was a big deal.

The biggest problem, though, was that people forgot how to think on their own. As long as the checklist was complete, we assumed the task would succeed. But every project was unique, the parameterizations weren’t perfect, and the machines themselves were highly susceptible to environmental changes that couldn’t always be squeezed into a single checklist item.

I don’t think you can blame homo sapiens for not being able to execute checklists. A computer executing a faulty checklist (i.e., a program) will be just as likely to fail as a human (if not moreso, since most computers can’t “think outside the box” of instructions they’ve been given). Our problem is coming up with a perfect checklist. Or more likely, balancing between crossing items off a list and actually analyzing the situation.