Death March (2nd Edition) Paperback – Nov 6 2003
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
Getting the download link through email is temporarily not available. Please check back later.
To get the free app, enter your mobile phone number.
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
Our 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.
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!" Well, 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, or so it seems.
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 and actually 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 manhood, 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.
But another segment of our industry 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 online 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 computer-literate 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 its 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, and Larry Putnam, suggest that the average project is likely to be six 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 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.
So the real question is: If you can't avoid death march projects, how can you survive them? What should you do to increase your chances of success? Where should you be willing to compromise—and when should you be willing to put your job on the line and plan to resign if you can't get your way? That is what this book is about. These issues are as relevant for the manager in charge of the project as they are for the technical staff that actually does the hard work of designing, coding, testing, and documenting the system. I'll address both groups in the chapters that follow.
A word about managers and technical staff members: Some of the comments you'll see in the following chapters will imply that management is "evil" and that the project team members are innocent, downtrodden victims. Obviously, this is not the case for all projects and all companies, though the very existence of a death march project is usually the result of a conscious management decision. While the project team members may be willing participants in such projects, they usually don't propose them in the first place.
If you've decided at this point that you don't have time to read this book, here's a simple word of advice that may provide some value for the time you've invested in reading the preface: triage. If you're on a death march project, it's almost certain that you won't have the resources to provide all the functionality or "features" requested by the end-user within the allotted schedule and budget. You'll have to make some cold-blooded decisions about which features to sacrifice and which ones to focus your resources on. Indeed, some of the frivolous features will never be implemented, so it's best to let them die on their own. Other features are important but also relatively easy to implement, e.g., because they're a by-product of the vendor-supplied class library or Computer-Aided Software Engineering (CASE) tools that you're using. To use the medical metaphor of triage, these features will survive on their own. The difference between success and failure on a death march project often lies in the project team's ability to identify the critical features of the system that would "die" without an investment of substantial resources and energy.
Of course, there's more to surviving a death march project than just triage. I'll cover triage in Chapter 3, but we also need to look at peopleware issues, "process" issues, and issues of tools and technology. I've tried to be as concise as possible , so you should be able to finish the whole book in a couple of hours; if nothing else, it should give you a more realistic assessment of your next death march project.
However, please don't get the impression that this book is a "bible," or that it will provide "silver bullet" solutions to all of your problems. There are no guaranteed "right answers" in this book; what works in some companies and in some situations may not work in others. Equally important: the compromises that some managers and technical staff members are willing to make will prove unacceptable to others. I'll make what I consider to be reasonable suggestions, but it's up to you to decide which ones will work in your environment.Even if you don't have enough money in your project budget to buy this book (such penny-pinching budgets are an indicator unto themselves of the risk associated with a death march project!), it won't cost you a penny to check the Death March Web page.
Whatever you decide to do, best of luck on your next death march project. And remember the words of Samuel Beckett:
Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.—Samuel Beckett, Worstward Ho (1984)See all Product Description
Top Customer Reviews
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.
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.
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.
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.Read more ›
Most recent customer reviews
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... Read morePublished on May 26 2004 by Hasan Alan Karatas
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. Read more
This book was a great read for anyone interested in understanding what the "death march" projects are all about. Read morePublished on Dec 23 2003 by Charles J. Bandy III
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. Read morePublished on Nov. 15 2003
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. Read morePublished on Oct. 11 2003 by Hari Thummalapalli
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... Read morePublished on April 30 2003 by Erik Gfesser
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. Read morePublished on March 28 2003 by Harold
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... Read morePublished on March 17 2003 by H. A Huffman
Look for similar items by category
- Books > Business & Investing
- Books > Computers & Technology > Computer Science > Software Engineering
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Computers & Technology > Project Management > PMP Exam
- Books > Computers & Technology > Software
- Books > Qualifying Textbooks - Fall 2007 > Business & Investing
- Books > Qualifying Textbooks - Fall 2007 > Computers & Internet