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.

Assuming that your group is a team of IT auditors who have just got an assignment to audit information logging of servers of a company. You have known that logs are

important for information systems operation and security because logs can be used to detect unauthorized accessCase 1 Ford Motor Co.

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. Everest's 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, it's not hard to understand Ford's 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

2

as high as $150 million, kicking the project cost to $350 million. That's 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 AMR's 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 wasn't there, he notes.

Failing to attach spaghetti

Integration was another issue, according to Garban's Williams. 'It was immature. All the components they needed to do -- 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 Forrester's 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 CPM's Kapur. Ford's 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 company's financials and clients.

Consider Hewlett-Packard's 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

3

orders, angry suppliers, an internal shakeup and, according to HP, a direct hit on its third quarter numbers.

For sheer embarrassment, there was Hershey's 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 Ford's 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 doesn't 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.