IT is a risky business. Here's how to avoid some common catastrophes and increase your chance 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 company wanted to save money by centralizing its operations, so it hired a Big Five consultant to implement a $US20 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 catalogue, so customers refused to pay. The centralized system made it too expensive to collect from individual buyers, so revenues dropped. Mid-level 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.

4. Manage it closely. Even the most minutely detailed consulting agreements can't cover everything, especially as changes or clarifications are needed. Consultants can be very useful, Price says, but you need to state in no uncertain terms what you want them to do, and manage them very closely.

Scenario 2: The incredible expanding IT project

Three years ago, a large tech services company decided to roll out a Web-based content management system to handle its internal communications. But inexorably, the features list began to grow. Could they use the same system for customer support? Sure, said the systems integrator. How about selling research reports to clients? No problem. The budget for the project rapidly climbed to $100 million.

The catch? The systems integrator was also the software vendor who'd built the content management system. The vendor had never met a problem their software couldn't solve -- for millions in additional development fees, naturally.

"By the time they contacted us, the company had spent closer to $280 million, and the percentage of test cases that actually worked was zero," says George Kondrach, executive VP of Innodata Isogen, a content supply chain consultancy. Innodata recommended scaling down the project and bringing in third-party software to handle jobs the content management system wasn't designed to do. Kondrach says Innodata could have fixed the problems for about $10 million, but that would have meant the client would have had to admit failure. Instead, the client continues to spend millions each year trying to make the system work.