Checklists: Conventional or Auditable

When we need to carry out a lengthy or complicated procedure, some of us have learned not to rely on memory to get all the right steps in the right order. We make checklists. We might check off the steps as we go, or after executing the procedure from memory, we might use the checklist to confirm that we got it right. These ways of using checklists — these "usage modes" and others — are what I'm calling "conventional."

We usually make checklists only if the procedure in question is complicated enough, or the consequences of missing a step are severe enough. But if the situation calls for a checklist of any kind, and if a conventional checklist is helpful, taking the next step to an auditable checklist is worth considering.

About conventional checklists

A conventional checklist functions as a reminder of the steps required when we execute a procedure. It also reminds us of the order in which we must execute those steps. There are two fundamental classes of conventional checklists, characterized by how they're meant to be used. [Gawande 2011] [Lau 2023]

READ-DO checklists

When people use a READ-DO checklist, they check off the items in the list as they execute them. This kind of checklist is sometimes called a "do-list."

DO-CONFIRM checklists

With a DO-CONFIRM checklist, people run the procedure often from memory and out of sight of the checklist. At some point they pause and check off the items of the checklist, confirming that they executed all the steps required.

The mental model we have of checklists of either category is planar. That is, we think of checklists as having been implemented on paper or a screen, where what you see is all there is (WYSIATI). Unlike Web pages, and unlike the forms we see on Web sites, conventional checklists have no moving parts, and no background software.

The audibility gap

Conventional checklists are better than no list at all, but they have limited value when something has gone wrong and we want to figure out what happened. Conventional checklists have no memory unless they're printed on paper and we save the paper.

But If the situation calls for a checklist of
any kind, and if a conventional checklist
is helpful, taking the next step to an
auditable checklist is worth consideringeven if we do save the paper, conventional checklists contain only checkmarks. Many cannot reliably provide evidence to post-incident investigators about whether a procedure was followed accurately, or exactly how the team deviated from prescribed procedure, or who executed which steps of the procedure, or in what order they executed them.

An auditable checklist is a checklist that serves the needs of both auditors and the users of conventional checklists. And auditors need to know the identity of the person who checked off the item on the checklist, and the date and time when they did it.

One way of making a checklist auditable is to add space for date, time, and user ID alongside the space for the checkmark for each item. Although this sounds simple enough, such a change dramatically reduces the usability of even the best-designed checklists. Users must enter much more data, and the checklist then becomes visually cluttered.

That's the problem. Extending a conventional checklist to include the information auditors need makes the checklist less usable for its primary purpose. I call this the auditability gap. Another way to think of it is that auditor's usage mode is incompatible with the usage modes of other users.

Closing the auditability gap

In some situations, technology can close the auditability gap. By converting the checklist into an active form, supported by software running in the background, we can capture all information needed for audits without troubling the people who use the checklist to run the procedure. To accomplish this, the user of the checklist must use it on an electronic device capable of running the background software. Any web browser will serve, but paper will not.

The tradeoff we must make to gain this capability is prohibitive in some situations. But if devices as simple as a commercially available tablet are available, users can get access to the auditable checklist and enter data as they would in a conventional checklist, while the checklist carries the burden of capturing the audit data.

Last words

When something has gone wrong, we need to know whether or not people followed prescribed procedures. Because the data contained in the auditable checklists provides the answers, the data captured in auditable checklists must be secured. This circumstance reveals another requirement: the data captured from auditable checklists must be lockable and tamper-proof.  Top    Next Issue

Projects never go quite as planned. We expect that, but we don't expect disaster. How can we get better at spotting disaster when there's still time to prevent it? How to Spot a Troubled Project Before the Trouble Starts is filled with tips for executives, senior managers, managers of project managers, and sponsors of projects in project-oriented organizations. It helps readers learn the subtle cues that indicate that a project is at risk for wreckage in time to do something about it. It's an ebook, but it's about 15% larger than "Who Moved My Cheese?" Just . Order Now! .

Footnotes

Your comments are welcome

Would you like to see your comments posted here? rbrenaXXxGCwVgbgLZDuRner@ChacDjdMAATPdDNJnrSwoCanyon.comSend me your comments by email, or by Web form.

About Point Lookout

Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.

This article in its entirety was written by a human being. No machine intelligence was involved in any way.

Point Lookout is a free weekly email newsletter. Browse the archive of past issues. Subscribe for free.

Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.

Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.

Related articles

More articles on Project Management:

Risk Management Risk: I

Risk Management Risk is the risk that a particular risk management plan is deficient. It's often overlooked, and therefore often unmitigated. We can reduce this risk by applying some simple procedures.

Mitigating Risk Resistance Risk

Project managers are responsible for managing risks, but they're often stymied by insufficient resources. Here's a proposal for making risk management more effective at an organizational scale.

Design Errors and Group Biases

Design errors can cause unwanted outcomes, but they can also lead to welcome surprises. The causes of many design errors are fundamental attributes of the way groups function. Here is Part II of our exploration.

Unresponsive Suppliers: I

If we depend on suppliers for some tasks in a project, or for necessary materials, their performance can affect our ability to meet deadlines. What can we do when a supplier's performance is problematic, and the supplier doesn't respond to our increasingly urgent pleas for attention?

Joint Leadership Teams: OODA

Some teams, business units, or enterprises are led not by individuals, but by joint leadership teams of two or more. They face special risks that arise from the organizations that host them, from the team they lead, or from within the joint leadership team itself.

See also Project Management for more related articles.

Forthcoming issues of Point Lookout

Coming September 3: Contributions in Team Meetings: Advocating

An agenda in the form of an ordered list of topics might not provide an appropriate framework for a given meeting. For example, if A depends on B, and B depends on A, we must find a way to discuss A and B together in some orderly fashion. Here are some alternatives to linear, ordered agendas. Available here and by RSS on September 3.

And on September 10: Contributions in Team Meetings: Scoping

Some meetings focus on solving specific problems. We call them "working sessions." More often, we delegate problem solving to task teams, while meetings wrestle with the difficult task of identifying or "scoping" problems rather than solving them. Scoping discussions can be perilous. Available here and by RSS on September 10.

Coaching services

I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenaXXxGCwVgbgLZDuRner@ChacDjdMAATPdDNJnrSwoCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.

Get the ebook!

Past issues of Point Lookout are available in six ebooks:

• Get 2001-2 in Geese Don't Land on Twigs (PDF, )
• Get 2003-4 in Why Dogs Wag (PDF, )
• Get 2005-6 in Loopy Things We Do (PDF, )
• Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
• Get 2009-10 in The Questions Not Asked (PDF, )
• Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info