the volume and complexity of what we know had exceeded our individual ability to deliver its benefits correctly, safely, or reliably. – Atul Gawande
I’ve just finished reading The Checklist Manifesto by Atul Gawande. In it, he provides compelling evidence that something as simple as checklists can have a very significant impact in any field where there is complexity and where there are serious consequences when mistakes are made. Does this sound like any field you know?
Gawande is a surgeon, so he spends a lot of time discussing the impact of using checklists in the operating room, but in the process of learning more about how checklists are already being used, he also takes a closer look at how skyscrapers are built, airplanes flown, investments screened, and food prepared. It turns out that the best practitioners in all of these fields rely heavily upon checklists to consistently deliver safe, reliable results.
Nonetheless, Gawande also notes that many, otherwise capable, people still choose to ignore the evidence and avoid using checklists. Why? One simple reason is that there is nothing sexy about a checklist. It’s much easier to get excited about the latest technology, whether that be a surgical robot or project management software. Another reason is that some people feel that a checklist takes the “art” and the “individuality” out of what they do. After all, if their job could be simplified into a mere checklist, then anyone could do it. And a third reason is that they claim that it will take too much time to stop what they are doing and run through a checklist.
Well, it’s hard to argue with the first excuse that checklists aren’t sexy, but they are certainly effective, and they cost very little to create. As for the argument that they “dumb down” skilled work, I think those folks are missing the point of a checklist. It’s not intended to replace expert judgement. A checklist is more like a safety net. It helps prevent simple mistakes so that experts can focus on what they do best. It works because there are limits to how much the mind can remember at one time. And finally, a well designed checklist takes very little time to review and, in practice, saves time that would otherwise be spent correcting simple mistakes.
Aviation is perhaps the field most committed to the use of checklists. Inside every cockpit is a flight manual which contains clear, concise procedures for almost any contingency, and it is used by even the most experienced pilots. Some of these pilots have flown thousands of flights, but they still follow procedural protocol to the letter. Familiarity can lead to overconfidence and complacency, and they know that it could also lead them to overlook the obvious. Alternatively, when there is an emergency, they turn to the flight manual for the proven best method of handling the condition. It helps to them to act quickly and maintain focus.
Gawande also found that checklists can actually help to increase communication across teams by making it an explicit part of how work gets done. For example, the checklist used in operating room procedures included a step in which each member of the team introduces themselves to the others. It also included a step for anyone to express concerns about the specific procedure or patient. At first, some teams members, mostly surgeons, felt awkward using the checklist, but polls taken at the end of operating procedures showed that most people rated collaboration much higher than before the checklist had been put into place. And, most importantly, many unnecessary complications, including deaths, were avoided.
So, could checklists have a place in IT? In the past, I’ve seen many ineffective attempts to add checklists in IT. Often, these checklists were simply governance in disguise. They were created somewhere else in the organization, or by external experts, and then imposed upon the team. Not surprisingly, they were seen as just more busywork, not something that added any real value. Consequently, they were either ignored or completed as an afterthought. It should be obvious, but it’s important that the checklists add real, measurable value, and are perceived as doing so by the people having to use them. Therefore, it should also be obvious that the people using them should be part of developing them and they should be encouraged to continuously adapt them to their needs. They are, after all, the experts.
So, where should we begin? Begin where there is the most risk of something being overlooked or not communicated. What are the types of activities that we do repeatedly (absent-mindedly), or the ones that we don’t do often, but when we do there is likely to be pressure (urgency) to get it done fast. Developers might benefit from running through a quick checklist before checking in their code. The operations folks might benefit from a series of checklists to run through before, during, and after releases to production. Finally, it might be helpful to have a repository of checklists for responding to specific events, especially outages and other emergencies. I say “might” because there are no hard and fast rules that apply to every team and every situation. You have to use your own judgement, run your own experiments, and measure the results. Over time, each checklist should be reviewed and updated according to what’s been learned.
Perhaps it will become commonplace someday for IT folks to receive a “flight manual” specific to their job when they are hired. I’d love to hear your experiences, good or bad, using checklists.
