In der Softwareindustrie kommt es immer häufiger zu sogenannten "Death-March-Projekten". Die Symptome dieser "Todesmärsche" sind allgemein bekannt: Der Zeitplan, das Budget und die Zahl der Mitarbeiter des Projekts betragen ungefähr die Hälfte des zur Durchführung notwendigen. Die gesamte Planung ist schlichtweg unrealistisch. Gearbeitet wird 14 Stunden am Tag, sechs oder sieben Tage die Woche, und der Stress fordert seine Opfer. Das Aus ist bereits vorprogrammiert, das Management aber erkennt entweder die Situation nicht oder es hat keine Alternative. Die Frage ist die: Warum kommt es zu solchen irrationalen Projekten, und was -- wenn nicht reiner Unverstand -- veranlaßt Menschen dazu, sich auf derartige Projekte einzulassen?
Edward Yourdon hat über das Death-March-Phänomen und über die beste Methode, wie man es überlebt, ein geistreiches und höchst empfehlenswertes Buch geschrieben. Er untersucht die verschiedenen Arten von Projekten, die sich häufig zu "Todesmärschen" entwickeln, und die Arten der Unternehmenspolitik und -kultur, die sie typischerweise produzieren. Das Buch hilft Ihnen dabei, Ihre eigene Motivation zu überprüfen, und die der Unternehmensmanager, die solche "Todesmärsche" verursachen.
Vieles in Death March beschreibt die menschliche Seite von höchst nervenaufreibenden Projekten. Seine in einfacher Sprache gehaltenen Beobachtungen der funktionsgestörten Organisation -- machiavellistische Politik, naiver Optimismus, Machtstreben, Angst und schlichtweg stümperhaftes Management, die so viele "Todesmarsch-Projekte" begleiten -- unterscheiden sich in angenehmer Weise von anderen Werken zum Thema Projektmanagement. Zusätzlich gibt er noch viele nützliche Tips, die Ihnen dabei helfen, solche Projekte zu überstehen, angefangen von Verhandlungen mit dem Management bis hin zu dem Versuch, stockenden Projekten neues Leben einzuhauchen.
Wenn Sie schon einmal so eine Situation durchgemacht haben oder Kunde einer Firma mit Todesmarsch-Management waren, wird Ihnen dieses Buch dabei helfen, das Geschehene zu verstehen. Aber noch wichtiger: Es wird Ihnen helfen, sich auf eine zukünftige Begegnung mit "Todesmärschen" vorzubereiten. Death Marchist ein sehr empfehlenswertes Buch für jeden, der in der Softwareentwicklung arbeitet.
-- Dieser Text bezieht sich auf eine vergriffene oder nicht verfügbare Ausgabe dieses Titels.
Death March Second Edition
The #1 guide to surviving "doomed" projects...Fully updated and expanded, with powerful new techniques!
At an alarming rate, companies continue to create death-march projects, repeatedly! What's worse is the amount of rational, intelligent people who sign up for a death-march projectsaeprojects whose schedules, estimations, budgets, and resources are so constrained or skewed that participants can hardly survive, much less succeed. In Death March, Second Edition, Ed Yourdon sheds new light on the reasons why companies spawn Death Marches and provides you with guidance to identify and survive death march projects.
Yourdon covers the entire project lifecycle, systematically addressing every key issue participants face: politics, people, process, project management, and tools. No matter what your role--developer, project leader, line-of-business manager, or CxO--you'll find realistic, usable solutions. This edition's new and updated coverage includes:
- Creating Mission Impossible projects out of DM projects
- Negotiating your project's conditions: making the best of a bad situation
- XP, agile methods, and death march projects
- Time management for teams: eliminating distractions that can derail your project
- "Critical chain scheduling": identifying and eliminating organizational dysfunction
- Predicting the "straw that breaks the camel's back": lessons from system dynamics
- Choosing tools and methodologies most likely to work in your environment
- Project "flight simulators": wargaming your next project
- Applying triage to deliver the features that matter most
- When it's time to walk away
This isn't a book about perfectly organized projects in "textbook" companies. It's about your project, in your company. But you won't just recognize your reality: you'll learn exactly what to do about it.
Über den Autor und weitere Mitwirkende
Prolog. Abdruck erfolgt mit freundlicher Genehmigung der Rechteinhaber. Alle Rechte vorbehalten.
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...