REQUIRED Based solely on the information provided in the article, use the system development life cycle (SDLC) to analyze the case in terms of risks and controls. Specifically, identify controls and/or what Ford Co. should have done in each relevant SDLC phases that could have prevented and/or mitigated those risks. The bigger they come, the harder they fall. In late August, Ford Motor Co. abandoned its Herculean effort to reach the summit of its five-year Everest Web purchasing project, scattering nearly 350 IT staffers and an investment estimated to be as much as $400 million in its wake. As big development projects go, 'Neverest' was a monster. Conceived at the height of the e-commerce gold rush, the project was supposed to replace a collection of aging purchasing and procurement systems while eliminating paper, increasing speed and cutting costs. Neither Ford nor Oracle, its partner, is talking, but according to analysts, while cost may have sounded the death knell, the real killers were poor design, integration issues and IT sprawl. Analysts credit Ford with trying to do the right thing -- consolidate some 30 disparate purchasing and procurement systems into one Web-based system that would serve multiple tiers of suppliers. 'Margins in the automotive industry are so thin, if you can save a dollar in cost savings, it is $30 in revenue,' explains Mark Bunger, a senior analyst in the automotive research department at Forrester Research in San Francisco. Everests goal was procurement automation of costly manual processes. For example, 'with paper going back and forth, say an invoice is being disputed. If you have to pick up the phone, the processing cost will be $20 to $50 instead of the 50 cents it should cost you in administrative overhead,' he says. With those kinds of examples, its not hard to understand Fords bid to scale Everest. Project failed the so what test, What went wrong speaks to project management on several levels, not the least of which was controlling cost. Originally tagged at $200 million, Kevin Mixer, a research director at Boston-based AMR Corp. who has previous experience working with Ford and Oracle, says he heard the internal cost of the program ran as high as $150 million, kicking the project cost to $350 million. Thats in line with published reports estimating the cost as high as $400 million. In the first generation at least, Ford achieved its project goals. But the new system failed the so what test for its end users -- suppliers -- who were forced to enter through the Covisint portal and then marched through as many as five screens to find that they could not see all their data, says Richard Williams, director of research at Garban Institutional Equities in Jersey City, N.J. By running the legacy applications in parallel, suppliers had even less of an incentive to move over, notes AMRs Mixer. 'A lot of functionality was missing. Suppliers still had to go to some base system to look for specific pricing or volumes, and Ford had not completely cut over to the [new] system,' Mixer says, which forced users to propagate two environments. There needed to be a value proposition for the suppliers to adopt, and it wasnt there, he notes. Failing to attach spaghetti. Integration was another issue, according to Garbans Williams. 'It was immature. All the components they needed to do this -- CRM, app servers, security -- were not working together. It was like trying to attach spaghetti. It was a nightmare.' Indeed, this is one nightmare where the repercussions will be felt for years to come, according to at least one analyst. And the pain will be measured not just in the lost investment dollars of today, but in lost opportunity down the road. No one launches mega projects with the intent of achieving a one-to-one return, notes Gopal Kapur, president of the Center for Project Management (CPM), a consultancy in San Ramon, Calif. Most companies expect a 10 times or more return on their investment, he says. So when what Forresters Bunger calls 'death star' projects go down the tubes, they take with them not only the initial investment, but the future payoff. Worse, if the project is mission-critical enough that the company has to try again, and in this case analysts say Ford had the right idea, then you are looking at five more years of development work, followed by even more years of waiting to reap the expected ROI. If forced to start over, Ford could end up lagging years behind competitors like GM and Toyota on supply-chain issues, says CPMs Kapur. Fords current plan -- to revert to the very legacy systems that Everest was to replace and improve upon -- could have the same effect. Mega-projects destined to fail When it comes to transformational projects, the stakes are enormous and risky. Many analysts agree that roughly 40% of all development projects fail. The success rate is even lower for the largest multi-year projects. And the failure of just one piece of an enterprise-wide integration project can wreak almost immediate havoc with a companys financials and clients. Consider Hewlett-Packards ongoing effort to integrate several systems from its merger with Compaq Computer. After successfully consolidating some 70-odd apps, the effort tripped over the deployment of an order-processing system. The result? Messed up, orders, angry suppliers, an internal shakeup and, according to HP, a direct hit on its third quarter numbers. For sheer embarrassment, there was Hersheys ERP meltdown just in time for Halloween a few years back. For a project of that magnitude to coincide with the most profitable period of the year was stupidity of the first degree, says Kapur. He attributes that example of poor planning to what he calls unintelligent obedience. As for Ford, it has said little other than it will salvage some of the newly built capability from Everest and move its suppliers back to its legacy Ford Supplier Network system. The problem, however, is that Fords rationale for Everest makes it clear it did not think those systems were up to snuff. Questions to ask. When Ford does a postmortem on this project, analysts say it should ask: * Is the fallback plan -- the legacy systems -- really workable? If it is, then perhaps Ford needs to reassess some of its initial reasons for launching Everest. * Was the initial concept and scope of the project valid? Could the project have been structured in some other manner? Was the choice of software platform valid? Oracle is frequently criticized for its integration problems, and integration was a key to the success of this project. * What, if anything, can be salvaged? How did we end up with a system that frustrated the target audience? How can we ensure it doesnt re-occur? * How well did the validation process work? Many firms do big implementations without validating their assumptions. * Did we determine up-front stop gates and were they realistic? If yes, Ford might have canceled the project years earlier, saving money, credibility and goodwill. * Did we have the needed people and skills assigned to the project? * Where did the project management and portfolio management processes break down? Was it a tools or people issue? Were the sponsors effective? Is the project management methodology mature enough to handle large-scale projects? The idea is to not point fingers, says Margo Visitacion, an analyst with Forrester, who believes most projects fail because of a lack of communication. Ford will need to review its plan, celebrate the things it did right and correct the things it did wrong. If Ford can institutionalize those findings, its next attempt to scale supply-chain management may go smoother, faster and potentially yield the kind of long-term opportunities and ROI that its Everest failure has denied them.