The Dirty Half-Dozen

5. Uncooperative Business Partners

What can go wrong: Texas-based, drug distributor FoxMeyer filed for bankruptcy in 1996. The company partially blamed a failed ERP project and sued its software vendor, SAP, as well as Andersen Consulting (now Accenture). The case is pending. While the FoxMeyer case is extreme, most of today's sizeable IT projects involve a vendor of some sort - be it a software company, a system integrator, a consultancy or all of the above. When they're wooing you, those companies say they're your partner. They're not. No matter how much they want your project to succeed or how honourable their intentions, they have pressures of their own.

Moreover, within your business, "there's resistance and resentment over outsiders coming in and the money being paid to those outsiders. That is an impediment to sharing information", Portny says.

What you can do about it: First, try to negotiate a contract that minimises consultant turnover. Corporate IT pros who've worked with system integrators are painfully familiar with the bait-and-switch practice wherein the system integrator's "A Team" flies in for presales meetings and launch - then promptly hands the project off to a less experienced, and perhaps less skilled, crew.

And when working on that contract, DeMarco says, it's important to eschew take-no-prisoners negotiating and move instead toward a reasonable, achievable agreement. "There's this attitude today that the negotiating's not over until the other guy's screwed," he says. "This is foolish. These aren't adversaries, these are your partners."

Page Break

3. Poorly Defined or Changing Specs

What can go wrong: Some experts say that, along with lack of early input from stakeholders, this is the font of all IT project failures. "The requirements aren't well spec'd up front, and the project begins anyway. You've got no charter, no consensus among stakeholders," Keil explains.

In 1983, Alan Davis - now CEO at Omni-Vista, a Colorado Springs consultancy - was employed at another consultancy. "A telecom company hired us to assess a project," he says. "On the first day, I asked the project manager for a copy of the requirements spec. His answer was: ‘Which one? We have two. Marketing sold one to [the client], the development team is building the other one'."

What you can do about it: Once again, securing input from stakeholders is the key. "To define the problem, you've got to know who you're solving it for," Hoenig says. A long series of meetings and discussions up front will help build consensus on what an IT project can and cannot do.

Once the requirements are defined, project hygiene comes into play. Any schedule slips or requests for additional funds must be formally justified. "Senior management can help drive this stuff," says Matt Light, a research director at Gartner (US). "They can ensure there's organisational context, that project management is not going to happen in a slipshod manner."

(As for the project with two specs, Davis's team urged a full-disclosure sit-down between both companies' CEOs and the project manager. The consultancy begged for and received an extra year to complete the project.)

Page Break

6. Poor or Dishonest Communication

What can go wrong: Business communication alone could and in fact has launched enough books to fill an aisle at Dymock's. However, the problem is worse when IT is involved, simply because it's so hard for a layman to truly grasp the lingo. "There tends to be an overlap of buzzwords, so business and IT execs aren't speaking the same language - even though they think they are," says Margo Visitacion, a senior industry analyst with Giga Information Group.

Beyond tech-speak, many organisations suffer from the Mum or Deaf Effects: line workers don't want to be the bearers of bad news, and senior managers contrive not to hear that news if it is ever delivered. As a result, nobody sounds the alarm on IT projects that have "disaster" written all over them until it's too late. Georgia State University's Kiel believes many of the worst IT snafus of the past decade were caused by the Mum Effect.

What you can do about it: Experts offer some concrete ways to tackle the vexing communication problem. Hoenig suggests appointing two project managers - one whose forte is IT and one who is a business specialist - and making it the job of the latter to help the board understand what's going on.

And while it's easy to talk about having a culture that values open and honest communication, actually establishing one is tricky. One tool: "watchdog bonuses" for project workers who bring serious problems to your attention.

Don't hesitate to use your informal sources to learn how a project is really going. "An IT executive has got to know who the most important three to five people are [on a given project] and be in constant touch with them," Hoenig says. "Those people should be actively managing the key problems. Be suspicious if they say everything's fine."

In the end, perhaps the best advice comes from DeMarco: projects fail, he says, "not because the tasks are intellectually huge, but because they're engendered by an effort to transform the company". IT is used as the mechanism for that change, he adds, and makes a convenient scapegoat if things turn ugly. "When a project fails, it may look like IT failed - but it's almost always because organisational change failed," DeMarco says

Page Break

Six ways IT projects fail - and how you can avoid them.

Stop the presses: IT projects fail OK, so you knew technology initiatives have been giving corporations fits. You may have read some harrowing numbers: fewer than a third of IT projects (a lot less, some say) are completed on time, on budget and with the promised functionality. Today, IT is so tightly woven into the fabric of the organisation that technology projects, successful or otherwise, reflect on the entire senior management team. "Global financial companies are spending 20 per cent to 40 per cent of their revenues on IT," says Thornton May, chief awareness officer and corporate futurist at Massachusetts-based Guardent. "If your management team is not facile at managing it, your board is guilty of malfeasance."

With such high stakes, it's no wonder lawsuits are now a routine part of the IT landscape - especially where outsourcers and system integrators are concerned. "For the typical contract IT operation, the ongoing cost of litigation is part of the budget," says Tom DeMarco, principal of the Atlantic Systems Guild, a technology consultancy. DeMarco often serves as an expert witness in IT-related suits. To illustrate the magnitude of current IT-project litigation in the US, he recalls a recent visit to the headquarters of a large system integrator, which he declines to name. "It's working on maybe 75 cases," he says. DeMarco has estimated that businesses can spend up to 15 per cent of their IT budget on such litigation.

Another expert, Wayne Bennett, an attorney at Boston-based Bingham Dana who often handles major IT contracts, finds it harder to pin a price tag on IT disasters, partly because their effects are so broad. In addition to money paid to vendors, integrators and consultants, Bennett says, the major components of an IT failure are time ("You get two-thirds through a project and find you've wasted 18 months working on the wrong solution," he says) and opportunity cost - that is, the potential competitive advantage you've blown by not working on the right solution.

IT projects offer unique obstacles. "You're doing something with technology that often hasn't been proven," says Stanley Portny, a trainer, consultant and author based in New Jersey. "And IT projects tend to touch so many parts of the organisation that it's hard to appreciate how pervasive they are."

To avert disaster, make your IT projects manoeuvre around these landmines.

Page Break

1. Lack of Executive Sponsorship

What can go wrong: Large IT projects tend to cut across departments and force a lot of people to change the way they work every day. Such change, if not sold by senior management, can create fear. And don't kid yourself: every fearful middle manager in every department can create bureaucratic roadblocks that reduce the project's chance to succeed. "Sponsorship is not just a name tag," says Christopher Hoenig, CEO of US-based Exolve and author of The Problem Solving Journey. "You need to break through stovepipes."

The problem is that too many business executives view IT projects, such as ERP implementations, as mere (albeit expensive) technology challenges. "That's wrong," says Mark Keil, an associate professor of computer information systems at Georgia State University in Atlanta. "You've got to see ERP as an organisational change project of immense proportions."

What you can do about it: When getting a technology project off the ground, somebody must make it clear that departments need to share information they may have hoarded in the past. Somebody needs to explain that the pain will pay off. This is where you earn your paycheque.

A project's sponsor "needs to take a risk, be a visionary", says Jim Johnson, chairman of research and advisory company Standish Group International (US). "You have to support, understand, negotiate between parties. You have to almost be the fall guy," he says, when various parties - the CIO, users, a system integrator, board members - begin second-guessing and backbiting.

Page Break

2. Lack of Early Stakeholder Input

What can go wrong: Lack of user input was the factor most likely to correlate with a bad IT project, according to "Chaos: A Recipe for Success", a Standish Group report. In fact, it's important to discuss projects up front with everybody who has a stake in the outcome. That list may include not only users but customers, business partners and internal departments on whose cooperation a project's success depends.

Among IT types, "there's pressure not to identify all the key people needed to implement and support a project," says Portny, because of a well-founded fear that such measures will slow the project. Portny says he once consulted with a multinational bank that was launching a globalised IT system. When the bank's European branches received the "final" version of the new software, they found all data-entry forms were in English. Because each country had a liaison to bank's US headquarters - and those liaisons all spoke English - nobody had considered the language issue. That might not have been the case had someone thought to seek the input of data-entry departments. The gaffe cost millions, Portny says.

Information hoarding can be a hurdle too. Middle managers, suspicious that a new software program will shrink their fiefdoms, sometimes cling to information about the way their departments run.

What you can do about it: The senior management bully pulpit is your best weapon. You can explain the project's benefits and stress the importance of information sharing. Make sure three broad groups contribute before the project gets under way, says Hoenig: those who will be affected by it, those who will implement it and those who will pay for it.

Page Break

4. Unrealistic Expectations

What can go wrong: Estimating the time and resources a major project will require has long been the bane of IT. When the idea for an IT project is first floated, there's a tendency for each group of stakeholders to say: "Great! That'll solve our problem with such-and-such." Portny says business executives are especially susceptible to such a trap where IT is concerned: "People who are less knowledgeable about what the technology can really do create their own expectations - even fantasies."

Undefined expectations frequently lead to dreaded scope creep - in which an initially straightforward technology project is asked to solve more and more problems until it grows bloated and unmanageable. Scope creep, in turn, tends to flay schedules and eat up resources.

What you can do about it: A formal project management chartering process can do wonders for several of the problems on our list - especially when it comes to setting expectations and assigning resources, says Light. A central project office, he says, makes sure "no significant IT project is initiated without formal budgeting and formal risk assessment". That is all part of a movement toward what Light sees as new focus among senior management on "project hygiene - making sure the culture's in place for good project management discipline".

But in today's fluid environment, change is inevitable during the life of any large IT project. "Trying to nail down [every detail] to the nth degree is too big a task," says Standish Group's Johnson. "If you spend too much time on it, you screw yourself up." In an effort to help clients solve the problem, the Standish Group has been working on what it calls a microproject methodology, in which bare minimum requirements are defined early and the larger goal is broken up into smaller chunks. Under this methodology, conventional milestones are eliminated in favour of actual short-term deliverables. "A whole microproject shouldn't take more than three months," Johnson says. "And if it doesn't work, you throw it away so you can recover quickly."

Page Break

Know When to Fold 'Em

Disengaging from an IT project gone bad is similarly valuable - and thankless HOLLYWOOD SELDOM MAKES movies about them, but orderly retreats are revered by military men, who understand their difficulty and importance to the wider campaign. Disengaging from an IT project gone bad is similarly valuable - and thankless.

Loathsome though it may be, the best time to figure out what you'll do in a worst-case scenario is when you're planning the project itself. To ensure against runaway IT programs that acquire a life of their own, Mark Keil, an associate professor of computer information systems at Georgia State University in Atlanta, suggests thinking through the following antimilestones:

Define de-escalation trigger points. If cost or schedule overruns approach the triggers, hold a formal meeting to suggest alternate plans.

Define termination conditions. Define in advance the point at which you're throwing good money after bad. "Sure, it's a hard sell, but consider the alternative," Keil says.

Agree on an outsider. Whether an auditing company, a consultant or an academic, discuss on whom you'll call for an unbiased assessment should any of these unpleasant possibilities arise.