Many organizations cannot survive Death Marches. Exceptions are the federal government and university hospitals. It's a pity that those most in need of this information are highly resistant to learning about the problem until it's too late. The innocent seldom go unpunished. The perpetrators are promoted. Example's of Putt's Law at work.

mv

You can consider yourself a very lucky software professional if you have not been involved in a 'death march' project (as a tester/developer/manager/architect/etc). Luck runs out -- so consider buying this book or hearing similar advice from others who have felt like their lives would end on that "phony deadline", before ending up there.

The first brownie point for the book goes for recognizing that the software industry is immature - which is the main reason behind such projects. It then describes what to look out for, and other points of caution that one needs to have in mind.

It was refreshing to see my personal experience match the author's, in terms of what generally works and what does not. Other than that, as with most books of its kind, in the end it seems as if it was elaborating on the most natural pieces of advice; still, noone is surprised to see 'death march' projects fail.

In particular, Yourdon describes how teams and team member dynamics play out in such scenarios, as well as the HR functions necessary to complete the picture. He talks about the Politics, and how the stakeholders manage their negotiations in such projects. He also brings up processes ("triage"!) and project management practices that could help (but only if they are not based on bureaucratic concepts). Furthermore, although he devotes a few pages on risk management, there is not enough coverage on that topic - although one could claim that most of the book is exactly that.

Overall, a good and worthwhile read if you are in the software business - but since each situation is unique, your mileage may vary.

Reading this book you will realize that it all relates to your experiences. I personally appreciate books that I can relate to and that are not just theoretical.

This is a must read for all developers and their managers.

Learn from experience - we (software engineers & managers) do not always re-invent the wheel.

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!

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.

Yourdon's book is a great read on identifying Death March projects. The fact is that we have quite a few people who fail to realize (or do not want to admit) that they are in such a project. After all, knowing the problem is a good start to a solution.

Yourdon does a nice job of examining the root causes through recent examples in the industry.

I expected to see more pragmatic steps to handling such projects .. but the solutions are generic at best.

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.

This book is worth it for the chapter on Critical Chain alone.

1. This book has many grammatical mistakes.

2. The same simple idea is usually repeated throught a chapter. The book actually could have been 1/3 thinner. Too much reading to unravel too few useful ideas.

3. "Quit the job" is often cited as an effective way to deal with death march projects

4. The last few chapters are simply out of touch with reality - using tools for complex modeling and analyzing the the "soft" factors (skill acquisition, morale, etc.) of software process and introducing common sense in finding the dysfuctions in an organization that unlikely to be changed. In my opinion, All these actually constitute the "art" of project management and are too simplistic to be subjected to these kind of logical analysis.

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.

This book was a great read for anyone interested in understanding what the "death march" projects are all about. Having lived through a number of these projects myself, I really felt that my experiences were written in the pages of this book. There were a lot of helpful sayings and examples provided. I believe that college professors should incorporate this book into thier classes towards the end of the Sr. year of undergraduate and during the first year of the masters programs in computer science.

By definition, a death march is a software development project that stretches people beyond the point of exhaustion without concomitant rewards. While they are very common in the area of software development, they do not always start that way. Some death marches have that form from the very beginning, where some individual(s) in power ask for a product where either the functionality or the time frame is thoroughly unreasonable. Others start out appearing rather reasonable, but somehow they get morphed into another, much more complex form. Yourdon concentrates on all aspects of death march projects, the social, psychological, economic and political forces that create one, either from the beginning or somewhere along the way.
He rightly places a good share of the blame on self-styled "heroic" programmers, which are by definition those who manage to build projects that seem to be impossible. Many programmers, and I am personally in this category, have the attitude that they can code anything, so they say yes when others would say "Impossible!" While some may consider this a fault, others consider it an occupational necessity if you are going to remain innovative. If the second category is the correct one, then having some death march projects is a sign of health in the industry, and the question becomes one of percentages, rather than existence. In either case, Yourdon gives some excellent advice in how to recognize and survive a death march. Sound advice all should consider, for even successful death march projects must be survived.
In reading the book, I began reaching the conclusion that a large number of death march projects are a necessary filter that is helping to drive the enormous advances that continue to be made in computing technology. The conditions of many being pushed to the limit with some projects succeeding is an example of Darwinism being applied to technology, and ferocious competition is where the most rapid evolutionary change takes place. Much is made about the large number of software projects that are cancelled, but one could consider them similar to nature's evolutionary dead ends. This may not be the point that Yourdon wanted to put across, but it is a tribute to the book that it forces you to think about death march projects and helps you to reach your own conclusions.
This book is on my list of best books of the year 2003 that will appear in the online "Journal of Object Technology."

A few years back, Ed was so hard up for cash that he wrote a book called "Time Bomb 2000!" in which he predicted the end of civilization. This silly prophecy only served to expose Yourdon for the fly-by-night, fast-talking, hourly-rate, con artist that he is. In other words, Ed completely undermined his reputation with every CIO in the industry.

My guess is that, on 1/1/2000, Ed was hunkering down in his survival retreat, drinking his bottled water, and wondering where in god's name his credibility went.

Given that his career as an oracle was cut short, Ed decided that he'd stop predicting the future and start cashing out on the 9/11 mania. Just like any talk show host or stand up comedian, Ed found ample material to make a few bucks off of the hysteria. He demonstrated the kind of initiative that would make Jeraldo Rivera proud.

The goal of this book is to keep Ed's name in circulation, so that he can charge a few more dollars for his worthless consulting services. Perhaps he'll use the royalties to refinish his deck or replace the transmission in his aging sports car. Ed's not going to tell you anything you don't already know, he's just going to make you think he will (which is the trick he uses to get you to buy it).

This leads me to think that I need to write Ed a letter...

Dear Ed,

Hello there little trooper. Isn't time for someone to pack it up and call it a career? Wouldn't the whole industry benefit if you took your fat, wrinkled, mug out of the public eye.

You pretty much admitted, in DeathMarch, that structured analysis was a crock. Face it, old man, you're over the hill. You've got no good ideas left. You're so desperate for ideas that you're reprinting Deathmarch. What are you going to do next time, reprint Time Bomb 2000!

I think you've fooled enough people out of their money. You've had your fun, Ed, now retire to Boca Raton and give us all a well deserved rest.

Please, Ed, pretty please.

Your Pal,
LLNL Engineer

This book by best-selling author Edward Yourdon is aimed at giving advice to everyone on a software development team on how to survive "Mission Impossible" projects. The underlying assumption behind this book is that in the worse case scenario, you can quit your job and move to another company. This strategy worked during the boom economy of 1997 through mid 2000.

But since 2001, it has become increasing difficult to take this stance. I am hoping the author will address these issues as applicable to the current environment where you can be out of a job for a year or two if you don't toe the line drawn by the powers that be.

Anyway, keeping this dangerous assumption in mind, this book provides a good insight into why these 'death march' projects happen and what you can do about it. These difficult projects are defined as "a forced march imposed upon relatively innocent victims, the outcome of which is a high casualty rate". The conditions usually involve one of more of the following - highly compressed schedule, reduced staff, minimal budget, and excessive features.

This short book starts off with an introduction to why these bad projects happen in the first place. The topics of politics, negotiations, people in death march projects, processes, tools and technology, and death march as a way of life. These are the various chapters in the book. As you can tell by the title of the last chapter, the author believes that death march projects are really the norm and not the exception so we all need to learn how to handle them.

If you don't have much time, the author recommends reading the concept of 'triage' discussed in Chapter 5: Processes and I thoroughly enjoyed reading this chapter before going back to the preface and the rest of the book. There are some very interesting personal notes by the author at the end of each chapter that are really worth reading. Even though the author claims that he is being serious, the book is very humorous throughout. Of course, it is easy to laugh if you are reading this book at a time when you are NOT on a death march project.

In chapter 2, five typical political players of a death march project are identified - owner, customer, shareholder, stakeholder, and champion. There is then a discussion of each type. If pressed for time, read pages 52-59. In chapter 3, a few of the familiar games are discussed - doubling and add some, reverse doubling, guess the number I'm thinking of, double dummy spit, spanish inquisition, low bid, gotcha, chinese water torture, smoke and mirrors, and finally hidden variables of maintainability/quality. If pressed for time, read pages 80-85.

In chapter 4 about people, on the topic of team building issues, 8 project roles are talked about - chairman, shaper, plant, monitor-evaluator, company worker, team worker, resource investigator, and completer. The 7 practices that lead to 'teamicide' are also addressed - defensive management, bureaucracy, physical separation of team members, fragmentation of people's time, quality reduction of the product, phony deadlines, and clique control. The four stages of team gelling are pointed out - forming, storming, norming, and performing. These four stages are discussed in various other books also.

My favorite chapter is on Processes (chapter 5) where the concept of 'triage' is discussed as applied to software development projects. Don't miss this chapter. Chapter 6 is a very short chapter on tools and techniques that most of us may already be familiar and if not, read this chapter as it is a good discussion on how right tools can affect your success positively. I felt the last chapter was more of a philosophical discussion of death march projects being a way of life and what to do about it.

Overall, this book is a must-have even if you are a veteran to the software development field. Don't forget to check out 'Rapid Development' by Steve McConnell that is a much heavier treatise on software development and the various success techniques.

The author of 'Death March' - Edward Yourdon has a website with his last name as the URL with the latest information on this subject. As I mentioned in the subject line and at the beginning of this review, there is a risk in following this book in this weak economy that could prove especially dangerous for IT professionals ultimately resulting in a spot in the unemployment line. Since it is so close to the publication of the second edition, the author has removed the manuscript chapters on this new release. So I am not really sure if he has a new philosophy for this type of an economy in the upcoming second edition. I would recommend waiting for this second edition. Good luck!

I recommend this book for anyone involved in the software development process - although this book is essential reading for software developers, it is also important that project managers read this book. A team consisting of software developers reading this book, and a naive project manager, is similar to a "death march" marriage where one spouse goes to a counselor, and one does not. I stumbled upon this book while working on my third major software project, and reading it greatly increased my understanding of the people issues which existed on that project. The "notes" section at the end of each chapter is especially good, each of which contains very pragmatic information. As a current computer science/software engineering graduate student who was encouraged to read "The Mythical Man Month" by Brooks upon entering the field during the last decade, I believe "Death March" is an essential accompanying text to Brooks.

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.

The longer I work in the IT field, the more books like this become more valuable. It used to be that 30%-40% of the projects that I worked on would be "Death Marches", now its around 70%. The political games, personality problems and poor planning issues are all covered in this book plus ways to handle them. I recommend this book to anyone who has to work in IT, or manage any type of project.

This is a good, quick read on an interesting toppic. A lot of relevant anecdotes from some experienced engineers, but it wasn't as useful as I hoped. Sometimes, quitting is not the answer! I was really hoping for a "prescription." There are enough useful tidbits and soundbites here to be worth the read, however, and it's a great introduction to other similar writings (many referenced within).

Boy, I wish I had read this book a long time ago. Who would have thought that so much about the hidden forces that shape technology development projects could be explained in just 200 pages?

I found this book credible, useful, and a fun and easy read. It's a little bit cynical and short on solutions, but that's hardly a criticism -- if you're on a death march project, you lose.

For example, you really need to make sure that the reward for heroic success isn't another death march. How you do this isn't exactly clear, but if you're not confident about it, then it's probably time to take a permanent vacation.

One serious flaw is the failure to mention that left to their own devices, *most* death march teams will decide that there isn't enough time to plan or to test, as if somehow magically neglecting to do so won't make the project even later. The project manager needs to make sure that this doesn't happen. If you read "Death March," then you probably ought to also read "Rapid Development" (McConnell) for balance.

Nonetheless, if you're a project manager or a project team member with more than a year of industry experience, then you'd be foolish not to read this book.

This book gives you a very real life understanding of projects. This is a book for project managers who are faced with the impossible. Death March projects seem to be the norm in the software industry. This book explains about how Death March Projects comes about, and how to survive it. While reading this book, I always found the examples given are very realistic. But this book does not offer solutions for people involved in Death March situations. There are no silver bullets here.

The book illustrates that politics exists in your project as well. To determine all major political players, involved in the project is the task of any participant: from the stakeholder and project manager to the minor developer. It's a hard task to spot all the players, but once you did it, your project will get more chances to survive and you will keep your sanity. This book doesn't have easy answers, but it will encourage you to start analyzing things which you never thought about, it will encourage adaptive work on yourself.

Because this book is encouraging, but not practical, I would recommend "Software Project Survival Guide" by Steve McConnell and "Agile Software Development" by Alistair Cockburn prior to reading this book.

This is a reality check for those contemplating or embarking upon a death march. Evaluate the situation before making the decision to join a death march team. Consider the personal and professional sacrifices. The introduction is too long, I sat the book down several times.
The book contains relavent information, and should be required reading for undregraduate and graduates, but perhaps a condensed version. Hopefully the students will have instructors that will assign section in order to cut down on the repetition.

In his book Yourdon is brutality honest about the disvantages of a Death March project (nearly impossible IT projects to complete - like salmon swimming up stream)and the negative effects they have on the participates. One can learn something even from the negative events of this kind of project. I do think the book should be required reading for potential project managers and developers in undergraduate and graduate schools, so that they may evaluate or rethink their options about some phases of the IT career field.

As a survivor of a "Death March" project myself, this book clearly lets the reader know what a death march project is all about. This book is a must read for those in software development who are involved with or are contemplating a new software engineering project that "promises to deliver everything including the kitchen sink, but you know has no realistic chance of succeeding". This book is a must read for both present and future project managers who will eventually become involved in a death march project. Death March projects are truly becoming the norm and we had all better be prepared for them.

While there are projects that are Olympian in nature in every field, and there are reasons to take on projects with high risks, the majority of "urgent" software projects are based false perceptions. This book describes how to survive in a self-imposed state of pain, suffering and lower life quality. If you have no choices, the book is really helpful. If you have a choice, there are software development organizations who have performed the cranial-rectal inversion and are willing to bring like-minded people on board. You don't have to settle for a death march career.

This is not a typical project manager's toolkit. I read this book when it first came out, and I found some of the anectdotes and tips helpful as I grew as a software project manager. There are excellent, practical suggestions about maintaining peace and harmony amongst team members, and back at home. One of the most eye-opening suggestions at the time for me was his characterization of requirements -gathering- vs. requirements -negotiation-. This is a subtle though important difference, and can dramatically change the situation to one more favorable for the development team. A light, recommended read.

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.

Lots of good stuff in here.

A death march is a software development project where the participants are working excruciating hours in an attempt to achieve a goal that is most likely impossible. There is nothing new about this in the human experience. Most of our myths, legends and success stories are based on people emerging from such circumstances. The reasons for our willingness to voluntarily enter into such projects go to the very heart of what makes us human. In most cases, there is the prospect of a significant reward if successful, both monetarily and the satisfaction of accomplishment. We strive for success, pushing ourselves to the limits, so that we will truly know what those limits are.
The technical fields are filled with stories of extraordinary success, with the most pronounced being in computing. Enormous fortunes have been earned by those who kept the faith and worked to exhaustion to create a valuable product that they can be proud of. However, like everything in the free market economy, for every success there are an untold number of crash and burn failures. The key for anyone contemplating joining such a project is to determine what the chances of success really are and that is the main point of the book.
Yourdon concentrates on those factors that largely determine whether the project has a chance of success. These factors can be summed up into a few key points.

1) Collect a committed group of overachievers who understand the odds and consequences of success and failure.
2) Have a manager who is willing to place their career on the line, even to the point where they may have to make forceful suggestions to higher level managers.
3) The manager must also be able to control who works on the project and prevent people from being assigned to it simply because they are incompetent in any other capacity.
4) Make sure that the project is not there simply to score points, get even or be a target for sabotage by others wishing to advance up the corporate chart by climbing over others.

While some projects may have succeeded without one of these points being true, it is hard to believe that that is the case. Projects that fit the criteria of a death march are becoming the norm in computing, particularly in the arena of small businesses. The growth of the Internet has led to the new type of scheduling known as "Internet time" , where iterations of products are now measured in months rather than years. Since this is the new reality, there is nothing to be done except adapt to it or change careers. Yourdon makes it clear how such projects must be approached, from the tester up to the senior manager and it would be risky not to follow his advice. His simple, yet effective breaking down of the projects into four simple categories is an excellent way to determine what your chances of success really are.
Many of the greatest successes in the history of computing are based on "impossible" projects succeeding, which is no different from the rest of the human experience. While luck always plays a part in such successes, most of the time it is due to hard work, dedication and preparation, things that we can control. Nearly everyone who is currently in the computing field will at some point be a part of a death march project. Like all extremely difficult tasks, the only hope for success is to enter with open eyes and know what it takes to increase the chances of success. This book will help you with the latter. The first is up to you.

A death-march project may be seen as a modern day chariot-racing event where the project manager is the gladiator with the whip, and the software development team is the expendable pack of horses pulling the chariot forward at dangerous speed.

In order to maximize the chances of succeeding or at least surviving in a death march project - where most civilized rules of behavior have been stripped away - you need to read and understood the basic truths, brutal facts, and time-proven tactics that are explained in this insightful little book.

The only fault I can find with this book is that it appears to have been written as a stripped-down death march project of its own. Many areas could use more elaboration to achieve better coverage of the subject matter.

I've read hundreds of software books and, for the most part, they all have the same thing in common: they tell you how the world should be. This book is different from those other works in this important respect: it tell you how things ARE. While many books grudgingly admit that most shops are at SEI level I maturity they do not convey the ultimate consequences associated with that state. This book does.

"Why on earth did I let myself get suckered into such a project?" The project described in this cry, of course, is a Death March. It is a project where arbitrary decisions have been imposed like the compression of the schedule or budget, or a cut in the staff. There are many factors that can contribute to a Death March but they all lead to the same end: a failed project.

The book could have been dry and dark, taking an already depressing subject and bludgeoning the reader with analysis or empty assessments. Instead, Yourdon tries to keep things light by including discussions (via EMAIL) he had with contributors at the end of each chapter. Within these notes the many people Yourdon corresponded with during the writing of the book offer their own stories and their own analysis of how Death March projects get started and how people survive them.

Including these correspondences, in their raw form, was a brilliant stroke which put a human, and often entertaining face, on these difficult situations. They are interspersed with other book citations, clearly showing that in Yourdon's mind at least, the simple recollections of these folks are easily on par with any formal, written works.

Yourdon's causal approach does have drawbacks, however. Anytime a conversational style is employed there is a chance it will fall into rumor and innuendo. Yourdon does that occasionally since the distance between anecdotal evidence and half truths is small, but this doesn't detract from the book overall.

Other books provide erudite authority on Project Management and Software Engineering but Yourdon cuts through all that with a single statement. "It's amazing how many software projects take place without anyone having the faintest idea of who the owner is..." This is one of the many clues he provides readers on how to spot a Death March in progress.

Any software manager who wishes to bring maturity to their organization must first understand the problems inherent in their department and indeed most departments. The Death March provides an honest assessment of the state of software engineening today and gives the reader insight and understanding of how things are often allowed to go so terribly, terribly wrong.

This work isn't a substitute for the many good books available on software engineering theory and practice. It does, however, provide a welcome and sometimes comic relief for those of us who have lived through-or are living through-a Death March project. And, while such projects are not likely to disappear anytime soon, any software manager who reads this book will have a better understanding of the challenges associated with them.

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.

Yaa, this book gives you a very real life understanding of projects, "doomed to be failed". If you have read this book, you can understand the likely next step in the fateful project. This book should be read once, but use your own judgement in tackling the situation, if unfortunately caught into Death March.

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.

I bought this book when it came out in '97. I had read Yourdon's works in college and the title just caught my eye. Well, here it is folks - the year 2000 and some things just don't change. For those of you who have ever been on a death march project, it may have you saying "Has Yourdon been spying on ME at the office? :). It's good to know someone else can relate to what we software development folks go through when we're drafted into one of those blasted things. It's got the humor and important points all in the right mix. This is a must have!