Checklist Manifesto and Technology

By Steve Backman, May 18, 2010

 

Have you read the Checklist Manifesto or run across Atul Gawande in the New Yorker or on the Daily Show (http://gawande.com/uncategorized/daily-show)? I’ve been wondering how his surgical reflections apply to technology projects. 
 
His thing is how simple check lists can save lives in the operating room. And including in world class hospitals such as his own base in Boston. Most technology initiatives don’t have the life and death urgency of emergency room surgery—certainly not mine. Yet there is a lot that applies. 
 
Have you ever been on the receiving end of a Friday afternoon “catastrophe”? One of my favorites is that frisky contact list a client needs urgently for a end of day mailing or weekend event. I had one just a week ago. I’m sure Dr G would say, before calling in emergency room care, how about a simple check-list: .
 

A checklist: "I can't print my contact list" 

  • Can you see the lists on screen or in the browser? If so, the data system probably has not failed.
  • Can you print an unrelated document from some other software? If not, then the problem is even less likely to be in the list software.
  • Is the printer plugged in and turned on? (Please, you’d be surprised.)
  • Does the printer have paper, not jammed? Walk over and check.
  • Is the printer reporting toner out or other message?
  • Is the printer visible on line in your “my printers” or the Mac equivalent? (How to check this may require more details.)
  • Can you print the list to another printer, even if that’s not the one needed for the job?
  • If not to any, does the problem go away if you restart your computer?
  • Can you see your network shared folders?
  • Can someone at another desk print that list to the required printer? (If so, you can probably get by and go home for the weekend.) 
Do you find this simple list list insulting? Gawande discusses how maybe half of the 150,000 or so annual deaths from surgery complications could be prevented by routine operating room system checks on par with this list. The world of technology, like the world of medicine, is a complex one requiring specialized knowledge. Gawande says in complex environments, under pressure to produce results, two problems can occur: 
 
  • We forget to check some basic things.  We’re under pressure and we jus forget. 
  • Or, we think those basic things don’t apply.  Or not to me. “’This has never been a problem before,’ people say. Until one day it is.”
 
Formalizing the database-won’t-print-my-list checklist or others like it may reduce support calls or lost time. They also should increase self-reliance and distribute knowledge. 
 
Having the list also relieves the potential of offending someone by asking to check the obvious, like are you plugged in. “The checklist gets the dumb stuff out of the way.” It reduces internalized tensions, and lets you focus on the hard items. Completed lists create documentation that can be checked if trouble arises later. 
 
Anyone who has taken part in training workshops I do know I’ve been partial to check-lists. I have used more complicated ones as thought experiments or discussion organizers. The book inspired me to review them and start creating simpler, more focused ones.
 

Checklists Support Collaborative Projects

 
I started the book expecting an alternative reality of software project management. Checklists are not an alternative way of doing technology project management. On the other hand, checklists could improve project management.  
 
For example, we have a highly technical checklist for initial steps in configuring a Drupal site. Follow the steps and it you get a fresh Drupal site operational in 15 minutes or so. (Then the fun begins…) On the less technical side, we also have worked on general project management checklists for implementation project launches.  To be useful in the way Gawande describes however, I now see two things that we need to bring into focus. 
 
First,  to be effective, the checklist methodology needs to be collaborative. A personal to-do list is not the same as a team checklist. One of Gawande’s operating room checklist essentials is that everyone on the team introduce themselves and say what their role will be in the surgery, whether emergency or not. The collaborative approach to reviewing the list increases the chance that the team as a whole will catch possible slip-ups.  
 
Second, someone has to “own” the list. According to Gawande, going back to the 1930s, airlines were probably the first large scale adopters of checklists. Generally, it’s the co-pilot who checks the list against what the pilot is doing. Similarly, in his experiments with medical checklists  around the world, he describes in meticulous detail discussion about who owns the list. 
 
Going further, Gawande  discusses effective checklists that sometimes mainly focus on ensuring team communication. The chapter on construction architecture, engineering and contracting had the most applicability to our kind of projects. Like a construction project and unlike a surgery, technology projects often go on for a while, these days depend on teams not working physically in close proximity, and have elements of complexity that can’t be predicted or modeled in advance. 
 
The construction contractor firm he profiles does use basic checklists to cross-check some processes. For me, these might correspond to a website relaunch checklist, switching the domain, migrating from development to production, setting security, and so on. A lot of things have to happen in the right sequence to have a smooth cutover. 
 
Interestingly, in the construction example, other checklists focus instead on ensuring that at each critical point in a project, the various sub-contracting teams talk to each other. “In the face of the unknown…the builders trusted in the power of communication.” “They believed in the wisdom of…making sure that multiple pairs of eyes were on a problem…” 
 
I liked that. Especially in the modern era of software development, influenced to one degree or another by “Agile” philosophies, we may tend to emphasize adaptability and flexibility over discipline and formality. Yes, user stories and design mockups may change in the course of completing a software component, and if not continuously updated, testing may suffer. I’m not going to justify that. What I learned from the construction example is the power of this other kind of list, ones that bring back together the dispersed teams to communicate. Did the designer and the developer verbally confirm together that their respective key specifications were met? These types of list check that everyone has remained in sync on their key processes and can vouch that requirements have been met. I’m going to explore these as well.
 

A Word On Resources

 
If you are intrigued, read the book.  Or at least spend some time on his website: http://gawande.com/. Tools that fit with using checklists for tech projects would need to have these features: collaboration, ability to set dates, ability to create reusable templates. 
 
  • Google spreadsheets would be an easy one. 
  • Though I use it personally, I don’t recommend Remember the Milk mainly because I don’t see how to create a checklist template. 
  • Basecamp makes a closer fit because it allows you to create to-do list templates that can be maintained and reused in new projects. A limitation is that someone with overall account administrator status has to post the edits. 
  • While reading the book, I came across http://checkvist.com. While I haven’t used it, it seems like a great standalone fit for “checklist manifesto” experiments, even in its free version.
  • And here is a great checklist for making checklists: http://www.projectcheck.org/checklist-for-checklists.html

 

Trackback URL for this post:

http://www.idealware.org/trackback/2293