Customer Reviews

Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects (Yourdon Computing Series)

5 star:		(22)
4 star:		(31)
3 star:		(10)
2 star:		(4)
1 star:		(6)

 

 

If you've been in IT for any length of time, you have undoubtedly experienced what Yourdon calls a "death march" project. These are projects that are underfunded, understaffed, or have deadlines that are unrealistic by a factor of 2x or more. You're expected to sacrifice your life and health for an extended period of time to complete an impossible task. And what's worse, this type of project is becoming all too common in today's business. The book "Death March", while it's unable to stop these projects, can help you survive and manage them.

Yourdon examines the reasons behind why companies run projects in this fashion, as well as some of the surrounding issues that can complicate an already impossible situation. For instance, you may have a tight deadline, but the "Policy Police" expect all the required paperwork to be filled out for each deliverable. Or even more common, you have decisions that need to be made by the customer, but the customer delays making those choices by days or weeks, thereby pushing the schedule off track even further. By understanding these situations, you can devise ways to work around them or to manage expectations so that you don't get saddled with all the blame for missed deadlines in the end.

Both managers and developers will find useful material in this book. It is slanted a bit more towards the management side, but it's useful for both parties to know and understand the external pressures that are affecting the outcome of their project.

Conclusion
If you are working on a death march project (or work for a company where they are all too common), this book can give you some practical ways to deal with the issues that cause them. The projects will not go away, but you will at least have a chance to survive them without losing your sanity.

I've recently read a lot of books on the new Software Engineering Institute's (SEI) defacto object oriented software development process, Rational Unified Process (RUP), the Object Management Groups new standard visual modeling language, Unified Modeling Language (UML), and good books on software architecture, however, Edward Yourdon's Death March is the most practical book with real world advice on how to handle yourself on projects that are 50% to 100% more aggressive on schedule, budget or staffing resources than "normal" projects. This book's perspectives makes it informative for not just project managers and their development staff but should also provide insight to senior management in both the customer and development organizations. Any person who will have either a vested outcome (stakeholder) in a difficult project or is involved in the decision making (shareholder) of a death march project, should find this book an invaluable resource.

Yourdon classifies death march projects into four types: 1) ugly style projects where there are expected casualties and project failure. 2) Suicide projects where the project has no chance of success but is established and staffed by persons with company loyalty and the belief that the company's continued survival is dependant on the team's last chance effort to save it. 3) Kamikaze style projects that are going to result in the destruction of the project team and staff but can result in the greater good of the company, if successful. 4.) The Mission Impossible project style is the most attractive type of death march because even though the odds are steeply weighed against success, a superb project manager with top notch developers on the team can pull off the impossible and become heroes in the company. The Mission Impossible project type is the most desirable death march project because the project team is eager to take on the challenge and possibly learn and use new exciting technologies in the process. Despite the fact that the chance of success is slim, it's possible to win with the right people

Not only is Yourdon's Death March informative on all possible project participant perspectives on what to do when confronted with a death march project, it is written by one the leading industry pundits and is a great enjoyable read.

Edward Yourdon begins with a definition of a "death march" as any project where the schedule has been arbitrarily compressed by half, the budget has been reduced by 50% or more, the requirements of the project are more than 50% of what can be reasonably expected, or for whatever reason, the risk of project failure is greater than 50%. Given the likelihood of a permanently high-pressure, intensely competitive business environment, death-march projects will remain the norm in the IT industry, and they will continue to appear practically everywhere in business in the future.

The first edition of Death March was for me, as most in the IT industry, gratifying for its dead-on assessment of the realities of IT projects in today's economy. The title is unforgettable, sadly accurate, and particularly resonant in today's increasingly frenetic business environment. The original edition was primarily a diagnosis of the zeitgeist of the IT industry, yet it didn't propose enough solutions for the unfortunates caught in death-march projects. The new, somewhat longer second edition, offers practical solutions for dealing with death marches and the major concerns of potential readers, i.e., what can I do tomorrow? The second edition includes advice on negotiation and estimation, as well as techniques for time management and controlling interruptions.

This is a short and disturbing book-usefully short, because if you really need to read the book, you probably don't have time to read it. But for anyone involved with project or technical management, it is a must-read. And it's not a bad idea for the marketing and sales people who sometime spawn death marches to give it a look, too. With the second edition, Mr. Yourdon has created an enduring work for the IT industry and the general business reader as well, a new classic that I keep on the shelf next to Peopleware and The Mythical Man-Month.

Death March projects seem to be the norm in the software industry. This book explain about how "death march projects" comes about, and how to survive it. While reading this book, I always found the examples given so realistic that I wished that I have read the book before I have graduate from University.

Within it, you can also see software project management tips littered throughout the book. They are often found in project management books, but somehow they never got registered in our brains. For example, it talks about "triage". Putting it into simpler teams, it means classifying the features to build into must-do, should-do and could-do. This concept of "scope" have been widely been discussed, but people failed to put them into practice.

This is an informative book to understand about "Death Marches". Understanding is the first step into winning the war of "Death March Projects".

This is definitely a book that is worth you spending your bucks on.

Death March does a great job of explaining what is wrong with the software development industry--and the problems are pervasive and horrible. I have been involved in plenty of disasters myself (everybody has), and I got a crick in my neck from wagging my head up and down as I read. Perhaps the most therapeutic part of the book is finding out that you are not the only one, and the grass is probably brown across the fence at the next company, too.

I loved the Napoleon quote: "It follows that any commander in chief that undertakes to carry out a plan which he considers defective is at fault; he must put forth his reason, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army's downfall." Great advice unless there are no alternatives and the Barbarians are storming the gates.

Yourdon does review the options for a team lead faced with no-win situations, and the book is useful for helping you think clearly and cast a wide net for solutions when you feel despondent and desperate. The oft-reiterated advice to quit is something I have done in the most egregious situations, and there is nothing like the feeling of relief when you walk out of a pressure-cooker for the last time. But realistically, you have to pay your bills.

What I can advise is to read this book to understand the sickness, and then do the best you can to change the industry. The problems are endemic, but plenty of other professions have reached a point where they can realiably estimate projects and complete them successfully (e.g. construction and building trades, manufacturing, even military planning).

Of course, you may want to move up in management, but then you might become part of the problem. This book could help you gain some vision for leading a successful IT organization. Arm yourself with knowledge and start a crusade as an enlightened IT leader!

Having managed several death march projects before I had even heard of this book, and now being involved in the mother of them all, there is a certain grim satisfaction in recognising one's situation in the title of a book.

This is a book for project managers who are faced with the impossible. It prescribes no magic formulae, but assists the often stressed and over-worked PM's brain to calmly consider the symptoms of the current environment and even to admit a laugh or two about the absurdity of it all.

As a project manager who has worked mostly in the web environment, I can safely say that the majority of web projects are death march projects - it all depends on the organisation whether they're Mission Impossible or Ugly.

Much food for thought for web development projects, in my opinion, and the principles do not date at all.

Yourdon's descriptions of the corporate culture and circumstance that lead to "Death March" projects demonstrate clear insight into current software project management practices. However, some of the survival strategies are specific to software systems that are not complex in their implementation. Throwing out methodologies and design processes can only be done on systems where the implementation itself is not complex, such as a client/server database application. The system is complex, but the code is not. My 15+ years of experience in embedded real-time systems with very complex and challenging software solutions leads me to believe that the only way to succeed in a "Death March" is to do as much rigorous top down design as possible and push out the "combat coding" as long as you can. In this arena the methodologies save you from the "Death March". The commenter from a company in Montana pointed this out and mid-stream Yourdon had to slip in an abrupt recommendation to not really discard design methodologies. This appeared about 2/3 of the way into the book. I personally have been very successful in avoiding Death March projects by applying the methodologies that Yourdon, DeMarco, Ward, and Mellor pioneered and that Yourdon now says to discard to get projects done faster. In my last large project we shipped a new system five months early on a 17 month schedule through rigorous use of Structured Analysis and Structured Design (that is the methodology that the bureaucrats force us into and it works).

Its funny reading the reviews which are posted here, esp. the one which says its a tad outdated. As if such reading was a fad. "Dont read The Mythical Man Month. Its old and hence no longer true!". Obviously these people have never been in big projects which have suffered from budget, schedule and/or resource deficiency.

Although I concede this book does not give how-to-fix-it solutions, it covers in good detail how to recognise Death March projects and DO SOMETHING about them. This is not a book for juvenile programmers, but for project managers struggling to make their projects complete on time, within budget and with desired quality and who have experienced their projects slip schedules by several months, one-day-at-a-time.

Chances are, anyone who's reading this book is on or has been on the very "Death March" projects it describes; I know I have.

As such, the book reads not so much like new information, but rather like a conversation around the watercooler. "Should have bailed on that project," "Try to get all the 'must have' functions complete," etc.

The upshot: While this book is affirming of the ad hoc insights all developers make as we go along, nothing's particularly revolutionary here. If you've survived one "Death March", you have these lessons hardwired into your brain:
1) Understand the politics of your organization
2) Don't use risky, not-ready-for-primetime technologies
3) Prioritize your function and drop fluff as necessary to meet your targets.
4) If all else fails, quit. That'll teach 'em.

Overall, there are some valuable insights, but I wouldn't waste my money.

This book does have one or two minor issues but is otherwise an excellent book for what it was intended to convey. I was required to have this book for a project management course I just completed taking at the university I attend (as I'm one of those computer people who works in the business but is just now going back and getting a degree in it). In my 7-8 years of experience working on numerous government and commercial IT contracts, Edward Yourdon has gotten it nearly perfect in his descriptions of projects gone awry. I found myself just nodding and saying to myself, 'Yeah, seen that...' or 'Yup, been there...' as Yourdon describes all sorts of "Death March" projects (projects which don't have the time, funding or expertise to meet their goals - but the participants charge ahead anyway).

The sad fact of the matter, which Yourdon points out, are that Death March projects are the norm and not the exception - no argument from me there. If you've ever wondered to yourself, 'Why is my project so F'ed up?', this is probably a good book to read to understand the big picture of how things go wrong. I would say this would be a good book to learn from (i.e., how not to have Death March projects), but the problem is that most of the things that make projects a Death March are out of the control of the 'Average Joe' on the project.

The only issues I can see with this book, is that Yourdon offers no real solutions to avoiding such projects other than "quit" (if you can). Although that is pretty good advice for those few in a position to do so, its little comfort to everyone else. But then again, you just need to see this book for what it is: A study on failed projects and why they fail, and not as a remedy for fixing them. If you do that, I think you will enjoy the book and come to an understanding of project dynamics that you may not have had before.

Who knows, hopefully you or someone like you reading it, will build on Yourdons work and come up with some real usable solutions.