I recently bought, read, thoroughly enjoyed and am now recommending Atul Gawande’s book, “The Checklist Manifesto“. In “the manifesto”, Gawande pulls examples from the medical field, construction, aviation and others to show how simple checklists, coupled with timely and effective teamwork, can vastly improve the quality and effectiveness of what we do; in some cases, literally making the difference between life or death.
I’m sharing some teaser quotes that I bookmarked during my read of “The Checklist Manifesto” because I think they are good at conveying some of the underlying principles that solution delivery professionals will find interesting, but mostly because I think they’ll push you toward giving the book a read yourself (click on the image to purchase through Amazon). While the snippets are neat, it’s the compelling, real-life stories in the book that bring those principles to life and make it such a great read.
I’ll also include a few words of my own around why the teaser quotes are relevant to business analysts and project professionals.
The Problem
Know-how and sophistication have increased remarkably across almost all our realms of endeavor, and as a result so has our struggle to deliver on them. You see it in the frequent mistakes authorities make when hurricanes or tornadoes or other disasters hit. You see it in the 36 percent increase between 2004 and 2007 in lawsuits against attorneys for legal mistakes—the most common being simple administrative errors, like missed calendar dates and clerical screw ups, as well as errors in applying the law. You see it in flawed software design, in foreign intelligence failures, in our tottering banks—in fact, in almost any endeavor requiring mastery of complexity and of large amounts of knowledge. Avoidable failures are common and persistent, not to mention demoralizing and frustrating, across many fields—from medicine to finance, business to government. And the reason is increasingly evident: the volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably. Knowledge has both saved us and burdened us.
Essentially, the old paradigms aren’t working when it comes to addressing the complexity of many of today’s problems. With regard to business solutions, I think we’re seeing this evidenced by our quest for “agility” and in the mind shift away from processes that attempt to handle software and systems solutions as “assembly line”-type activities.
Simple Checklists help eliminate “stupid” mistakes:
Substantial parts of what software designers, financial managers, firefighters, police officers, lawyers, and most certainly clinicians do are now too complex for them to carry out reliably from memory alone. [Checklists] 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. [P]eople can lull themselves into skipping steps even when they remember them. In complex processes, after all, certain steps don’t always matter. Perhaps the elevator controls on airplanes are usually unlocked and a check is pointless most of the time. Perhaps measuring all four vital signs uncovers a worrisome issue in only one out of fifty patients. “This has never been a problem before,” people say. Until one day it is.
I think this is the essence of the book. Basically, checklists aren’t the proverbial “silver bullet”. What they do is free us to focus on the hard, complex issues without worry of overlooking the “stupid” mistakes which can be easily overlooked when we’re trying to keep up with so many variables and dependencies in delivering solutions.
To best address problems and risks associated with complexity:
Decentralized decision making
[U]nder 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. 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.
Think “empowered teams”. Take away almost all the other “stuff” associated with agile (or any other type of) delivery methodologies, and the essence is this: Get a group of smart, motivated people together, let them agree to whatever conventions they think they need in terms of planning/process/ceremony, and, for the most part, get out of the way and let them deliver, and you have a good chance at success.
Cross-functional collaboration and effective communication
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.
The examples given in the book were around the lead surgeon and the master builder; individuals who, historically, would almost, if not entirely single-handedly make and execute the key decisions with a largely subordinate cast of supporting characters.
Nowadays, complexity and super-specialization has given us circumstances where one person – even a remarkably gifted and high-performing individual – cannot possibly know enough about everything for the “single superstar” model to be sufficient anymore. That’s why we’re seeing such an emphasis on cross-functional teams of members with (largely) equal voices.
Bottom Line…
[Checklists] 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.
Recap
As I alluded to in some of my comments above, what I found particularly interesting, are the similarities between Gawande’s recommendations around basic checklists and collaboration as a means of addressing problems of scale and complexity and the agile principles that we find becoming more and more popular for addressing the same in software/systems delivery methodology.
If you’re not sure if you want to buy the book yet, have a look at this article which served as the precursor for the book, and provides an amazing example of “checklist” principles at work.
If you’ve read the book, please share your impressions with me below. I’d love to carry on the dialog!
Comments