IT is not alone with Failure

Author: Yogi Schulz

With regularity, some consulting firm or other makes headlines with a report about IT project failures. Earlier this year, Boston Consulting Group reported only 41% of software projects were completed on time and on budget. While that number is up from a dismal 16% five years ago, no one is dancing in the streets yet.

So rather than make apologies for IT or suggest ways of improving this track record, I thought I’d look at the track record of major projects that ran into difficulty in other parts of our society. I believe that IT is performing just as well as other disciplines. Perhaps the problem is that IT is just newer, more active and being studied and reported more frequently.

The examples suggest that other disciplines struggle with the same issues that plague IT projects. They also suggest IT can learn from these examples.

Transportation

Airplanes

In Great Britain, engineers produced the first large commercial jet airliner, the de Havilland Comet. The Comet entered service in 1952 until two exploded in flight, killing everyone aboard. The pressurized cabin was exerting too much force on the plane’s metal skin. At high altitude, where the pressure differential is greatest, the plane’s body burst apart.

This example shows how inadequate engineering in a new situation can have devastating consequences. The engineers probably thought they were dealing with small increments of change on a manageable number of fronts. In fact, they were dealing with a new jet power source on a much larger and heavier airframe operating at a higher than ever before attempted altitude. When this many major new factors are in play, extra caution and extra testing are called for. IT professionals often forget the same point.

Air Florida flight 90 took off from Washington National Airport. Due to wing icing and pilot error, the aircraft lost altitude, bounced off the 14th Street Bridge and crashed into the Potomac River less than a mile from the airport. There were only 5 survivors out of 79 people on board. The aircraft descended nose-high and tail-low. The tail scraped the deck of the bridge, struck seven vehicles, killing 4 motorists before plunging into the frozen river.

In this case, a pilot blithely took off in a snowstorm when puzzling instrumentation readings and experience should have suggested extreme caution. IT professionals sometimes display the same cavalier attitude.

Automobiles

Edsel

The Ford Motor Company held grand ambitions for what became the Edsel as early as 1955. By 1957, Ford announced that the design of the Edsel would be far more radical than any of its other products and that equally radical sales and marketing techniques would be used to promote it. The Edsel was built from 1957 to 1960 and, as we all know, was colossal failure with the public.

To me, the story of the Edsel is one of incredible arrogance on the part of Ford management. They truly believed they knew better what the public wanted.

How many IT professionals believe they know better than the end-users in their organization?  Ford learned the lesson, listened to the marketplace and produced the wildly successful Mustang. Has IT learned the same lesson?

Corvair

The Chevrolet Corvair was GM’s first compact designed to satisfy people looking for a sturdy, practical car. The Corvair was produced from 1960 to 1969. Ralph Nader’s book “Unsafe at Any Speed” charged that GM deliberately concealed the tendency of 1960-63 model Corvairs to lose control and roll over when cornering, a problem that was not fixed until 1964. The settlement of Nader’s $2 million invasion of privacy suit against GM enabled him to fund the Public Interest Research Group (PIRG).

It’s unclear just how good or bad the Corvair really was. The vast network of Corvair aficionados, which exists to this day, creates some doubt about Nader’s charge. The message however, is that you have to manage your public and stakeholder communication very well. IT project managers neglect this task all too frequently.

Bridges

One of the earliest cast-iron bridges was the railway bridge over the Dee River in England. In 1847, three 108-foot spans of the twelve-span bridge collapsed under the weight of a passenger train. The bridge’s designer, Robert Stephenson, was so horrified by the accident that he set himself to devising a new, stronger mode of bridge construction.

On November 7, 1940, the first Tacoma Narrows suspension bridge collapsed due to wind-induced vibrations. Situated on the Tacoma Narrows in Puget Sound, near the city of Tacoma, Washington, the bridge had only been open for traffic a few months.

According to Paul Sibley of the University of London, a bridge collapses about every 30 years because engineers have asked too much of a given design. They’ve taken something that worked, made it lighter, less expensive, more elegant, until they’ve turned it into something that doesn’t work.

How many times has IT fallen into the same trap?  How many times have system architectures that don’t scale or aren’t appropriate for the application, been pressed into service nonetheless with disastrous results?

Panama Canal

In 1880 Ferdinand de Lesseps, the accomplished builder of the Suez Canal, organized a French company to build the Panama Canal. Construction started in 1882. By 1899, the French had been defeated by disease-carrying mosquitoes killing their workers and the inadequacy of their machinery.

This story is an example of how talented individuals, with a successful track record, can be blind-sided by something totally foreign to them. Ferdinand de Lesseps was blind-sided by a tiny mosquito, hardly something most managers think about.

The ascendancy of the web is a good example of something that blind-sided many IT professionals. Who would have thought that graphics and content analysts would find their way onto an IT project team?

Trains

On June 3, 1998, an Inter City Express passenger train traveling at 125 m.p.h. crashed into the support pier of an overpass near Eschede, Germany, killing 98. The likely cause of the crash was a defective wheel.

Discovery.ca reports that train accidents are common occurrences all over the world. About 1,400 rail workers, passengers, motorists and trespassers were killed in train accidents in 1996. This compares to 175 people killed in U.S. airplane accidents in 1995. Some train crashes are caused by communication gaps while others, and the most common, are collisions between trains and cars.

The lesson is that management of operations deserves as much attention as product development because failure can be just as disastrous. How much attention does IT management pay to infrastructure issues?

Space Exploration

Mars Missions

In 1993, the $1 billion Mars Observer suddenly disappeared just three days before it was to begin orbiting the Red Planet. A four-month investigation subsequently determined that ruptured fuel lines were the most likely cause of an explosion.

On December 7, 1999, NASA abandoned all hope for the missing-in-action Mars Polar Lander. Engines controlling the final descent of the Mars Polar Lander might have shut off prematurely, sending the $165 million probe crashing to the planet’s surface.

Mars Polar Lander’s failure followed the embarrassing loss of its companion orbiting spacecraft, the Mars Climate Orbiter. Engineers discovered that a failure to convert English measurements into metric units caused the Orbiter to burn up in the atmosphere as it was beginning to circle the planet on September 23, 1999.

Critics have accused NASA of trying to do too much with too little money with its “faster, better, cheaper” approach to space flight. Under this new approach smaller, less expensive probes are launched more often than in the past.

NASA, just like IT, is continually pressured to do more with less. There is a point beyond which this is simply not possible. The results, for NASA and IT, will be inadequate quality at best or disaster at worst.

Space Shuttle

The first space shuttle, Columbia, made its maiden flight in April 1981. The space shuttle is a truly monumental engineering achievement because of its payload capacity and its re-usability. This achievement required incredible political will as well as engineering talent. A General Accounting Office study in 1976 assessed NASA’s Shuttle development plan. It concluded that the project would result in increased costs, schedule delays, and performance degradation that were not originally envisioned. The development plan, revised as the program fell behind schedule and took funding cuts, embodied such factors as reduced testing, compressed schedules, and concurrent development and production.

Does this sound familiar?  Like many IT professionals, NASA oversold capability and benefits. Later, when reality set in, embarrassment becomes rampant and heads roll.

The seven Challenger astronauts died tragically in the explosion of their spacecraft during the launch from the Kennedy Space Center on January 28, 1986. The explosion occurred 73 seconds into the flight as a result of a fuel leak in one of two solid rocket boosters that ignited the main liquid fuel tank. An O-ring, which was not designed to function at the low ambient temperature on the morning of the launch, caused the fuel leak.

In the rush to production, both NASA and IT tend to roll over identified risks; sometimes with tragic consequences.

These two events stand out most prominently in the minds of the public and sometimes overshadow the many dozens of flawless Space Shuttle missions that have occurred. The message to IT:  Try to solve small problems. Don’t ignore them and let them grow. Large problems will haunt you long after they’ve been solved.

Consumer Products

The New Products Showcase & Learning Center, Inc. maintains the most comprehensive display and inventory of successful and failed consumer products. Their collection of failed products receives many laughs. Table 1 describes some of the more hilarious examples.

What makes The New Products Showcase a successful business is that consumer product designers and marketers are keen to learn from the failure of others and do everything in their power to position new products for success.

I’m disappointed that IT professionals are only too eager to sweep ugly messes under the carpet as quickly as possible and move on. This approach may avoid confronting harsh realities but it slows learning and the rate of improvement among IT professionals and the organizations they want to support.

Doing Better

It’s encouraging to see that the success rate for software projects is improving. We can however, do better yet. We can learn from these examples from other disciplines to test our ideas carefully and to carefully investigate all possible areas of risk.

Remember, that the other disciplines don’t perform any better than us IT professionals even when their press claims they do.

Table 1. Failed Consumer Products.

If you want to see the pictures that accompany these and other failed consumer products, surf to:http://www.showlearn.com/productshowcase/hits_misses.htm

Note to editor: this list can be shortened if space is tight. The more fascinating/entertaining ones are at the top of the table.