More on this book
Community
Kindle Notes & Highlights
It was hard to imagine having more experience and expertise than Major Hill, who had been the air corps’ chief of flight testing. Instead, they came up with an ingeniously simple approach: they created a pilot’s checklist.
Checklists seem to provide protection against such failures. They remind us of the minimum necessary steps and make them explicit. They not only offer the possibility of verification but also instill a kind of discipline of higher performance.
These checklists accomplished what checklists elsewhere have done, Pronovost observed. They helped with memory recall and clearly set out the minimum necessary steps in a process. He was surprised to discover how often even experienced personnel failed to grasp the importance of certain precautions.
checklists seem able to defend anyone, even the experienced, against failure in many more tasks than we realized. They provide a kind of cognitive net. They catch mental flaws inherent in all of us—flaws of memory and attention and thoroughness.
they presumably have limits, as well. So a key step is to identify which kinds of situations checklists can help with and which ones they can’t.
Simple problems, they note, are ones like baking a cake from a mix.
Complicated problems are ones like sending a rocket to the moon.
Complex problems are ones like raising a child.
We are besieged by simple problems.
Checklists can provide protection against such elementary errors.
The value of checklists for simple problems seems self-evident. But can they help avert failure when the problems combine everything from the simple to the complex?
how could they be sure that they had the right knowledge in hand? Second, how could they be sure that they were applying this knowledge correctly?
Along the right wall as we walked in was, O’Sullivan explained, the construction schedule. As I peered in close, I saw a line-by-line, day-by-day listing of every building task that needed to be accomplished, in what order, and when—the fifteenth-floor concrete pour on the thirteenth of the month, a steel delivery on the fourteenth, and so on. The schedule spread over multiple sheets. There was special color coding, with red items highlighting critical steps that had to be done before other steps could proceed. As each task was accomplished, a job supervisor reported to O’Sullivan, who then
...more
This highlight has been truncated due to consecutive passage length restrictions.
Furthermore, the people involved had to somehow determine whether the tilting indicated a serious construction defect. I was curious to know how they handled this question, for there was inevitable uncertainty. How could they know that the problem was just ordinary settling, that loading the steel frame would in fact level out the floor? As Rouillard acknowledged, “variances can occur.”
The medical way of dealing with such problems—with the inevitable nuances of an individual patient case—is to leave them to the expert’s individual judgment.
This approach has a flaw, however, O’Sullivan pointed out. Like a patient, a building involves multiple specialists—the sixteen trades. In the absence of a true Master Builder—a supreme, all-knowing expert with command of all existing knowledge—autonomy is a disaster. It produces only a cacophony of incompatible decisions and overlooked errors.
“submittal schedule.” It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another—on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward.
The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction—who had to share (or “submit”) particular kinds of information before the next steps could proceed.
The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted. So the submittal schedule made them talk.
In the face of the unknown—the always nagging uncertainty about whether, under complex circumstances, things will really be okay—the builders trusted in the power of communication. They didn’t believe in the wisdom of the single individual, of even an experienced engineer. They believed in the wisdom of the group, the wisdom of making sure that multiple pairs of eyes were on a problem and then letting the watchers decide what to do. Man is fallible, but maybe men are less so.
You have to resolve it, and to do that you have to make sure the critical people talk. So the computer also flags the issue for the submittal schedule printout and sends an e-mail to each of the parties who have to resolve it. There’s yet another program, called ProjectCenter, that allows anyone who has found a problem—even a frontline worker—to e-mail all the relevant parties, track progress, and make sure a check is added to the schedule to confirm that everyone has talked and resolved the matter.
The e-mail was also automatically sent to the main contractor and anyone else who might potentially be required to sign off. Each party was given three days to confirm that the proposed solution was okay. And everyone needed to confirm they’d communicated, since the time taken for even this small fix could change the entire sequence in which other things needed to be done.
we allow it based on trust in the ability of the experts to manage the complexities. They in turn know better than to rely on their individual abilities to get everything right. They trust instead in one set of checklists to make sure that simple steps are not missed or skipped and in another set to make sure that everyone talks through and resolves all the hard and unexpected problems. “The biggest cause of serious error in this business is a failure of communication,” O’Sullivan told me.
There is a particularly tantalizing aspect to the building industry’s strategy for getting things right in complex situations: it’s that it gives people power.
The philosophy is that you push the power of decision making out to the periphery and away from the center. You give people the room to adapt, based on their experience and expertise. All you ask is that they talk to one another and take responsibility. That is what works.
The trouble wasn’t a 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.
In other words, to handle this complex situation, they did not issue instructions. Conditions were too unpredictable and constantly changing. They worked on making sure people talked.
No, the real lesson is that under conditions of true complexity—where the knowledge required exceeds that of any individual and unpredictability reigns—efforts to dictate every step from the center will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either—that is anarchy. Instead, they require a seemingly contradictory mix of freedom and expectation—expectation to coordinate, for example, and also to measure progress toward common goals.
That routine requires balancing a number of virtues: freedom and discipline, craft and protocol, specialized ability and group collaboration. And for checklists to help achieve that balance, they have to take two almost opposing forms. They supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.
There must always be room for judgment, but judgment aided—and even enhanced—by procedure.
The checklist also included what they called a “team briefing.” The team members were supposed to stop and take a moment simply to talk with one another before proceeding—about how long the surgeon expected the operation to take, how much blood loss everyone should be prepared for, whether the patient had any risks or concerns the team should know about. Reznick had never heard about the demise of Master Builders, but he had gravitated intuitively toward the skyscraper solution—a mix of task and communication checks to manage the problem of proliferating complexity—and so had others, it turned
...more
the fourth killer—the unexpected—is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together—
Their insistence that people talk to one another about each case, at least just for a minute before starting, was basically a strategy to foster teamwork—a kind of team huddle, as it were.
The researchers called it an “activation phenomenon.” Giving people a chance to say something at the start seemed to activate their sense of participation and responsibility and their willingness to speak up.
I went to the library and pulled out a few articles on how flight checklists are made. As great as the construction-world checklists seemed to be, they were employed in projects that routinely take months to complete. In surgery, minutes matter. The problem of time seemed a serious limitation. But aviation had this challenge, too, and somehow pilots’ checklists met it.
There are good checklists and bad, Boorman explained. Bad checklists are vague and imprecise. They are too long; they are hard to use; they are 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. Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything—a checklist cannot fly
...more
Pilots nonetheless turn to their checklists for two reasons. First, they are trained to do so. They learn from the beginning of flight school that their memory and judgment are unreliable and that lives depend on their recognizing that fact. Second, the checklists have proved their worth—they work.
When you’re making a checklist, Boorman explained, you have a number of key decisions. You must define a clear pause point at which the checklist is supposed to be used (unless the moment is obvious, like when a warning light goes on or an engine fails). You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, 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
...more
The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.
you want to keep the list short by focusing on what he called “the killer items”—the steps that are most dangerous to skip and sometimes overlooked nonetheless.
The wording should be simple and exact, Boorman went on, and use the familiar language of the profession. Even the look of the checklist matters. Ideally, it should fit on one page. It should be free of clutter and unnecessary colors. It should use both uppercase and lowercase text for ease of reading. (He went so far as to recommend using a sans serif type like Helvetica.)
no matter how much thought we might put in, a checklist has to be tested in the real world, which is inevitably more complicated than expected. First drafts always fall apart, he said, and one needs to study how, make changes, and keep testing until the checklist works consistently.
The three checklists took no time at all—maybe thirty seconds each—plus maybe a minute for the briefing. The brevity was no accident, Boorman said. People had spent hours watching pilots try out early versions in simulators, timing them, refining them, paring them down to their most efficient essentials.
It was, I noticed, a READ-DO checklist—read it and do it—with only seven lines.
There were, however, all kinds of steps that the checklist had not specified—notifying the radio control tower that we had an emergency, for example, briefing the flight attendants, determining the safest nearby airport to land and have the cargo door inspected. I hadn’t done any of these yet. But Boorman had. The omissions were intentional, he explained. Although these are critical steps, experience had shown that professional pilots virtually never fail to perform them when necessary.
It is common to misconceive how checklists function in complex lines of work. They are not comprehensive how-to guides, whether for building a skyscraper or getting a plane out of trouble. 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.
What experts like Dan Boorman have recognized is that the reason for the delay is not usually laziness or unwillingness. The reason is more often that the necessary knowledge has not been translated into a simple, usable, and systematic form.
his team buckled down to the work of distilling the information into its practical essence. They drafted a revision to the standard checklists pilots use for polar flights. They sharpened, trimmed, and puzzled over pause points—how are pilots to know, for instance, whether an engine is failing because of icing instead of something else? Then his group tested the checklist with pilots in the simulator and found problems and fixed them and tested again.
This—distilling books into their essence—“do this” according to sivers
modify the checklists to fit into their usual procedures.
We tried to follow the lessons from aviation. We made it clearer. We made it speedier. We adopted mainly a DO-CONFIRM rather than a READ-DO format, to give people greater flexibility in performing their tasks while nonetheless having them stop at key points to confirm that critical steps have not been overlooked.
