Managing a Doomed Software Project: Practical Suggestions for Breaking the Bad News
Date: Jan 13, 2006
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.
"I Might Be Able To Do This If": Creating a Negotiation
Managers like to have control. This makes perfect sense; out of control and responsible is a very scary place to be. One form of control is choice. To create choice, just give the boss options:
- We could slip the project by two weeks.
- We could split the project into phases, delivering a completed, working system on time and delivering follow-up functionality two months later.
- I could stop working on the super-gonzo project.
- I could stop other related support activities. (If you track your time for a few days, you might be surprised at all the extra little activities you’re supporting. If you stop supporting those activities, people will probably complain. Framed this way, though, it’s the boss’ decision, not yours.)
- We could lower the mean time between failure (MBTF) expectations of the system. In other words, expect the system to error more often, and thus lower quality requirements.
- We could block off boardroom A and get the entire project team working in the same place 100% of the time, and we might have a chance.
Offering options has a wonderful effect. With reasonable management, you can back out of unrealistic expectations, provide management with a sense of control, and reframe the entire project to be possible.
Squeak Early, Squeak Often
The earlier you provide this information to management, the more they can do about it. Remember: Keeping management in control is in your own best interests. Squeak far enough into the project, and with enough data, and it will be clear that you’re a committed contributor who isn’t just crying wolf.
If the information you provide seems to go in one ear and out the other, start sending it by email. Daily. In most organizations, you can carbon copy (cc:) two or three levels up the chain of command in status updates; they may even thank you for it. You can also carbon copy the customer or other key stakeholders on the project.
In any event, this is a lot more than just covering your tail, although it does work wonders for that purpose. Squeaking often and consistently will lower expectations, thus formally un-dooming you.
What Should I Work On Today?
At this point, you’ve told the boss that you will not hit the date. You have reframed the problem from a personnel problem (you are late) to a project management problem (someone needs to adjust the schedule to reflect reality). The next question is this: "What should I work on next, boss?"
This question preserves the manager’s sense of control and gives him choices. If you have to be explicit, ask, "Should I work on features or fix bugs? What features? What bugs?"
The doomed-ness is now at the feet of the manager. Do your best, be professional, and stay committed to the project, but you can now officially stop feeling bad that you cannot do the impossible. (But if by chance you’re doomed a lot and no one else in the organization is, seriously consider whether you are cut out for the role you are currently assigned.)
Nine times out of ten, the original due date will come and go, the company will survive, and your job will be safe. If the organization is going through some internal meltdown and your job really is in jeopardy, I hope that I have helped you recognize the unreasonable management, and you have been working on an escape plan.
Customer Involvement
The previous sections assume that the big boss is the one who doomed you, but often there’s another interested party: the customer. The customer may be a single company you work for, a particular executive, a business unit, a person in marketing or sales, a "program manager," or someone else entirely.
One common problem that can accelerate doomed-ness is the customer and the big boss having different expectations. Perhaps one of the compromises I have described so far could lead to an outcome that is perfectly acceptable to the customer, but the boss (the liaison between the two groups) just can’t see it. Perhaps they disagree on a key feature, or quality expectations, or have some other issue that’s creating conflicting expectations—and you, as a contributor, cannot fulfill both at the same time.
Generally speaking, the person who is going to be hurt the most if you can’t make a delivery date is the one who is paying for the software—the customer. If the customer is not represented in the discussion above, negotiation may be impossible. This can be fixed by bringing the customer into the decision-making process. You can do this in a number of ways, such as suggesting, "Since we are not expecting delivery on date Y, you’ll update the project plan and discuss options with the customer, right?"
In Agile environments, you may be working directly with the customer, and the customer may see you as a living, breathing human being. In that case, the customer is much more likely to view the schedule as something flexible that can change, not a contract written in stone to be insisted upon.
So if you are doomed and the customer isn’t involved, try to get her involved. Make sure that she feels in control. Otherwise, we’re back to fight-or-flight.
All or Nothing
I have worked on several projects where the customer insisted that it was "all or nothing"—they needed all the features, on the exact date, at high quality, or the project simply was not worth doing. With no lever to push, the success of the project relied entirely upon the feasibility of hitting the date.
In all of these cases, when push came to shove, the customer found functionality to cut. When they made the choice earlier in the project, they made the choice consciously, and they felt in control of the choice, customers were much more likely to view the project as a success, and the doomed-ness evaporated.
Suppose you want the customer to make the choice early and she keeps insisting that it is all or nothing. What can you do?
First, ask what features are the most important—the key features you need to deliver to test early.
Second, put it this way: "I want to get everything done on time. We may be able to. I may not need to even ask this, but if you had to pick just one feature to cut in order to make the deadline, what would it be ?"
Once the customer identifies that non-essential feature, ask for just one more. Then one more.
Pretty soon, without even meaning to do it, the customer has prioritized the features, allowing you to work on the key features first, and, more importantly, break the project into phases.
Sometimes, the pressure is turned up so high that the difference between reasonable management and unreasonable management is hard to tell; in that case, I have room for one additional technique.
One Final Idea
At one point in my career, I was involved in a project that was completely doomed from the beginning. Three executives, one of whom was non-technical and another a new hire, without any specific knowledge of the work involved, took a guess at the delivery date for a major project. After the date was set in stone, they brought in the technical team to do the work.
And, of course, they were wrong. Wildly wrong. A three-month project for 10 people turned out to be a nine-month project with a staff that ramped up to 40, which was only possible because the people we brought in knew the system well and could be productive.
To get those people, we had to take them off other projects, so not only was the big project late—the entire project portfolio for the year was late.
Down from the mountain came the announcement—the big boss wanted to know why the big project was late. The big boss wanted to know who was responsible.
I was called into a meeting and asked "Why was the project late?"
I was doomed. After taking a deep breath and counting mentally to five, I took pains to say in my most congenial, non-confrontational voice, "Why did you think it was going to be done on time?" Suddenly, the environment changed to something besides blame: Honesty.
The rest of the after-action review process was unclear to me. I don’t know what happened or who said what to whom. In fact, I know only two things:
- No one was ever fired.
- No one ever asked me a single follow-up question.
Risk is par for the course on high-technology projects; without risk, there’s no reward. Doomed-ness, on the other hand, is temporary, and best avoided when possible.
For More Information
If you enjoyed this article and would like to read more from the Doomed-Ness Body of Knowledge (DNBOK), I recommend these books, all of which inspired examples in this article:
- Death March: The Complete Software Developer’s Guide to Mission Impossible Projects (Prentice Hall, 2003), by Ed Yourdon
- The Deadline: A Novel About Project Management (Dorset House, 1997), by Tom DeMarco
- Behind Closed Doors: Secrets of Great Management (Pragmatic Bookshelf, 2005), by Esther Derby and Johanna Rothman
Matthew Heusser actively develops working software and also writes and speaks on systems improvement. You can email Matt at Matt.Heusser@gmail.com, or visit his web site, Excelon Development.