Death march projects are standard in software development and they are usually the most complex ones to handle. It seems to me that this is more like question how to handle the chaos and how to survive it with as less losses as prossible. There are some signals of dangers I would like to share with you.
Insufficient analysis
I worked as a programmer in one death march projects where analysis was very insufficient. Of course, there were those nice UML diagrams and process descriptions. A lot of data but almost no information. Nobody in higher level of management saw no dangers to time schedules behind different processes. When I saw project schedule I almost got heart attack. How the hell it is possible to write and test complex state changing logic during three days? Analyst has all the information about danger points that may occure on development side. But still these danger points were not considered. If you see such kind of analysis and nobody agrees to change it then run and do it fast.
"Innovation"
There are always maniacs who load their guns with silver bullets and try to change the world with silver shoots. The most dangerous ones are those who try to use bleeding edge technologies that may be useful. The other type of those maniacs enter the meeting room and tell that they have very good book about some technology that looks promising. Okay, fine, but what if nobody in team has experiences with this technology?
In one of new technology projects I participated I saw this thing happening. Fortunately I was able to stop it. Why? Because same guy suggested some untested technologies for previous project and that project turns to be death march project very fast.
If you see one-man-initiated "innovation" happening and you cannot stop it then run.
Meetings are non-informative
If you have weak analyst in project and you are developer then higher level guys usually hope that you can be Atlas carrying the world on your shoulders. They don’t usually say it – they just expect it. If it happens then you have more questions in meetings with customer than you ever have expected.
If you don’t get answers to those questions or you get insufficient answers no matter how hard you try then this project team is not for you. They will eat your mind, your brains, your time, your good feeling and everything that makes up you as a human being. I have seen meetings where customer is focused on some very little and technical aspect of system and it talks about it hours. And if I asked my questions so mere mortals can understand me I got no answers I expected. I asked it many different ways but no help at all. Of course, everybody understood the question but nobody wanted to handle these questions. Why? Because they were afraid of answers that may crush the holy time schedule.
If you see that there is nothing to do and nobody is interested in providing you with information then it is time to go – don’t waste yourself.
I don’t want to be crude and tell you that you should leave projects right away when you see anormal signals. Before you leave the projects make sure that this project is going to be death march for sure. And before you leave try to give your best to get all bad elements out of project. If you leave something then you are looser (at least for some guys) and if you make something better you are hero (for all guys).