How can you prevent mistakes? Some mistakes have extraordinary costs: airplane crashes, surgical infections, building collapses, nuclear power-plant explosions. Even the mistakes that don’t kill people — like software defects and leaky roofs — can slow you down by adding waste to a process, forcing you go back and spend time (and money) to fix a problem. In either case, we don’t choose to make these mistakes. So how do we prevent them?
Atul Gawande proposes a solution for all sorts of endeavors in his book The Checklist Manifesto: How to Get Things Right. It’s a short, engaging read, and I recommend it for anyone who has to apply knowledge to complete a task. That’s most of us.
We use checklists and recipes in some of our software development processes, and I’m in the process of applying what I’ve learned to improve them. I hope to share some of the results here in coming months — supposing that the final product isn’t too site-specific — but in the meantime, here are my more-or-less raw notes from Gawande’s book, which isn’t specific to any particular industry, although it was written from a surgeon’s perspective.
- Checklists are all about managing complexity, providing a “cognitive net” against “flaws of memory and attention and thoroughness.” They are “forcing functions . . . straightforward solutions that force the necessary behavior.” A good checklist should help its users “get the stupid stuff right.”
- The project plan is a kind of checklist. And the communication (submittal) schedule is a complexity manager. The idea is to communicate what needs to happen when in a complicated process (like building a skyscraper, writing software, or operating on a patient) and having a process in place to ensure that all of the parties in the project have shared all of the information about changing requirements and problems available at specific times.
- It’s possible/advisable to use tools to manage complexity, conflicts, and information integration. Sometimes the result of using the tool looks like a checklist, but not always. Sometimes it’s a Gantt chart or a cook’s recipe.
- The checklist steward: Anybody can change a checklist, but it has an owner who feeds and waters it.
- Complex situations don’t (usually) require detailed instruction. They do require high-level goals and lots of communication. (Gawande gives the fascinating case study of Wal-Mart’s response to hurricane Katrina in 2005.) Solutions should be simple, measurable, transmissible. They should encourage team interaction and engagement. Project owners should facilitate communication for complex tasks.
- The team huddle helps coordination, and it can help with keeping commitments. It’s important to communicate risks and issues early and often.
- Communication should happen (at the very minimum) during specified “pause points” between transitions in the process. In the operating room, these points might be just before administering the anesthesia, before closing up the patient, etc. In an airplane cockpit, they are before starting the engines, before leaving the gate, before take-off, before landing, and so on. (Figuring out what these are in a software development process is something I’ve already started considering.)
- Aviation uses lots of small checklists. A “normal situation” checklist should be very short. An exceptional situation should be very brief, readable, and actionable, too.
- Good checklists are made by practitioners, usable, available, put into use, about 5-9 items long, tested, and completable in about 60-90 seconds (or less).
- Bad checklists are long, imprecise, vague, hard-to-use, or impractical.
- Cockpit crew have created two categories of checklists: DO-CONFIRM and READ-DO. “With a DO-CONFIRM checklist . . . 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.”
- Things that are “never” forgotten by a normal practitioner don’t need to be on a list.
- After they’re put into use, checklists need continuous improvement. They must be revisited and refined. It’s a good idea to put a publication date on them.
- Most people — doctors, financiers, software engineers, etc. — don’t like to use checklists. They consider them neither fun nor in keeping with the “heroic” nature of their role. They feel checklists are “beneath them.”
- Ideally they should be usable and helpful for both novices and old-hands.
- Checklists should not be rigid, creativity- or team-killing exercises. They’re designed to “get the dumb stuff out of the way” and provide the leeway to be creative on the hard/sexy stuff. They’re frameworks for self-discipline and productivity.
Other people’s notes about the book:
Do you use checklists? How well do they work for you? What do you like and dislike about them? Feel free to leave your feedback in the comments.
