September 1st, 2006
In the first chapter of my Death March book, there’s a lengthy discussion of the reasons why these crazy projects get started — i.e., projects that typically have only half as much calendar time as they should have been given, or half as much money, or half as many developers. My so-called “justifications” for death-march projects included the following:
- Politics — i.e., political pressure from the boss, or the customer, or some other key stakeholder
- Naive promises by the marketing folks, who desperately want to get the business
- Naive promises by inexperienced technical people or project leaders, who actually think they can accomplish miracles and deliver the project in half the time, half the budget, and/or half the number of people than one would normally estimate.
- The “startup” mentality: three guys in a garage, who have to build an amazing new system really, really quickly before they run out of money and their landlord shuts off the electricity.
- The macho (or “Marine Corps”) mentality that says normal projects are for wimps, and “real men don’t need no steenking vacations, personal time with their family, or sleep.
- Intense global competition that’s threatening to put the entire organization out of business unless they can get Project X finished really, really quickly … and really, really inexpensively … and without hiring any additional people.
- Intense technical competition from a startup company that’s just introduced a sexy new product that makes your product look obsolete.
- Intense pressure caused by onerous new government regulations.
- Unexpected crises — e.g., half the developers have come down with bird flu, and the rest of the team will probably come down with the disease in the next couple of months, by which time they darn well better be done with the project.
I thought it would be interesting to see if any of these death-march rationales have changed significantly since I first wrote the book 10 years ago. My own personal experience is that things haven’t much in this area, but I’d like to get your opinion.
I’m looking around for some sophisticated survey/poll tools that I can link into this blog, but for the moment, I’ve found a simple, free one with some HTML that I can paste right into this entry. Unfortunately, it only allows for five choices to the survey question, and it doesn’t allow prioritization of the responses. But, hey, it’s a start. If you have a moment, please respond to the questionnaire (it’s anonymous, and no personal information is collected); you should be able to see the results on an ongoing basis, too. I’ll let you know when I’ve figured out how to replace this quickie version with something more sophisticated.
September 8th, 2006 at 2:51 am
In most cases there probably is no single answer to this “why start” or the “why volunteer” question. Somewhere in the formula for both there is a prominent place for lack of courage, lack of candor, and often lack of competence. Just because business management is unrealistic in asking for a particular amount of functionality in a particular amount of time for a particular amount of $, does not mean that competent and courageous IT professionals are required to agree, especially when they know it is unrealistic. I am reminded of Tom DeMarco’s use of Monte Carlo simulations to generate a probability distribution of possible project outcomes. Business people generally understand such probabilities and it is IT’s responsibility to provide business management with the information they need to make the best possible decisions about IT investments. A project without risk is likely a project not work doing. But knowing and communicating the risks and the rewards of IT investments is IT’s responsibility. If the business once so informed is willing to take the risks, then so be it. We alway have the choice of waking away if we think it appropriate. And you never know, they might be right, or even just lucky. It’s IT role to help the business have realistic expectations. We guide, but generally we do not decide IT investments (infrastucture and such aside). And just because it may be a death march, does not mean it has to be your death march. I can hear Mom asking, “are you going to follow them if they jump off the cliff too?”
September 8th, 2006 at 1:19 pm
Ah, well, in my org. hopes springs eternal. Orgs have needs, and the needs always involve change. Faced with the certainty of the need to change, someone is always prepared to declare that this time it will be different.
The successful PMs I know are savvy enough to say ‘no’ to obvious invitations to failure. Sometimes it takes several ‘no’s, but the really seasoned ones know enough to keep saying it. Most of the successful PMs I know are in their 40’s, 50’s, and 60’s.
I spoke with Rita Mulcahey about this once. She said she considered it a common characteristic of the really good PMs she knew that they walk away from projects that can’t succeed. Another common characteristic was the realization that you have to fire or remove people that are obstacles to success. All of that is not intuitive, it is learned through experience. Ultimately, she said, the really good ones become total pros, doing the reading, doing the homework, going the extra distance. PM becomes their life.
I doubt that you find many highly competent, highly experienced managers that are willing to take on a DM project. So how do they start and who runs them: It would not seem to be the people that Rita was describing. The rest is simply mechanical and inevitable.