Deciding When to Kill the Project

"I will kill da wabbit!"—Elmer Fudd

Some projects are so poorly thought out, so ill-conceived (sometimes the major players are so full of themselves), that the project is destined for failure, regardless of what you do. Let' s face it, you' re only one individual, there are only so many hours in a day, and sometimes your best isn t good enough.

I' ve been unfortunate enough to have been involved in two of these kinds of projects (not as a PM, but as a team member). The environment brings everyone down; motivation and esprit de corps fade away; the project grinds slowly to a halt. You somehow know that you ' re on a bicycle going nowhere, but you try to keep peddling. Until one day the big cheese steps into the room, fires the contractors, and hands out reassignment sheets to the permanent employees. "I was wrong," he says. "One point two million dollars ' wrong."

If you' re the project manager, you are in the best position to recommend when to kill a project. You ' re also in the most difficult position, because if you decide to sound the bell too soon, you ' l l be known as the person who cried "Wolf!" If you warn leadership that chooses to ignore you, then you' re forced to manage a project you know is destined for failure. It' s very tough to rally yourself, let alone your troops, when you ' re in such a position. If you choose not to raise the possibility of killing and the sponsor pulls the plug, then you look like you didn' t know what you were doing. Worst of all, if you don 't say anything and the company keeps throwing buckets of money at a project designed to build a whale, you might wind up delivering a guppy.

It' s up to you to decide to pull the plug on the project. When a sponsor says that you must do so, your decision is easy. But how do you decide when it isn't so easy to see what call you should make? You have to use your common sense, your business acumen, and the variance numbers to tell you when a project has become unworkable. The variances might be your first clue that things are terribly awry. But it's also important to gauge the business worthiness of what you're trying to do. If your technicians are coming to you and telling you that they're having a hard time with this or that, and if they do this frequently enough on the same issue—extending the duration of the issue further and further out—that's your clue that you've got something unworkable in progress. Your deliverable is probably something experimental that needs to be solved in a research and development lab and not in this project, and you need to make the call to the sponsor.

Integrated systems are famous for this kind of problem. Typically, the integrated-systems problem arises when you already have a system in house that works fine for some business element. Management asks, "Why can't we couple some new software with our present system, thus solving the current business problem?" It's not the business idea of coupling two systems that creates a problem; its the actual coupling of those two systems that generates substantial technical hurdles—the integrated systems aspect of the idea. Unfortunately, business people don't understand the difficulty that integrated systems create (and lots of times, neither do PMs—especially nontechnical PMs), so you wind up in the middle of a project trying to make two (or more) systems talk to each other that really don't want to do so. In the middle of an expensive project, managers don't buy the excuse that "we can't do it because it's technically impossible, or very difficult," so you're simply told to figure it out.

This is a very tough problem for the PM, because she has to be a truth- teller, often in the face of managerial adversity—not a good position to be in. This is, I postulate, why PMs very often simply keep going down the project road and allow the project to die naturally. Unfortunately, this could be the kiss of death for a PM's career, and even (as I've personally observed) for the sponsor©s.

Note Extensible Markup Language (XML) might be the godsend for the integrated- systems problem. Using XML, a database can stay where it's at, on the platform it likes to live on. You then use application servers, such as Microsoft's BizTalk or WebLogic's WebLogic, to grab data out of the database and format it in XML so that it can be viewed by an ordinary browser. Using standardized protocols such as XML and Simple Object Access Protocol (SOAP), you may find that you can extract data from disparate sources and easily present them on a single browser page, eliminating the need for technicians to grapple with tremendously time-consuming and difficult integrated-systems components.

Was this article helpful?

0 0

Post a comment