In software development, a death march project generally refers to a project that has a fixed release date with fixed functionality and fixed resources - resulting in crazy demands from management that developers work extra long hours and weekends.
What do you think a death march project is and how does it come about?
Usually it comes about from the business committing to the client functionality and requirements for which they think the systems/development group can finish in x amount of time... without actually asking for an estimate of time, or even going over the requirements they gathered for the client! And then because it is such a money-maker project, systems higher-ups agree to it because 'for the company overall' its a good revenue maker! I have been in about 4 to 5 death marches, usually lasting one to two weeks. My last deathmarch last about 2 months, and consisted of 9-14 hour work days. :( not fun.
From my somewhat limited experience, I would say that a death march project is any project that results in developers working insane hours for a long period of time. These developers usually burn out well before the deadline.
I've seen a couple of ways that these situations come about:
I would have to say that number one is the best indicator for me, because it's usually the cause for all the other factors. For example: overoptimism leads to exaggerated claims to the client, a willigness to accept scope creep, laziness etc.
I also think it's worthwile to note that this is not always the fault of management, the design team or any other parties not directly involved in programming. Programmers often over-estimate their abilities and can also write buggy code that sets a project back.
Unfortunately, it is also Standard Operating Procedure in some consulting companies to have some skilled engineers estimate the real man hours required for a project, then have a manager HALVE that in the final offer in order to win the bid for the project, thus ensuring a painful Death March for the team.
Another hallmark of a deathmarch is more and more people jumping ship as the project approaches the "deadline".
Deathmarch projects underscore the irrelevance of the IT organization that lets it happen. If there's a feeling that schedule and budget trump things like functionality, technical choices or business value, then IT management has been made irrelevant. IT managers are there just to oversee the cost center to which the programmers report.
If the project has no real focus on business value -- it grinds on to the bitter end where it has to be cancelled ("Descoped" or "Reprioritized").
The only way this can happen is that IT management either (a) might have a useful contribution but isn't valued by the business or (b) has no clue at all.
A death march means the team isn't building something of value, it's building something that fits cost and schedule.
When asking the team how far along they think the project is, a pretty major indicator is when the project manager estimates its 70% completed, the business analyst guesses its 45-55% completed and the developers says its 5-10% completed.
That's a warning sign right there.
I think they can come about because of poor planning & estimation, unreasonable demands by business, team implosion, scope & feature creep with tightening deadlines, as well as the good old being a stupid idea in the first place.
I would generally say that a Deathmarch is really about a systemic failure ... so it's not just one thing that creates a Deathmarch, but rather a confluence of events.
I would say that on top of general bad project management (unrealistic scheduling, mismanaged slippages etc etc etc), Deathmarch projects often involve a new technology that is being treated as some sort of "silver bullet". Often coupled with poor training and a lack of understanding.
In all cases though, a large number of the team need to know that the project is doomed to truly qualify for the title "Deathmarch".