Written by Atul Gawande, this book outlines the power that a lowly checklist brings to “get things right”. The book is certainly an interesting read, but it goes beyond that; if you study how people work, or are tasked to try to improve the effectiveness of workers, then reading this book is an imperative.
I wrote a post on this topic 9 months ago called “Is the Checklist mightier than the Model?” after the New Yorker Article by the author was pointed out to me by Jacob Ukelson. Since that time I have become increasingly convinced that the power and simplicity of the checklist might represent the best approach for allowing teams of people to coordinate their work. At the BPM 2010 conference, I saw many studies of process representations, and attempts to measure their effectiveness, but not a single study of using a checklist as the process model. I asked many of the researchers casually why they are not studying checklists. The response was usually a non-verbal equivalent of “are you serious?” I resolved to study this further, and the place to start is with this book.
Atul Gawande is a surgeon concerned, as I suppose most surgeons are, about the nature and cause of complications during surgery. A surgeon is an extreme type of knowledge worker: highly trained for many years, because of the need for on-the-spot expertise on all the possible situations that might occur. The introduction gives a couple of anecdotes that make the case that inspite of all the training and preparation, situations that surprise the medical professionals still occur.
No matter how routine an operation is, the patients never seem to be.
The root cause of our modern difficulties is the extremely large amount of knowledge that is available to us today. He says “the balance of ignorance and ineptitude has shifted.” There is plenty of knowledge to be leveraged, but the challenge is “making sure we apply the knowledge we have consistently and correctly.” He says that “we have accumulated stupendous know-how” but “that know-how is often unmanageable.”
Chapter one explores how we are faced with extreme complexity. He points out that a typical doctor will face in their regular practice 250 different primary diseases and conditions over the course of a year. He points to the “deluge of almost 700,00 medical journal articles per year.” For those thinking that information systems might help bridge the gap, he points to the sobering discovery that “you commonly find that the [diagnostic codes for] particular diseases your patients have do not actually exist in the computer system.” But medicine is not the only field with extreme complexity, and other fields have developed ways to handle the complexity.
Chapter two explores the initial use of the checklist in aviation with the introduction of the B-17 bomber which introduced a quantum leap of complexity above other aircraft of the time. He also follows Peter Pronovost who introduced checklists into surgery at Johns Hopkins Hospital with the dramatic results: in that year they estimated the check list prevented 8 deaths and saved over $2 million.
Ok, I am sold: all I need is to give everyone checklists to make everyone more effective? Not so fast! He visited Boeing to find out how they make checklist, and found:
There are good checklists and bad… Bad checklists are vague and impractical. They are made by desk jockeys with no awareness of the situations in which they are to be deployed. They treat the people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on.
This struck me as being oddly similar to the problem we have when people define business processes for others, without really understanding the dynamics of the situation. He goes on:
It is common to misconceive how checklists function in complex lines of work. They are not comprehensive how-to guides… They are quick and simple tools aimed to buttress the skills of expert professionals. And by remaining swift and usable and resolutely modest, they are saving thousands upon thousands of lives.
He talks about the difference between “complicated” and “complex”. Complicated problems can be broken into a series of simpler problems. While a complicated problem may require a lot of work, the solution is repeatable. Complex problems, however, are sensitive to their unique situation, and the solution is not repeatable in the same way. We touched upon complex problems in Mastering the Unpredictable which promotes a case management approach to supporting these kinds of knowledge workers.
Gawande also takes a close look at the construction industry. With hundreds of thousands of buildings across the country, and millions of people involved in putting them together and maintaining them, how has it come to be that we virtually never hear about building falling down? Buildings are, on the average, phenomenally safe, in spite of the complexity of modern infrastructure. He comes across something interesting:
It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks.
Once again I was struck by how similar this is to BPM: too often the process analysts want to write down what actions need to be taken, almost to the exclusion of the communications that are needed between the experts involved.
He spends some time talking about the failure of FEMA to respond to Hurricane Katrina. The centralized command-and-control organization was designed for complicated situations, and was unable to respond in a massively complex one.
The trouble was not lack of sympathy among top officials. It was a lack of understanding that, in the face of an extraordinarily complex problem, power needed to be pushed out of the center as far as possible.
He contrasts this to Walmart, which was able to respond effectively by concentrating on “setting goals, measuring process, and maintaining communications lines with employees at the front lines.” Complexity can not be removed from a situation, and it can not be broken down the way a complicated one can into discreet components. Instead, the way to handle complexity, is to put well trained knowledge workers in the proper place, and give them the latitude to get things done.
There is a whole lot more in the book about how checklists can be constructed, how they should not, how they work, how people often reject the idea of using checklists, and even why they are not liked in general. I hope that I have motivated the understanding that this book is not just about lists of “things to do”. Instead, it covers an important technique which should be part of any attempt to “get things right.”