The book ‘
Death March’ starts by introducing death march project concepts, exploring
various causes and explaining why people participate in such projects. After having
worked on one such project, I have experienced first-hand almost all of the causes and
effects of a death march project that the author mentions.
A study of over 7000 development projects cited in the 1997 edition of
Computerworld,
stated that 55% were over budget (with cost overruns of more than 50%), 50% were late
(needing at least twice the estimated time), and 30% were incomplete (the product was
delivered with 50% or less of the planned functionality). These statistics were taken a
decade ago. So as I began reading the book, I thought that in the end, the author would
conclude that death march projects are likely to diminish because the industry is more
aware. But I was rather surprised that the author actually maintains throughout the book
that death march projects are the norm and will continue to be so, which was thought-
provoking.
The "politics" and "negotiations" chapters were engaging with ample lessons to be learnt.
I did not expect politics to be such an important factor in running a project smoothly.
What was interesting to read is the author’s description of death march projects from
differing perspectives of the key players namely the Owner, Customer, Shareholder,
Stakeholder, Champion. It made me realize the role and importance of a Champion.
Also, the negotiation games described were pragmatic. I understood how crucial
negotiations can be to a death march project and how they can be put to practice to
avoid projects from becoming death march projects such as the ‘Two out of three (cost,
schedule, quality)’ rule or the ‘10% change in project variable’ rule.
The thing I liked most about the book is that the author makes candid observations
about death march projects. The author mentions that some of the effects of a death
march project are lower self esteem, depression, and anxiety which I too have come
to witness while working on a death march project. Throughout the book the author
actually presents pragmatic ways of dealing with a death march project such as
not becoming too emotionally attached to the outcome of the project. I enjoyed
reading analogies that the author uses to compare death march projects such as
underground mining, cowboying, high rise window washing and the epitome –
spending a night in jail.
Almost everyone in the computer industry has noticed their workload increasing, while
at the same time the deadlines imposed by their supervisors are shortening. from a very
personal perspective of an individual member. In other words, a death march is just about
every project in these crazy days of compressed development cycles.
This book can be a very good tool to maintain a sense of perspective and help appreciate
the concerns of non- developers involved with the project.
The book then goes on to cover such significant topics as how a Death March project
team leader should negotiate with management for budget, working conditions, staffing,
etc.; how to handle the day-to-day issues of working on such a project, and, just as
importantly, when to know when it's time to get out.
I found this book to be remarkably refreshing in dealing with the true issues of working
in these sorts of environments, and it is far more practical than I had expected it would
be. The book has a Utilitarian approach. It is clearly written by someone who has "been
there" and has no use or time for trite answers. It would have been interesting to see some
of the examples in the book extended along these lines.
It is certain to occasion thousands of thoughtful debates all over the world. At the very
least, it will provide a great deal of practical advice for those "on the march" right now,
as well as at least some measure of relief by letting the participants know that they're not
alone.
In conclusion, I would say that the book adopts a very utilitarian perspective and
provides valuable guidance in identifying a death march project, understanding the
reasons behind it and the effects of it. The book also provides practical advice about
making an educated decision whether to get involved in a death march project or
not.
It hasn't stopped death march projects from taking place. And that death march projects
are likely to diminish. Death march projects are likely to be a common occurrence for
years to come. And that's the primary point of this chapter. You may not agree with any
of the rationales suggested here; you may not like any of the reasons for initiating such
projects or joining such projects—but they're real nonetheless. that such projects can be
an educational experience even if they fail
The books starts by exploring death march project concepts, introducing various causes
and reasons why people would join them. After looking at such projects from a very
personal perspective of an individual member, the author then presents several other
viewpoints - from the perspective of corporate politics and from the perspective of other
people involved in the death march team.
Although my personal experiences are different from one of the key ideas of the book,
that ‘
death march projects are the norm, not the exception‘, I recognised several of my
projects in the descriptions of ‘mission impossible‘ and ‘ugly‘.
Death March is quite a
thought-provoker, and it made me revisit my own dark experiences, thinking about what
we did and how we did it, why projects succeeded and failed, where we were wrong and
how not to do it again. Case studies in this book discuss problems common in software
development, so the proposed solutions are a good starting point for ideas that can be
applied to improve typical projects.
