Whether they’re still in planning or halfway through development, some projects should just die. But how do you handle the delicate task of telling a client or the front office that a project should be terminated and still keep your job? Equal parts of diplomacy, analysis, and objectivity should do the trick, but only after you’re thoroughly convinced that such a drastic option is the right course of action.
Why kill a project?
When should you kill a project? Read “Six reasons to kill a project” to find out.
Abandon all hope
So, you’ve come to realize that the project you’re working on is a lost cause. Perhaps you’ll never recover the cost of building the software, or you’ve already exhausted the budget, or your solution is obsolete—any number of things could deliver the deathblow. All that’s left to do is to break the bad news.
Of course, you could follow Dilbert’s cue and handle the situation the “weasel way” by just riding things out, but that’s hardly serious advice for those of us in the real world. It’s your responsibility to inform your boss that it’s time to pull the plug.
Before you begin walking towards that door at the end of the hall, start building your case. Like any good lawyer, you’re going to need a lot of evidence to back up what you say. Charts, budget sheets, testimonials, articles from news Web sites—anything that helps support your point is good to have at your fingertips.
Not only will this information help you clearly describe the problem, you may actually find something that could help you recover the project. If that’s the case, you could end up offering a mad scheme to save the project instead of bad news about the need to shut it down. That won’t happen very often, and you still could find yourself without any alternative. But it’s important to consider alternatives.
Breaking the news
No matter what the situation, you should break the news gently. You must avoid a knee-jerk reaction to help keep the conversation on a calm, rational level. Whether you thought the project was a bad idea from the beginning or it’s been your “baby,” you should be completely convinced that dissolving the project is the best way to go. Any doubt will lead to a weak presentation, and you may end up wishing you’d never brought it up.
To emphasize the importance of your announcement, set up a meeting with the unlucky attendee, even if it will only be the two of you. When you get there, don’t just blurt out “the XYZ project is killing us and needs to go away.” It’s important to be direct, but if you don’t offer some kind of background information, you’ll be putting yourself on the defensive and shaving credibility off of your argument.
Instead, start off by saying that you need to discuss the project. Then briefly outline the details that support your claim, stating that these issues have come to your attention, and that an evaluation of the project’s future would be prudent. You might want to mention budget projections, competitors’ products, or any other information that illustrates the severity of the situation. This approach sets the stage for the inevitable bombshell.
Next, lead into the big news with a statement about how the project is affecting the company. If you’re considering killing a project, it’s most likely due to the serious repercussions of not killing it. You can soften the blow by first describing what your team has done to get the project back on track, and then mentioning the terrible troubles that failure is causing.
Finally, break the news. Lay your reasoning out on the table, and bolster it with the material you gathered before the meeting. Make your recommendations clear. If you present your case well, the project driver will agree with you.
Don’t leave them hanging
If you’re planning to recommend terminating a project, it’s wise to offer it as one of at least two possible solutions, even if you don’t see any other options. Make clear the implications of just continuing with things as they are. Put some forethought into costs, deadlines, and the required scope. Consider the big picture. For example, just because a project is a failure doesn’t mean that the need for that software has gone away. Remember to consider the cleanup and transition work that will be required.
Hopefully you’ve reached a decision on the project before it’s impossible to pursue other options. Even if you’re past the point of no return, it’s irresponsible to dismiss the up-front evaluation that created the project in the first place. If you don’t offer alternatives, none will be selected, and you may be forced to continue with the doomed project. You don’t necessarily have to come up with a definitive plan of action, but you should expect to be asked how to accomplish the intended solution. You should at least research and present possible scenarios for moving forward—sometimes even a bad idea is better than no idea.
Doomed to failure
Even with your strongest recommendation, you may have to accept the fact that the project isn’t going away. You need to consider the matter from the perspective of the decision makers. Sometimes financial losses are acceptable risks in the grander scheme of things. Often the people who initiated the project are the ones holding the purse strings. Making sacrifices in order to continue a moribund project is a decision that you won’t get to make.
If you think your views won’t be well received, continuing to work on what you think is a fruitless endeavor won’t come as a shock. In any case, at least you’ve aired your opinions, and you might have succeeded in lowering expectations. If you’re afraid of becoming a scapegoat, you might have to act on your convictions and transfer elsewhere, but if you do stick with the project, you must do your best to make it succeed, even if it seems impossible. On the upside, you may find an enlightened individual who sees the point you’re making, and who understands that the project can’t continue.
You can’t give up on the project without the official say-so, but at least you’ll have the comforting knowledge that you did something to protect the company as a whole from a potentially greater failure.
Have you killed a project?
What did you say, and how did it go when you broke the news? Join the discussion below, or send our editors an e-mail with your thoughts.