How to Kill an Enterprise Project

There are few things as draining on an organization?in dollars and morale?as a project that has lived beyond its time. Loathe to admit defeat, companies rarely pull the plug on an ERP or CRM installation gone bad. In the meantime, any number of resources get sucked down the metaphorical drain?including, if you’re not careful, your job. As the CIO, you’re the head doctor on the ward. It’s up to you to determine which projects you can bandage and which you should put out of their misery.

If the thought of killing an expensive project makes your heart palpitate, there are steps you can take to minimize the discomfort. But before you can deep-six those doomed projects, you have to know how to identify them.

Your project is in trouble when you experience one or more of the following warning signs. One?your gut is rumbling. “Pay attention to what your noncognitive self is telling you,” says Eileen Strider, former CIO for insurance provider Universal Underwriter in Overland Park, Kan. Strider knows of what she speaks. In 1997, after one year and $1 million worth of patchwork solutions, she had to kill a policy administration and rating system project. “My gut knew way before my head knew,” she says. “Then my head had to figure out what really was going on.” Too often, CIOs rely on their intellect to see them through tough times. It’s instinctive to throw resources at problems as they pop up in the hopes that this time it will finally fix everything, but that’s part of the seduction. “It’s not like you aren’t paying attention,” says Strider. “It’s just hard to see clearly when you’re in the middle of it.”

Two?your project manager starts smoking cigarettes. While the warning signs probably aren’t as obvious as bad breath and tar-stained fingers, you can tell a lot about the state of your project by changes in your employees’ behavior. Johanna Rothman, a consultant for the Cutter Consortium in Arlington, Mass., who recently authored a report on evaluating projects, says you should constantly gauge your employees’ enthusiasm. “Are they excited about the project?” she asks. “If they are excited they will tell you stuff about it. Once they stop talking, you are in trouble.” A good way to gauge behavior is to go to the company cafeteria and join in?or just listen to?the lunchtime banter.

Three?the rumor mill is churning overtime. And it is probably right. If you hear that finance or HR or some other department is complaining about the parts of the project that relate to them, there probably is something to it.

Four?every day you learn something new about the software. Discoveries are normal at the beginning of a project, says Marie Benesh, who turned her experience as the project manager on one of the world’s first integrated ERP installations at Corning in 1995 into a career as a professional ERP project evaluator. It’s a bad sign if the problems keep coming after the first three months, particularly if you have to start reallocating people. “[In the beginning] I hear consistently that we didn’t realize we were going to have to do ABC,” says Benesh. “But if it happens [after the first few months], then you are probably changing the scope of the project midway through. And then you will never make the end.”

If some or all of the warning signs are there, it is time for action. Here’s what you can do. Take responsibility for everything that has gone wrong. That is probably the hardest thing to do since you are essentially putting your head on the chopping block, but it is also the only way to get your employees to tell you what really happened to your project. Strider stood up at a meeting of company executives and announced that the project failed and that it was entirely her fault, and then told her employees the same thing. Once you take responsibility, she says, your employees will tell you all their fears and failures. Otherwise they’ll be too scared of getting blamed to tell you what you need to know.

Do an analysis of the project to date. Don’t hide it from your employees; they know things aren’t right and will be just as relieved as you to find out why. That said, it is important to do it quickly?a review of a $50 million ERP project Benesh conducted for a Big 10 university took only two weeks. Talk to your vendor and contractors, but don’t let them stay onsite. Find someone who isn’t affiliated with the project (it could be someone from another department, it could be a consultant?just not you) to interview everyone who is.

If you can, kill it on a Wednesday. This way, says Rothman, your employees have the rest of the week to wrap up loose ends and salvage what they can, and then can come back to work the next week for a fresh start. “Don’t wind it down because people won’t wind down,” says Rothman. “If I get three weeks to wind down I start thinking maybe I can finish this.” Make the necessary layoffs and personnel changes right away and give everyone else something new to do immediately. If there isn’t a project to move on to, have them do research.

After you pull the plug, resist the temptation to sue your vendor. Unless you can find an example of gross negligence, it is probably just a waste of money. As every CIO knows, vendors write contracts that make themselves immune to liability. “It might be their fault,” says Strider, “but it takes two to tango.” Benesh says that the best bet is “to spill your guts to the vendor.” Most will go out of their way to avoid negative publicity, including providing experienced specialists to help if and when you start again.

Update your rŽsumŽ. If you follow our advice, you should make out all right. But it can’t hurt to to have a backup plan just in case.