Hero of Flight 1549

Wow! What a feat to ditch an Airbus A320 safely in the Hudson River with no loss of life. As Miles Vorkosigan is wont to say, luck favors the prepared:

• An experienced pilot and recognized safety expert with a trained crew
  
• An aircraft designed to stay afloat
• A very wide river near the airport to ditch in
• Commercial ferries and emergency craft on the scene quickly to rescue passengers
• Ferry crews that "routinely train for all types of river emergencies."
• Passengers who had just been briefed before takeoff on emergency procedures

This reader comment at the Wall Street Journal pretty well sums it up:

The pilot, co-pilot, attendants, the controllers, the teams of rescue workers, the trainers - simulators for pilot training, the manufacturer are all the heros in this event - everyone played a role and the passengers, people on the ground and the families of all were spared a real tragedy today. Thank the Lord we have dedicated, well-trained people in many walks of life - without them, life would be very difficult for many of us.

Comment by Jim - January 15, 2009 at 11:45 pm

The Smoking Gun shares the resume of Capt Sullennberger (h/t Drudge).

Cross-posted at RareKate Writes.

Why Ask Why?

The standard questions every cub reporter learns to ask are: who, what, where, when, why, how, and how much. With these tools, the reporter can get answers to describe almost any situation. And the analyst can describe any system. The "who, what, where, when, and how much" questions tend to elicit quantitative answers, namely specific people, things, places, times, and amounts. Not surprisingly, these tend to be the easiest questions to answer: "Just the facts, ma'am."

"How" is useful because it looks at processes by which things get done. How do you get from Point A to Point B? How do you manufacture widgets? How do you fill out this form? How do you fix a hole in a bucket? "How" reveals methods, tools, subsystems and timing required to achieve some goal.

Yet, I think that "Why" is the most profound question. Certainly it can be the most embarrassing--just ask a toddler's parent! "Why" is unique among the questioning words because it's the only one that digs into reasons, attitudes, beliefs, values, and rules governing a situation. It's an uncomfortable question, because we are forced to examine our motives and rationales for the system under study, sometimes for the first time. Why do you do this this way? Why do you do this at all?

When the story is some process you're trying to analyze, most of the W's will yield clear-cut answers: only Why begs you to go below the surface to discover meaning behind the process. Why will help you uncover the operating assumptions, the legal and regulatory bases, past practices, and corporate mythology underlying the process as it exists today.

Sometimes, people back into the "Why" question.

Corning Glass Works had been working to instill the TQM paradigm for several years. The group that does the taxes decided to see where they could make improvements in their products, to make it easier to "delight the customer", namely the IRS. One task they did was to prepare a summary of expenses. This task took more than 400 work hours each year: any improvement would mean major savings.

Rather than dive into improving the existing process, they decided to talk to their customer about what they (the IRS) wanted in Corning's tax returns. Obviously, there are legal and regulatory requirements about filing tax returns. But there is also more than one way to organize the information in the return.

Corning discovered that the IRS, in its biannual audits, spent many man-months decoding the returns. Why had Corning been doing the summary? Because they had assumed that's what the IRS wanted. By questioning the rationale behind the process, Corning and the IRS came to an amicable agreement on what was really wanted, and both organizations saved time, effort, and money!

Corning probably discovered that the expense summary had originally been done for one of three reasons: (a) someone thought some regulation required it; (b) once upon a time the IRS really did ask for it that way; or (c) it was a holdover from an antique accounting system. But regulations, technology, supporting processes and customer expectations do change over time. The trick is to adapt appropriately.

The answer "We've always done it that way" indicates lost corporate knowledge about the origins of a process or system. The good news is that you don't have to understand all the details of what was state-of-the-art during the War of 1812. What you do need to discover is what your customer's real needs are, and what the current environment's rules, regulations, and expectations are. Without that knowledge, it's impossible to make safe, effective change.

Deming preaches the gospel of continuous improvement (assuming that the process is under control). I admit that's well and good, but every so often we should step back and ask questions like:

• "Why are we doing it in this particular way?"
• "Why are we doing it at all?"

Time marches on, and as it goes, much changes: technology, legislation, customers, work force, industry practices. What was a satisficing solution some time ago may no longer be viable, despite those continuous improvements. Or it may still be the best way to go.

Modern Towers of Babel

In the Hebrew Bible* there's a story about a ambitious construction project that went awry (Genesis 11: 1-9):

1. And the whole earth was of one language, and of one speech.
2. And it came to pass, as they journeyed from the east, that they found a plain in the land of Shinar; and they dwelt there.
3. And they said one to another, Go to, let us make brick, and burn them thoroughly. And they had brick for stone, and slime had they for morter.
4. And they said, Go to, let us build us a city and a tower, whose top may reach unto heaven; and let us make us a name, lest we be scattered abroad upon the face of the whole earth.
5. And the LORD came down to see the city and the tower, which the children of men builded.
6. And the LORD said, Behold, the people is one, and they have all one language; and this they begin to do: and now nothing will be restrained from them, which they have imagined to do.
7. Go to, let us go down, and there confound their language, that they may not understand one another's speech.
8. So the LORD scattered them abroad from thence upon the face of all the earth: and they left off to build the city.
9. Therefore is the name of it called Babel; because the LORD did there confound the language of all the earth: and from thence did the LORD scatter them abroad upon the face of all the earth.

Is that a little hard for you to understand? Yes, it's English, but from the King James Version of the Bible. That dates from 1611, almost 400 years ago!

Our language is indeed "confounded", but communicating is hard not just because we may speak different languages or have atrocious accents. It's also hard due to the meaning we attach to the words and phrases based on our culture, education, and experience.

There is a tendency for groups to develop their own jargon, acronyms, and idioms to convey meaning quickly to others within the group. Bureaucracies of all kinds are notorious for their acronyms, whether governmental, military, or corporate. Long-established programs also develop their own patois, confusing anyone new.

One way to thwart Murphy's Law is to ensure that people are communicating effectively. Any time “everyone knows” something, I guarantee someone won’t think that way. Any time “it’s obvious”, it’s not always the case.

Jargon is a common obstacle to clear communications. It's a communications short-cut, terminology with group-specific usage and meaning. Jargon includes:

• Acronyms
• Project group-speak
• Technical or industry terminology
• Culture-specific references, e.g. "good Samaritan"
• Slang and idioms

Acronyms often mean quite different things to different groups, even within the same organization:

• DDG = "drop dead gorgeous" or "dreadnaught destroyer guided missile"
• MIW = "man-in-water" or "mine interdiction warfare"
• RAM = "radar absorbent material" or "reliability, availability, maintainability"

Even if everyone translates an acronym the same way, you still need to be careful.

I sat through a meeting one day where we were trying to make sure everything was covered to bring an airplane on-line to support our testing. Naturally, the Federal Aviation Administration (FAA) has rules and regulations about aircraft safety and airworthiness, which require aircraft to go through a certification process.

We all agreed that there needed to be an FAA cert, but a heated conversation ensued when two factions disagreed on the already-scheduled dates for the certification inspection. After a while, I realized that they were talking about two different cert efforts, and pointed out that little fact to the group. Oh, they said.

We had assumed that we were talking about the same “FAA certification”, when there were actually two different events: one for the airframe with the test equipment installed, and one for the electronics. Group-speak almost got the better of us.

I became sensitive to the problem of cultural allusions when I used "walk on water" with a non-Christian and a reference to Greek mythology with a native of Taiwan. Both instances were during conversations, so I was able to elaborate when they asked what I meant. In written communications, cultural allusions are okay so long as you leave clues about meaning, e.g. "He's as vain as Adonis" rather than "He's a real Adonis."

Diversity is a big buzzword in the business world, but it has a major downside when trying to get people from different backgrounds, cultures, and companies to communicate with each other. As our workforce and society becomes ever more culturally diverse, we must remember to make the effort to ensure our reader or listener understands us as we intend, lest we fail like the builders in Babel.

* also known as the Old Testament

Milestone for Mr. Murphy

It's been 60 years since Mr. Murphy was credited with the "law" that bears his name: Whatever can go wrong, will go wrong.

Marcus Dunk wrote a nice tribute to the US Air Force safety engineer in yesterday's Daily Mail:

Born in 1918, Murphy was the eldest of five children and attended the prestigious United States Military Academy, West Point, from which he graduated in 1940. He was immediately commissioned into the army Air Corps, and during the Second World War saw action against the Japanese in China and Burma.

A fine and conscientious pilot who was often described as 'no-nonsense', Murphy decided after the war to involve himself in the technological aspects of aircraft design, and went to work as a research and development officer for the Air Force.

[...]

For Murphy himself, the law and its variations to which he gave his name was the cause of great annoyance. While he preferred to see the law as a principle of good, defensive design - a willingness to be prepared for the worst - he regarded most versions of his Law as 'ridiculous, trivial and erroneous', and said as much before his death in 1990.

Although he may have failed to see the joke, he does have something of a point. While it is easy to label Murphy's Law as the ultimate pessimist's charter, there is an undercurrent of optimism running just beneath the surface of this Law, one that wryly acknowledges that although things will probably go wrong, recognising that fact is the first step in being prepared for when that actually happens. [emphasis added]

As any Scout would say, "Be prepared!"

My cousin Rob's corollary is that simply identifying the "possible" modes of failure reduces the chance of those failures occurring, both during testing and in use.

Dr. W. Edwards Deming, who preached the gospel of statistical process control (SPC), was adamant that you couldn't test quality into a product: it has to be built in. That principle is just as applicable to software projects as widget manufacturing.

For any development project, integration and test (I&T) is the phase where past sins, both technical and managerial, become apparent. Development schedules slip, squeezing testing, while system-of-system design flaws lay undiscovered until the whole product is assembled, leaving no time to recover.

If you expect the piece parts of your software or hardware system to come together smoothly during the I&T phase of your project, you really need to concentrate on identifying the factors that could go wrong during I&T and eliminate or mitigate their risks -- and do it early in the game.

In other words, it's good engineering practice to try and thwart Murphy's Law by eliminating things that can go wrong. Thank you Mr. Murphy!

[Originally posted at RareKate Writes]

Thwarting Murphy's Law!

Welcome to my new website and blog, where I'll be exploring ways to engineer out things that can go wrong with a system.

Topics are likely to include defensive design, project management, Lean Six Sigma, and system test. I'll be happy to take your suggestions and questions.