When the IT project you management gets tagged “Top Priority,” you gain higher visibility in your company. Congratulations, and . . . gulp—right? Even in the most successfully planned projects, there’s always a hiccup. And these prove to be the best learning tools. Whatever you run in to, be glad you weren’t in charge of any of these project turkeys in our top IT project disasters list.
Here are four IT project disasters and the lessons we can learn from them.
IT Project Disaster #1: Air travel grounded, 2007
Back in 2007, some 17,000 international passengers were grounded at Los Angeles International Airport because of a software problem with the U.S. Customs and Border Protection Agency system. The cause: A network card that, instead of shutting down, persisted in sending incorrect data across the network, bringing everything to a standstill. During the eight-hour shutdown, no traveler could enter or leave the U.S. through LAX.
Project management lesson #1:
Don’t buy cheap parts for mission-critical systems.
Project management lesson #2:
Integrate risk management. Always create a back-up for when things go wrong.
IT Project Disaster #2: Airbus A380’s incompatible software, 2006
This issue could affect many IT projects—a case of when one software program doesn’t talk to another. This disaster hit the Airbus A380, one of the world’s largest aircraft and a European flagship industrial project. As the story goes, the French assembly line was using the latest version of the computer-aided design software (CATIA), while the German factory was using an outdated version. When Airbus workers tried to connect two sections of the aircraft, the wiring on one section did not match the wiring in the other, so the cables couldn’t link up without being changed. The issue put the project back at least a year.
PM Lesson #3:
Make sure key software programs are compatible.
PM Lesson #4:
Make sure everyone is using the same software version.
PM Lesson #5:
Project teams that cross borders will likely face national or cultural differences that affect project outcomes (as many have experienced in IT outsourcing). Anticipate this and have processes to gain clarity and precision among teams.
IT Project Disaster #3: The Y2K problem, 1999
Some millennial generation project managers might not recall this one, but 15 years ago the tech world went nuts about what would happen when the calendar rolled over from Dec. 31, 1999, to Jan. 1, 2000. Seems a bunch of legacy software had designated years by a two-digit number (the last two), so the year 2000 could not be differentiated from 1900. Huge sums were spent to avert the anticipated disaster, and the new millennium arrived without any consequences.
The expensive and frenetic efforts taken to avert the Millenium bug in the late 1990s worked. The problem here resided in the original error made decades earlier, when a year was represented with two digits a system that obviously wouldn’t work past 1999. No one thought ahead, or saw through the potential consequences of what seemed like a trivial matter at the time.
PM Lesson #6:
Sometimes the most trivial decisions have far-reaching effect.
PM Lesson #7:
Take time to ponder the long-term consequences if your project succeeds.
IT Project Disaster #4: World War 3 near-miss, 1983
This near-disaster makes the list because its consequences could have been so dire. This one goes back to the Cold War era in 1983, when the U.S. and the Soviet Union had massive installations of missiles (ICBMs) armed with nuclear payloads aimed at each other. The Soviet early warning system sent an alert, caused by a software bug, that the U.S. had launched five ballistic missiles. Fortunately, the Soviet duty officer, Stanislav Petrov, reasoned that if the U.S. were to attack, it would launch more than five missiles. He did not launch a counter-attack and is credited with avoiding a nuclear war.PM Lesson #8:
The best-designed system can go wrong; software bugs happen.
PM Lesson #9:
It’s not bad to insert a human decision into an apocalyptic process.
