5.0 out of 5 stars A New Classic for Business and IT!
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...
Published on Feb. 6 2004 by Jeffery Gainer
3.0 out of 5 stars Accurate But Not Practical
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...
Published on Oct. 21 2002 by A. Petrotchenkov
Most Helpful First | Newest First
4.0 out of 5 stars Good reading on the problem but generic on a solution ..,
This review is from: Death March (2nd Edition) (Paperback)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.
5.0 out of 5 stars A New Classic for Business and IT!,
This review is from: Death March (2nd Edition) (Paperback)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.
4.0 out of 5 stars Useful update to previous edition,
This review is from: Death March (2nd Edition) (Paperback)This book is worth it for the chapter on Critical Chain alone.
2.0 out of 5 stars Problem: Death March Project, Solution: Quite Your Job,
This review is from: Death March (2nd Edition) (Paperback)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.
5.0 out of 5 stars An excellent survival guide,
This review is from: Death March (2nd Edition) (Paperback)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.
5.0 out of 5 stars Great Book, useful examples,
This review is from: Death March (2nd Edition) (Paperback)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.
5.0 out of 5 stars Death march projects examined from all perspectives,
This review is from: Death March (2nd Edition) (Paperback)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."
1.0 out of 5 stars ADVICE FOR ED: RETIRE!,
By A Customer
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...
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.
4.0 out of 5 stars Perfect in a good economy. Waiting for new advice in 2 Ed.,
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!
5.0 out of 5 stars Essential reading for all involved in software development,
Most Helpful First | Newest First
Death March (2nd Edition) by Edward Yourdon (Paperback - Nov. 6 2003)
CDN$ 62.99 CDN$ 39.68