Lessons Learned: IT's Biggest Project Failures
Two Western states spent the 1990s attempting to computerize their departments of motor vehicles, only to abandon the projects after spending millions of dollars. First was California, which in 1987 embarked on a five-year, $27 million plan to develop a system for keeping track of the state's 31 million drivers' licenses and 38 million vehicle registrations. But the state solicited a bid from just one company and awarded the contract to Tandem Computers. With Tandem supplying the software, the state was locked into buying Tandem hardware as well, and in 1990, it purchased six computers at a cost of $11.9 million.
That same year, however, tests showed that the new system was slower than the one it was designed to replace. The state forged ahead, but in 1994, it was finally forced to abandon what the San Francisco Chronicle described as "an unworkable system that could not be fixed without the expenditure of millions more." In that May 1994 article, the Chronicle described it as a "failed $44 million computer project." In an August article, it was described as a $49 million project, suggesting that the project continued to cost money even after it was shut down. A state audit later concluded that the DMV had "violated numerous contracting laws and regulations."Lesson Learned
Regulations are there for a reason, especially ones that keep you from doing things like placing your future in the hands of one supplier.
Meanwhile, the state of Washington was going through its own nightmare with its License Application Mitigation Project (LAMP). Begun in 1990, LAMP was supposed to cost $16 million over five years and automate the state's vehicle registration and license renewal processes. By 1992, the projected cost had grown to $41.8 million; a year later, $51 million; by 1997, $67.5 million. Finally, it became apparent that not only was the cost of installing the system out of control, but it would also cost six times as much to run every year as the system it was replacing. Result: plug pulled, with $40 million spent for nothing.Lesson Learned
When a project is obviously doomed to failure, get out sooner rather than later.
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 an SAP system and a warehouse automation system and 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 to get the system in a quarter of the intended sites. The suits were settled and/or dismissed in 2004.Lesson Learned
No one plans to fail, but even so, make sure your operation can survive the failure of a project.
It's easy to forget these days just how desperate Apple Computer was during the 1990s. When Microsoft Windows 95 came out, it arrived with multitasking and dynamic memory allocation, neither of which was available in the existing Mac System 7. Copland was Apple's attempt to develop a new operating system in-house; actually begun in 1994, the new OS was intended to be released as System 8 in 1996.
Copland's development could be the poster child for feature creep. As the new OS came to dominate resource allocation within Apple, project managers began protecting their fiefdoms by pushing for their products to be incorporated into System 8. Apple did manage to get one developers' release out in late 1996, but it was wildly unstable and did little to increase anyone's confidence in the company.
Before another developer release could come out, Apple made the decision to cancel Copland and look outside for its new operating system; the outcome, of course, was the purchase of NeXT, which supplied the technology that became OS X.
Copland did not die in vain. Some of the technology seen in demos eventually turned up in OS X. And even before that, some Copland features wound up in System 8 and 9, including a multithreaded Finder that provided something like true preemptive multitasking.Lesson Learned
Project creep is a killer. Keep your project's goals focused.