Death March

Perhaps more than any other engineering discipline (see Steve McConnell’s After The Gold Rush), software engineers work on projects that have no real chance of success. There are as many reasons why as there are projects, but if you want to be in with a chance of surviving such a ‘death march’ this could be the book for you.

Content

Edward Yourdon is a well known and well respected computer scientist, so what useful information can he give you in these circumstances? Surely you’re lumbered with the simple choice between putting up with it or resigning?

Well, no. The book explains that there are any number of things to do, and not just for the project stake-holders. There are things that just about anyone on the project — and indeed just outside the project — can do. And quitting is almost always one of the options he gives. I find this interesting because most books tend to argue that you can fix anything. Sometimes you just don’t have the authority to do anything that would make a significant enough change.

Of course, it’s a two-hundred page book, so it doesn’t just launch into this resign-or-fix discussion. First he talks about what a Death March project actually is, and then moves on to finding who the key players in the project are. These people are not always those that you think should be in charge! For example, the CEO’s golfing partner is often in a position of power and influence, although you won’t find them in the organisation chart. (I’ve seen these kind of dynamics in play, but I hadn’t really though about it in these terms.)

He then moves on to negotiating the best deal for you and your team in this bad situation. You may not be able to get your boss to accept a rational argument at the beginning (or even towards the end) of the project, but you should at least try. And these are the arguments to use!

Motivation, both from the various clients and in your own team, play an important role in the success or otherwise of the project, and are discussed in some detail. One vaguely controversial statement is that we all need to be involved in politics to some extent. I agree with the ‘why’ — even your boss may secretly want your project to fail — but I don’t know how. Many, maybe most, of the developers I know have absolutely no interest in politics and try to pretend that it doesn’t affect them!

The next two chapters talk about methodologies and tools, and their applicability to death march projects. The last chapter discusses integrating the death march into your companies culture (most of your projects are going to be like that anyway, so you may as well get used to it!).

Controvacy!

It’s not all good news, though. Some of the chapter on staff motivation is hard going (or at least would be for the people on your project). One of Yourdon’s correspondents suggests that, on a death march project, people should be putting in at least 60 hours a week! I know that some people do that, and that it is encouraged at some companies, but I really don’t think that people should be encouraged to do that on a regular basis. It’s only fair to say that Yourdon goes on to say that people working over 60 hours a week need to be watched closely, but by then the damage may already have been done.

Generally, however, the advice given is very pragmatic. I’d like to think that most of it was obvious, but it isn’t. This is the kind of information you probably realise only after years in the business.

Overall

I’m sure you can guess by now: I’m impressed. Most Computer Science books are not this sensible and are frequently based in research in university labs rather than commerce. In fact, I’m pretty certain that I’ve never seen a book that recommends that you resign in certain circumstances!

It’s not just the detail that makes this an important book. Yourdon backs up his assertions with examples and email’s from colleagues that discuss some of the options available.

If you work in IT, sooner or later you will end up working on a Death-March project. This book is just what you need to be able to tell what chance of success it has and whether you and your organisation will survive it. Highly recommended.