1 of 1 people found the following review helpful
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
1.0 out of 5 stars A Dreadful Book -- Avoid It
This books advice is typical of the comments I have heard from software people for the last 20 years. This sort of advice is also one of the reasons that software has death march projects and engineering disciplines do not. Engineering disciplines have developed mehtodologis which allow them work in a disciplined fashion to acheive realistic goals. It seems to be only...
Published on April 25 1999
Most Helpful First | Newest First
1 of 1 people found the following review helpful
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.
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.
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.
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."
4.0 out of 5 stars Perfect in a good economy. Waiting for new advice in 2 Ed.,
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!
4.0 out of 5 stars Prepare Yourself, or Become Yet Another Casualty,
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.
4.0 out of 5 stars Practical book on how to survive Mission Impossible projects,
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.
4.0 out of 5 stars How to improve your chances against impossible odds,
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.
4.0 out of 5 stars Insight into "the state of the art" in software development,
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.
5.0 out of 5 stars Essential item for your death-march survival pack,
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.
1.0 out of 5 stars A Dreadful Book -- Avoid It,
By A Customer
This books advice is typical of the comments I have heard from software people for the last 20 years. This sort of advice is also one of the reasons that software has death march projects and engineering disciplines do not. Engineering disciplines have developed mehtodologis which allow them work in a disciplined fashion to acheive realistic goals. It seems to be only in software that the irresponsible attitudes promtoed by this book prevail. It is because of these attitudes that it is nearly impossible to realistically size a software project. The attitude that discipline is a detriment to results rather than an enabler. Imangine a book that adivises a team leader to hide the truth of a project from the managemtn that is paying for it. Imagine a book that heaps contempt on fellow workers who do not share the juvenile ethos espoused by this book.
This is a dreadful book. It is a book which if uts advice is followed will foster death march projects not avoide them. This is a dreadful book. I am sorry that I was required by the conventions of this web page to give it one star. This seems to imply that there is at leat some merit in the book. There isn't any.
Most Helpful First | Newest First
Death March (2nd Edition) by Edward Yourdon (Paperback - Nov. 6 2003)
CDN$ 62.99 CDN$ 56.85