Communication lessons from air disasters

I’ve always had a morbid fascination for air disasters.  (Don’t ask me why; I have no idea.)  I’m fascinated by shows such as Air Disasters, Why Planes Crash,  and Mayday: Air Disasters.  Whenever I hear about a plane going down, I’ll start thinking about what happened, clues, what might have caused it, and so on.  There are times when I think I should have gotten a job with the NTSB.

Greg Moore has some publications in which he talks about lessons learned from aircraft accidents; his book partially discusses these lessons.  He also has an excellent SQL Saturday presentation titled “Who’s Flying The Plane?” which talks about lessons learned from air disasters and how they can apply to IT.  Go check it out if you have a chance; Greg gives a great presentation!

For the purposes of this article, however, I want to concentrate on a particular topic: how communication — or, the lack of — either contributed to or was the root cause of a disaster.

Last night, I watched an episode of Air Disasters that talked about the plane crash that took the life of professional golfer Payne Stewart. The plane went down after the cabin depressurized (the cause of which was never determined), the crew became incapacitated, and the plane ran out of fuel. What made it interesting to me was that bad documentation might have been one of the contributing factors to the accident. After the cabin lost pressure, the crew likely consulted a checklist, as is standard procedure for nearly any cockpit activity or incident. The checklist was poorly written and unclear. What should have been the very first instruction was, “put on your oxygen mask.” It was not. By the time the crew got to that instruction, it was too late; they were overcome by hypoxia.

It reminded me of a tenet that I preach in my documentation presentation: if, in a step-by-step instruction, an instruction cannot be understood within a few seconds, it has failed.

I also remember another Air Disasters episode that focused on Avianca Flight 52.  In January of 1990, the plane, a Boeing 707 carrying 158 people, crashed on approach to Kennedy Airport in New York after running out of fuel, killing 73 people.  There were numerous communication issues during the flight.  Had any one of them been addressed, chances are the disaster never would have occurred.

How often have you been involved in some kind of activity where things were miscommunicated?  How well did those activities go?  I’m guessing that they didn’t go well.  How often have they happened when deadlines were approaching?  What was the mood of your organization?  I’ll guess that it was likely one of high stress and low morale.  And during that time, how smoothly did things go?  Probably not very.  I’ll bet that plenty of mistakes were made.

I’m painting this picture within a business environment.  Imagine what these conditions are like when people’s lives are at stake.

The number of disasters that have occurred from poor communication are countless; entire studies have been dedicated to the subject.  Indeed, numerous solutions and subcategories related to miscommunication have been devised.  The airline industry developed the process of crew resource management.  Extensive research has been done on the phenomenon known as groupthink.  Even simple measures such as checklists have been studied and implemented.

The moral of the story: good communication, including documentation, is critical. The consequences of it can have adverse effects. At best, bad communication can disrupt your business. At worst, it can cost lives.

Advertisement

Testing something? What’s the test plan?

Imagine if you will that you’ve been asked to test a product. The product could be anything — software, a car, a kitchen appliance, a piece of sports equipment, whatever. For the purposes of this article, we’ll say you’re working at some company, and you’ve been asked to test a piece of software.

You’re told to go into an application, and you’re given this instruction.

“Okay, test it and see if it works.”

That’s it.

How would you feel? Vague? Confused? Frustrated? Abandoned? All of the above? Something else?

Well, I, myself, have been put into this situation more times than I care to admit. It’s one of the most frustrating job situations I’ve ever been thrust into.

What, exactly, constitutes “see if it works”? I could simply start the application, see if it starts, and say, “okay, it works.” I suspect that that’s not what the people who make the request are looking for. Yet time and again, I get a request from a developer or a designer to test something, and that’s the only instruction I’m given.

And it’s frustrating like you wouldn’t believe.

What’s even more frustrating is when (not if) the application comes back with some kind of problem, and the people who asked you to test come back with, “you said you tested this! Why is this broken?”

Want to know why there’s so much friction between developers and QA personnel? This is a likely reason. This is something that definitely falls under my list of documentation pet peeves.

The fact is, if you develop a product, and you need to test it for functionality, you need to specify what it is you’re looking to test. You need to define — and spell out — what constitutes a “working product” from one that’s “defective.” Just because a car starts doesn’t mean it’s working. You still need to put it in gear, drive it, steer it, and make sure that it can stop.

If you are creating a product, you need to describe what parameters are required for it to pass testing. If you’re asking someone in quality control to test your product, provide the tester with guidelines as to what should be checked to ensure the product is functional. Better, provide him or her with a checklist to determine whether or not your product can be released. If you discover additional items that need to be tested, then update the checklist.

(If you want to know more about checklists, I highly recommend The Checklist Manifesto by Atul Gawande. It’s actually a surprisingly excellent read.)

So any time you release a product for testing, tell the testers what it is that constitutes a “good” product. Don’t just send it off with vague instructions to “make sure it works” and expect it to be tested. More often that not, that will result in a failed product — and defeat the entire purpose of why you’re looking to test it in the first place.

The checklist manifesto

Some time ago, I came up with a new presentation idea that I tentatively titled “The magic of checklists.”  The idea is to demonstrate how checklists can improve tasks in any organization.  I have a number of ideas regarding this presentation, and I’ll expand upon them in a future ‘blog article.

As preparation for this idea, I assigned myself some homework.  My friend, Greg Moore, recommended a book to read: The Checklist Manifesto by Atul Gawande.  I borrowed a copy from the local library and started reading.

The book (which I’m still reading) is turning out to be an excellent read: so much so that I’m considering purchasing my own copy, instead of just relying on the one I borrowed from the library.  (This way, I can use a highlighter and scribble my own notes in the book.). Yes, it reinforces my ideas about using a checklist to improve upon workplace tasks.  But I’m also discovering that there is so much more.  Reading this book has enlightened me on numerous ideas that had never occurred to me.

The book hits upon numerous concepts, each of which is worth an entire presentation in their own right.  Among them: the importance of communication, organizational structure, teamwork, crew/team resource management, keeping an open mind, empowering a team, following instructions, making adjustments, and doing the right thing.  (Since I’m not yet finished with the book, there are likely a number of other concepts I haven’t mentioned that I haven’t yet come across.). When I first picked up the book, my initial thought was, “how much can there be about a simple checklist?”  I’ve since learned that a checklist — any checklist, no matter how small — is not simple.  And while a checklist is an important tool, it is also a big part of an even bigger process.  All the ideas I listed several sentences ago are all part of that process.

I’d like to relay a story I came upon in the book.  David Lee Roth of Van Halen was famously known for canceling concerts if his instructions for leaving a bowl of M&Ms with the brown ones removed in the dressing room were not followed.  Many people — myself included — decried him for these seemingly cockamamie instructions.  However, there was a method to his madness.  It turned out that this was a test.  If that instruction hadn’t been followed, then it was possible that another critical instruction — like, say, installing bracing to ensure the stage didn’t collapse — had not been followed.  (And before you think instructions like these can’t be missed, they can, and they have — sometimes, with disastrous consequences.) It goes to show that there is always more to the story.

Once I finish reading this book and can organize my thoughts, I’ll put out another article and another presentation (hopefully, coming soon to a SQL Saturday near you).  In the meantime, I highly recommend this book.  Maybe it’ll change your perspective the way it has changed mine.