October 4, 1999
|
Print this story |
continued....page 2 of 3
Hugh Ryan, partner and director of Andersen Consulting's large complex systems practice, says that when it comes to IT projects, there's often a misconception that if a system is built, it will be used regardless of efficacy. "But it's not that way," Ryan says. "You have to be able to quantify a project's value from the beginning, or what will ultimately happen is the business folks will press for delivery of what they want, at the cost they want, and when they want it, and the IT group is left scrambling to know where they stand."
Though Sun's implementation has been finished for a year, risk management continues. The company is working to ensure that the system continues to fulfill users' needs. Yang says Sun accomplishes this by using a court system, where any system user, via Sun's intranet, can log a case against the IT project leaders. Leaders are then summoned, and the case gets heard. If the IT staffers are ill-prepared to answer user complaints, they're told to return with proper documentation.
On Their Own
Because it's not dependent on technology for managing technology risks, Elf Atochem takes the old-fashioned approach: Rubin requires that when a project is proposed, the initiators come directly to him or the executive committee with a specific project proposal. "I want my people to estimate at 90% probability of accuracy what's the lowest possible cost and time I could get for this project and what the highest is."
Play It Safe
Like Rubin, Carlson Companies' Medina doesn't think project and risk-management methodologies offered by third-party consulting firms are the way to go. The problem with these approaches, he says, is that the methodology becomes king. "Consultants will always say, 'Our methodology will guarantee success.' If the project is a success, they point to the methodology as the reason; but if it fails, it's not the methodology's fault, it's the fault of those using it," Medina says.
For the replacement of a legacy voice-booking system for travel reservations that was part of a call-center upgrade project, Carlson determined risks based on the experience and common sense of Medina and his team. "The risk involved with doing the project was that if it didn't work there would be massive disruption in our worldwide travel system," Medina says. To alleviate this risk, Medina decided to tackle the project in chunks, leveraging the legacy system the whole way through, rather than trying to build a perfect system as a whole unit.
Illustration by Dave Calver
Battle Lines

Related links:
And from our sister publications:
Ongoing risk management was achieved through a disciplined method of reviews in a "war room," where project team leaders responsible for discrete parts of the implementation would report three times a week early on in the project and twice a day as the project was nearer to completion. "This prevented problems from sitting until they became unwieldy and cost more time and money to fix than they should have," Yang says. "The war room also helped us make all the project deliverables visible."
Not all companies ascribe to third-party risk management. Bob Rubin, CIO at chemicals manufacturer Elf Atochem North America Inc. in Philadelphia, says risk management is more good, old-fashioned common sense than anything else. The downfall of risk-management tools and services, he says, are the weighting factors assigned to each risk. "Ultimately, it's a judgment call because the risk factor of a new technology and how it relates to organizational change is what I as the business owner say it is."
Rubin then asks project leaders why a project was formulated in a particular way, how much business value depends on it, what could possibly go wrong, and what project managers will do if someone important quits. "The way to go about this is to explain that you're not trying to be mean, you just want to be sure that you run through the worst-case scenarios before they actually occur," he says. There's no place for "hope" in an IT implementation, Rubin says. Whenever someone uses the word hope, he says, be careful because that may mean they're looking too far ahead. The key is not to worry about meeting the final target on time, but simply trying to meet the next one.
Eighteen months ago, Rubin's methodology saved Elf Atochem from embarking on an SAP module to manage logistics relating to environmental safety by proving the product wasn't mature. The danger of working with an immature product: The time and attention it would need would be overwhelming because IT staff was already dedicated to implementing other SAP modules, Rubin says. Instead of going with the questionable SAP module, Elf Atochem decided to use a proprietary solution it had been using for years in another division and will reconsider the SAP module later when the company is ready to upgrade.
continued...page 3
return to page 1
Back to This Week's Issue
Send Us Your Feedback
Top of the Page
Lowe's seeking Systems Engineer III in Mooresville, NC
Univ of Michigan seeking University Ethical Hacker in Ann Arbor, MI
MAP Digital seeking Project Manager: Live Digital Events in New York, NY
cPanel Inc. seeking Internal Systems Developer in Houston, TX
Cirrus Design seeking Web Architect in Duluth, MN
For more great jobs, career-related news, features and services, please visit our Career Center.