Managing a Doomed Software Project: Practical Suggestions for Breaking the Bad News

• By Matthew Heusser
• Jan 13, 2006

Like this article? We recommend
Death March, 2nd Edition

Does this scenario sound familiar to you?

The company, department, or customer bets the farm that project X will be done by late October in order to make the Christmas sales period. Various managers assure them that this can be done. Around June, the big boss calls you into his office and explains to your team the importance of the project, its crucial nature to the business, the value of your contribution, and the importance of the deadline.

Time passes...

Sometime around July 15, you realize that there’s no way you can meet the deadline. It doesn’t matter how much overtime you work, it doesn’t matter how lucky you get—it just won’t happen.

Welcome to the doom train. All aboard.

If you’ve been a technical contributor for long, this scenario is probably rather familiar. In fact, you may be living it right now. If that’s the case, take heart—we’ve all been there before. This article is written just for you.

It’s important to note that being doomed has nothing to do with performance; it’s all about expectations. Whether having project X done by October 15 is reasonable does not really matter if project X is expected on that date. In my own career, literally every single time I have been doomed has been due to this expectation gap; nothing else comes close.

Before I offer advice, we need to make sure that you really are doomed. The expanse of human potential is incredible; don’t count yourself out just because things look grim today. If you just had a bad day, you are just stuck on a particularly nasty problem, or the project is challenging but possible, throwing in the towel early and following the advice in this article can make your life much worse.

There are lots of ways to figure out whether you’re doomed. One simple approach is a burn-down chart. Break the project into tasks and assign a point value to each task, such as how many hours the task should take. Figure out how many points your team is accomplishing per week, and you can project out to when the project will finish. If projected completion is past the due date, you’re doomed. If the project is visibly off-track, you can try to brainstorm a half-dozen actions within your power to bring it back on track. Have you given up bull sessions and web-surfing, put in reasonable overtime, tried to offload non-project work, and every other reasonable step?

Yup, still doomed.

Like any recovery program, we’ve completed the first step—recognizing the problem. Recognizing your doomed-ness is liberating, because you can stop wishing and hoping and "trying harder," and instead take actual steps to improve your life. Despite the dark cloud hanging over you and coloring your vision of the world, it’s possible to improve the situation, given just a few techniques and a plan. Let’s talk about some specific techniques first.

"I Can’t Do This": The Power of Congruence

The typical response to doomed-ness is fight-or-flight: getting scared and working lots of overtime, or getting defensive and finger-pointing. Neither of those options deals with the real problem—the combination of expectation and ability.

If you were picked to work on the big critical piece of the product, odds are that it’s because you are good at what you do and well suited to do it. Perhaps no one else knows the technology or codebase as well as you, or you may have certain natural talents.

If you are coming from such a position of respect, you can arrange a private meeting with the boss and tell him very respectfully, "I can’t finish project X by October 15. I want to. I’m working hard at it and I want us to succeed. Perhaps you can find someone else to do it, but I can’t."

Of course, there is no one else. A savvy boss will realize this fact very quickly. If you can’t do it, nobody can. At this moment, you are no longer doomed—you have transitioned the doomed-ness to the boss. This will completely upset his sense of control, and trigger his fight-or-flight response. To smooth things over, you’ll want the next step, covered in the following section.