<< 1 >>
Rating: 
Summary: Problem: Death March Project, Solution: Quite Your Job
Review: 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.
Rating: 
Summary: Death march projects examined from all perspectives
Review: 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."
Rating:
Summary: Software development is a defective industry
Review: 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!
Rating:
Summary: A New Classic for Business and IT!
Review: 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.
Rating:
Summary: A New Classic for Business and IT!
Review: 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.
Rating:
Summary: An excellent survival guide
Review: 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.
Rating:
Summary: You'll find yourself shaking your head 'yes' when reading...
Review: 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.
Rating: 
Summary: Useful update to previous edition
Review: This book is worth it for the chapter on Critical Chain alone.
Rating:
Summary: Great Book, useful examples
Review: 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.
Rating:
Summary: Good reading on the problem but generic on a solution ..
Review: 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.
<< 1 >>
|
