Programming Books C Java PHP Python Learn more Browse Programming Books
Qty:1
  • List Price: $59.99
  • Save: $21.66 (36%)
In Stock.
Ships from and sold by Amazon.com.
Gift-wrap available.
Death March (2nd Edition) has been added to your Cart
FREE Shipping on orders over $35.
Condition: Used: Good
Comment: Solid used copy with visible wear. FREE SHIPPING w/AMAZON PRIME!
Access codes and supplements are not guaranteed with used items.
Trade in your item
Get a $2.00
Gift Card.
Have one to sell? Sell on Amazon
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Death March (2nd Edition) Paperback – November 16, 2003

ISBN-13: 978-0131436350 ISBN-10: 013143635X Edition: 2nd

Buy New
Price: $38.33
31 New from $30.00 35 Used from $9.48
Amazon Price New from Used from
Paperback
"Please retry"
$38.33
$30.00 $9.48
Free%20Two-Day%20Shipping%20for%20College%20Students%20with%20Amazon%20Student


Frequently Bought Together

Death March (2nd Edition) + The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) + Peopleware: Productive Projects and Teams (3rd Edition)
Price for all three: $99.74

Buy the selected items together

Customers Who Bought This Item Also Bought

NO_CONTENT_IN_FEATURE

Shop the new tech.book(store)
New! Introducing the tech.book(store), a hub for Software Developers and Architects, Networking Administrators, TPMs, and other technology professionals to find highly-rated and highly-relevant career resources. Shop books on programming and big data, or read this week's blog posts by authors and thought-leaders in the tech industry. > Shop now

Product Details

  • Paperback: 256 pages
  • Publisher: Prentice Hall; 2 edition (November 16, 2003)
  • Language: English
  • ISBN-10: 013143635X
  • ISBN-13: 978-0131436350
  • Product Dimensions: 9.2 x 7 x 0.5 inches
  • Shipping Weight: 14.4 ounces (View shipping rates and policies)
  • Average Customer Review: 3.9 out of 5 stars  See all reviews (76 customer reviews)
  • Amazon Best Sellers Rank: #151,142 in Books (See Top 100 in Books)

Editorial Reviews

Amazon.com Review

Death march projects are becoming increasingly common in the software industry. The symptoms are obvious: The project schedule, budget, and staff are about half of what is necessary for completion. The planned feature set is unrealistic. People are working 14 hours a day, six or seven days a week, and stress is taking its toll. The project has a high risk of failure, yet management is either blind to the situation or has no alternative. Why do these irrational projects happen, and what, other than pure idiocy, leads people to get involved in them?

Edward Yourdon has produced a wise and highly readable book on the entire death march phenomenon and the best way to steer through one. He takes a close look at the types of projects that often become death marches and the corporate politics and culture that typically produce them; Yourdon helps you examine your own motivations and those of corporate managers who enable death marches to take shape.

Much of Death March is about the human element of highly stressful projects. The author's plain-spoken observations on the dysfunctional organization--the Machiavellian politics, naive optimism, lust for power, fear, and sheer managerial stupidity that guide so many death marches--make for a refreshing change from other project management books. You'll also find much practical advice to help you survive, everything from negotiating with upper management to breathing life into faltering projects. He'll even help you determine if you should look for another job.

If you've ever worked in a death march situation or been a client of a company addicted to death march management, this book will help you understand what happened. More importantly, it will help you prepare for future encounters with death marches. Death March is highly recommended for anyone involved in software development. --This text refers to an out of print or unavailable edition of this title.

From the Inside Flap

PrefaceOur achievements speak for themselves. What we have to keep track of are our failures, discouragements, and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay.— Eric Hoffer
Reflections on the Human Condition, aph. 157 (1973)

I know . . . you're intrigued by the title of this book, and you decided to peek inside to see what it's all about. But, you're busy, busy, busy — and you don't know if you have the time to read yet another book about managing software projects. Especially if it's a book that tells you how things should be done in an ideal world where rational men and women make calm, sensible decisions about the budget, schedule, and resources for your software project.

However, you may have noticed that we don't live in an ideal world — and chances are that your project requires you to interact with people who seem anything but rational and whose decisions hardly seem calm or sensible. In other words, you're working on a death march project. The wonderful thing about the title of this book is that I don't even have to explain it. Every time I mention it to friends and colleagues, they just laugh and say, "Oh, yeah, you must be talking about my project!"

These days it's likely to be my project, and your project, and everyone else's project too — we're all working on death march projects. It seems to me that the first question you should be asking yourself (though it may not occur to you until the end of your project) is: "Why on earth did I let myself get suckered into such a project?" I'll discuss this in the first chapter, because my experience as a consultant — visiting and observing many such projects from the sidelines — is that the world would be a healthier place if more of us had the guts to stand up and say, "Hell, no! I won't join this death march!"

But, assuming there's no escape — e.g., there are no other jobs available or you've got some form of a "golden handcuff" relationship with your employer that strongly discourages you from leaving — the next question is: "How can I survive this project without ruining my health, my sanity, and my dignity?" If you're an optimist, you might even be wondering how you can conquer the obstacles before you to finish the death march project on time and under budget. But, if you've been through a number of these projects before, you probably know that the odds are stacked against you and that survival is the best you can hope for.

Having worked in the software industry for over 30 years, I find that our profession has a rather interesting reaction to death march projects. In some parts of the industry, especially in Silicon Valley, such projects are glorified as a test of fortitude, somewhat akin to climbing Mount Everest barefoot. I felt this way during my first few software projects back in the mid-1960s, and the fact that the same attitude prevails a generation later suggests to me that it's likely to be a permanent phenomenon, as long as technology continues to change as rapidly as it has been during my lifetime. Ours is not a mature industry. Every year there's a new Mount Everest to climb and a new crop of hotshot programmers who are convinced that they can run barefoot all the way to the top.

Another segment of our industry, however, regards death march projects as embarrassing failures. We've all been bombarded with statistics about the prevalence of schedule delays, budget overruns, buggy software, disgruntled users, and outright project failures. We've been told repeatedly by consultants, gurus, and methodologists that the reason for all these embarrassments is that we've been using the wrong methods (or no methods at all), or the wrong tools, or the wrong project management techniques. In other words, death march projects exist because we're stupid or incompetent.

If you talk to battle-scarred veterans in the field — the ones who have gone through a couple of death march projects and have learned that it's really not fun to climb Mount Everest barefoot — you'll often hear them say, "Hey! I'm not stupid! Of course I would like to use the right methods and tools and project management approaches. But, my senior management and my end users won't let me. The reason we have such a ridiculous schedule for this project is that it was imposed upon us on the first day, before we had the faintest idea what the project was all about!" Conclusion: Death march projects occur because senior managers are Machiavellian bastards and/or because our users are naive and unrealistic.

No doubt there's some truth to all this. We do make a lot of stupid mistakes managing our projects, our senior managers do indulge in ridiculous political games, and our end users do make unreasonable demands on us. I'm convinced that much of this is due to the rapid pace of change, combined with the usual disrespect that each new generation has for the advice offered by the previous generation. Why on earth should today's generation of Java-oriented hotshots pay any attention to the advice offered by my generation, whose formative programming experience took place 30 years ago in Autocoder and assembly language? And, how should today's generation of business users know what kind of Web-based application is reasonable to ask for, considering that their predecessors were asking for mainframe-based, on-line systems, with character-based, dumb-terminal interfaces?

Whatever the explanation for the phenomenon, I've come to a sobering conclusion: Death march projects are the norm, not the exception. I think that today's software developers and project managers are pretty smart and are eager to manage projects in a rational way; I also think that today's business users and senior managers are much more computerliterate than they were a generation ago and much less naive about what software developers can be expected to deliver with finite resources. That doesn't stop both groups of smart individuals from embarking upon yet another death march project — because the competitive business pressures demand it and the new technological opportunities invite it. The business managers may be fully aware that a rational schedule for their new system would require 12 calendar months, but they'll also tell you emphatically that unless it's available in six months, the competition will grab the entire market for their new product or service. And, the technical staff may be fully aware that new technologies like the Internet are still quite risky, but they will tell you that if the new technology does work, it will provide a strategic competitive advantage that makes it well worth the risk.

To put it another way, industry surveys from organizations such as the Standish Group, as well as statistical data from metrics gurus such as Capers Jones, Howard Rubin, Paul Strassmann, and Larry Putnam, suggest that the average project is likely to be 6 to 12 months behind schedule and 50 to 100 percent over budget. The situation varies depending on the size of the project and various other factors, but the grim reality is that you should expect that your project will operate under conditions that will almost certainly lead to some degree of death march behavior on the part of the project manager and his or her technical staff. If a project starts off with these high-risk factors, there's going to be a lot of overtime and wasted weekends, and there's likely to be a lot of emotional and physical burnout before the end of the project. Even if the project begins in a reasonably calm, rational fashion, there's a good chance that it will deteriorate into a death march project as time goes on — either because the original schedule and budget will turn out to have been highly unrealistic, or because the user will add more requirements to those upon which the original schedule and estimate was based.

So the real questions are: If you can't avoid death march projects, how can you survive them? What should you do to increase your chances of success? When should you be willing to compromise — and when should you be willing to put your job on the line and resign if you can't get your way? That is what this book is about. As you will come to realize, the solution will involve issues of peopleware, processes and methodologies, as well as tools and technologies. If you're going to manage a death march project, should you insist on the freedom to staff the team with people of your own choosing? Should you take a hard-line approach with process methodologies like the SEI-CMM model, or should you let the project team abandon all formal methodologies if they feel it will help them accomplish the job? Should you insist on adequate programming languages, workstations, and CASE tools — or is it more important to fight your political battles over the issues of people and processes?

These issues are as relevant to the manager in charge of the project, as they are to the technical staff that actu --This text refers to an out of print or unavailable edition of this title.


More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

3.9 out of 5 stars

Most Helpful Customer Reviews

28 of 30 people found the following review helpful By Thomas Duff HALL OF FAMETOP 500 REVIEWERVINE VOICE on January 3, 2004
Format: 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.
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.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
30 of 34 people found the following review helpful By Linus W Freeman on July 19, 2001
Format: Paperback
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.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
16 of 17 people found the following review helpful By Lee on November 18, 2000
Format: Paperback
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.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
14 of 15 people found the following review helpful By Texas Techie on January 24, 2005
Format: Paperback
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!
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Recent Customer Reviews