A Review of Three Project Management Horror Stories and the Lessons We Can Learn From Them

In June 1997, Electronic Data Systems and SHL Systemhouse started work on a Canadian national firearm registration system. The original plan was for a small IT project that would cost taxpayers only $2 million -- $119 million for implementation which was to be offset by $117 million in licensing fees.

But then, politics got in the way. Pressure from the gun lobbyists and other interest groups resulted in more than 1,000 change orders in just the first two years. The changes involved having to interface with the computer systems of more than 50 agencies and since that integration wasn't part of the original contract, the government had to pay for all the extra work. By 2001, the costs had ballooned to $688 million, including $300 million for support.

But that wasn't the worst part. By 2001, the annual maintenance costs alone were running $75 million a year. A 2002 audit estimated that the program would wind up costing more than $1 billion by 2004 while generating revenue of only $140 million, giving rise to its nickname: "the billion-dollar boondoggle."

The Lesson Learned: Define your project scope and freeze specifications before the requests for changes get out of hand. Learn the how to control scope creep by utilizing change management in this article, Defining Project Scope.

In 1993, FoxMeyer Drugs was the fourth largest distributor of pharmaceuticals in the U.S., worth $5 billion. In an attempt to increase efficiency, FoxMeyer purchased a SAP system and a warehouse automation system and then hired Andersen Consulting to integrate and implement the two in what was supposed to be a $35 million project. By 1996, the company was bankrupt; it was eventually sold to a competitor for a mere $80 million.

The reasons for the failure are familiar. First, FoxMeyer set up an unrealistically aggressive time line -- the entire system was supposed to be implemented in 18 months. Second, the warehouse employees whose jobs were affected -- more accurately, threatened -- by the automated system were not supportive of the project, to say the least. After three existing warehouses were closed, the first warehouse to be automated was plagued by sabotage, with inventory damaged by workers and orders going unfilled.

Finally, the new system turned out to be less capable than the one it replaced: By 1994, the SAP system was processing only 10,000 orders a night, compared with 420,000 orders under the old mainframe. FoxMeyer also alleged that both Andersen and SAP used the automation project as a training tool for junior employees, rather than assigning their best workers to it.

In 1998, two years after filing for bankruptcy, FoxMeyer sued Andersen and SAP for $500 million each, claiming it had paid twice the estimate amount only to get the system in a quarter of the intended sites. The suits were settled and/or dismissed in 2004.

The Lesson Learned: A risk assessment is critical to the success of a project. Project Risk identification helps organizations identify significant risks, estimate their probability of occurring and evaluate the impact in terms of cost and time. Risk Management: Planning Ahead and Preventing Project Failure can help you avoid a horror story like FoxMeyer's.

Sainsbury's, the British supermarket giant, was determined to install an automated fulfillment system in its Waltham Point distribution center in Essex. Waltham Point was the distribution center for much of London and southeast England. The new barcode-based fulfillment system would increase efficiency and streamline operations. If it worked, that is.

Installed in 2003, the system promptly ran into what were then described as "horrendous" barcode reading errors. Regardless, in 2005 the company claimed the system was operating as intended. Two years later, the entire project was scrapped and Sainsbury wrote off $265,355 million in IT costs, enough to buy a lot of groceries.

The Lesson Learned: It is important to address problems as soon as they appear. With proper planning, project managers can handle problems as they arise, thus avoiding project failure.

As the adage goes, "he who learns from other's mistakes is truly wise." Commit these stories to your memory, or better still, bookmark this page, ponder over the lessons learned, and be prepared when you face a similar situation.