The IT worst case scenario survival guide
IT is a risky business. Here's how to avoid some common catastrophes and increase your chances of success
You’re lost in the IT wilderness, starved for funding and thirsting for recognition. As the infrastructure sinks slowly under your feet, alligators crawl out of their corner offices to snap at your heels and marketing weasels begin gnawing at your flesh ...
When you’re that far up the proverbial creek, and neither bailing out nor soldiering on seem like workable options, it’s easy to imagine that no one else in IT has ever been in such an impossible situation.
You’d be wrong about that. According to research by The Standish Group, one out of five IT projects fail outright, and more than half come in late or over budget. Why? The standard answer from the business side, “It’s IT’s fault,” conveniently ignores equally likely causes: bad requirements management, poor business planning, lousy communication, or the dreaded “scope creep.”
Here, we’ve identified five of the most common scenarios in which projects fail and what IT can do to avoid them. The stories you are about to read are true, although company names have been obscured to protect the guilty. Some date from the technology-at-any-cost ‘90s, while others are ripped from today’s headlines. But their lessons are timeless.
Scenario 1: Outsourcing run amok
Back in the mid-’90s, a large vending machine services firm wanted to save money by centralizing its operations, so it hired a Big Five consultant to implement a $20 million ERP system. Big mistake.
“Turns out, the consultant’s dream was to build a management information system from scratch because he thought he knew how to do it better than anybody else,” says Bob Price, former CEO of Control Data and author of The Eye for Innovation: Recognizing Possibilities and Managing the Creative Enterprise (Yale University Press, 2005). The result was a near total meltdown. Prices in the ERP system didn’t match those in the catalog, so customers refused to pay. The centralized system made it too expensive to collect from individual buyers, so revenues dropped. Midlevel managers who were never consulted about the system revolted and left in droves. The firm’s president lost his job over the fiasco, and his boss, the CEO of the firm’s parent company, ultimately resigned.
What do you do if the consultant you thought was a godsend turns into Godzilla?
1. Assess your internal talent. Nobody in the organization really understood the project, leaving the consultant totally in charge. If you don’t have the necessary expertise in house -- or are unable to hire it -- don’t take on the project. “It’s better to do business in a poor way,” Price says, “than undertake something you don’t understand and end up not doing business at all.”
2. Match the solution to your business. In this case, the firm was trying to force fit a centralized structure on an extremely decentralized business model. It ultimately solved the problem by putting sales and inventory management back out in the field but handling customer data centrally.
3. Avoid proprietary technology. The ERP system was not only a custom job, it was written in an obscure version of ALGOL (Algorithmic Language) -- a programming language the consultant loved but nobody else knew how to use, according to Price.
