Atul Gawande is a surgeon who was part of a group sponsored by the World
Health Organization to improve surgery by developing and promoting a
checklist to improve surgical outcomes. The project
was successful in reducing complications and increasing survival rates
in every hospital in which it has been used. This book is about developing the
checklist and the research that went into it.
divides errors into two distinct types of errors: ignorance (thing we
don't know) and ineptitude (things we do know, but
don't think about). Many of the reasons for failure are due to the
second type of error. The humble checklist is the tool to keep us from
committing errors of ineptitude. The only way to eliminate errors of
ignorance is to recognize that we don't know everything
and, in fact, we do not know much of anything.
As engineers, we deal
with complex problems of design to meet requirements of specifications
and agency requirements. Almost all of the time we can create designs
that meet the requirements, but sometimes we fail. Most failures, in my experience, fall within the area of
interfacing with other engineers and programmers or are memory-related.. A checklist, used properly, can help to avoid these kinds of failures.
This relatively thin
book covers the various types and uses of checklists by giving examples in the areas of civil engineering, aviation, restaurants, and,
of course, surgery. In addition it provides a detailed
look at the development of a checklist for use in surgery, with examples on how a checklist
is designed, tested, and adapted for use.
The section on the
aviation checklists provides useful information on how to design real-world
checklists. If you need more information in this
area, the bibliography provides references that cover this
topic in more detail.
One example used in
civil engineering is a checklist that consists solely of the names of people who need to be informed of
problems and need to sign off on solutions. This is an excellent and non-obvious use of a checklist: to promote communication
between interested parties and ensure that information is shared.
The book is a riveting read and hard to put down, and it gave me some great insights into my own processes. Currently when I start a
design, I have a list of specifications that the design has to meet,
both regulatory requirements and customer-supplied specifications. Most
of these are hammered out in meetings with the
customer's representatives. Some of these requirements are generated by
me from a general statement of what the customer wants or a detailed
requirement submitted by the customer. The final statement of work acts
as, well, a checklist.
Radcliffe Cutshaw is a creative private consultant in the areas of RF design and RF development and wireless. He is also involved with writing.
Making a check list goes a long way, not only in our day-to-day life, but in our professional life, as engineers. The check-list strategy during hardware/software/firmware designing & the check-list prepared for product testing vis-a-vis the product specification go a long way to help us.
I have experienced this more that often & when a check-list has not been diligently made by me, I have been at the receiving end of quite some flaks, besides the dissatisfaction felt.
Checklists are for sure a very important part of critical tasks. I only might add that they need to distributed through out the workflow in a timely way. There is little value in going over a 50 page checklist at tape-out which starts with items that should have been done at design start or during intermediate design reviews. If they are incorporated as part of the day to day task, they become second nature. They also need to be qualified with if-then options to guide the decision making otherwise they tend to be skipped with 'not applicable to me' shortcuts sometimes with disastrous effects.
I can vouch for checklists.
A flight check list caused me to find a large tool left by a mechanic in the engine compartment of a single engine plane I was going to fly. Who knows what damage it could have caused once I was airborne.
Years ago when doing design I used a master engineering DIDJADO list, from which those items appropriate for my project became the project didjado list.
However, a list is just as good as the thought that goes into its creation and use.
I too have found that checklists can save the day more often than not. A byproduct of good checklists being used was time savings. When was the last time you went on a camping or hiking trip? Thinking about all the things needed the night before may work well but all too often important items are forgotten (sun screen/bug spray). I started using lists for camping, hiking, home renovations, and projects at work; all in the interest on not missing something. It has worked well and saved time, money, aggravation, cost very little time to generate and checkoff. A good and basic tool that everyone should use.
In a prior article (Build checklists for embedded software projects, 7/9/2008), the author refers to a 1956 study that stated that most people can remember seven items, plus or minus two. I'm not sure how accurately that fits with routine repeated actions, like publishing a software release, but the concept will still apply regardless of what the actual number is. There are just too many details to reliably keep in your head. And, if a particular project has a few steps that vary from the norm, the checklist is even more vital.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.