[chbot] Edward Yourdon and his take on the death-march
markaren1 at xtra.co.nz
Mon Jul 22 19:35:26 BST 2013
Just found this on Usenet.
... and being a long time fan of EY and his
methods, I thought it might be interesting
if only I had seen it 30 years ago
"I thought it was only me"
Chapter 1. Introduction
Happiness lies in being privileged to work hard
for long hours in doing whatever you think is
worth doing. One man may find happiness in
supporting a wife and children. And another may
find it in robbing banks. Still another may labor
mightily for years in pursuing pure research with no discernible results.
Note the individual and subjective nature of each
case. No two are alike and there is no reason to
expect them to be. Each man or woman must find
for himself or herself that occupation in which
hard work and long hours make him or her happy.
Contrariwise, if you are looking for shorter
hours and longer vacations and early retirement,
you are in the wrong job. Perhaps you need to
take up bank robbing. Or geeking in a sideshow. Or even politics.
Jubal Harshaw, in To Sail Beyond the Sunset
by Robert Heinlein (Ace Books, reprint edition, 1996)
What is a death march project? What makes IT
organizations create such things? Why would
anyone in his right mind agree to participate in such a project?
To many grizzled IT veterans, these are
rhetorical questions. Everything, in their
experience, is a death march project. Why do they
happen? Because corporations are insane and, as
consultant Richard Sargent commented to me,
"Corporate insanity is doing the same thing again
and again, and each time expecting different
results." And why do we participate in such
projects? Because, as consultant Dave Kleist
observed in an e-mail note, "Death march projects
are rarely billed as such, and it takes a lot of
work when being hired from the outside to
discover if your hiring company is prone to creating death march projects."
If you think the answers to these questions are
obvious, feel free to jump to the next chapter.
I'm sometimes think they are obvious, since most
people never ask me what I mean by "death march."
But if you're one of the people who has no idea
what I'm talking about, or wonder if this is a
book about military campaigns from World War II,
it may be worth the effort to pause for a moment
and contemplate what this is all about.
Death March Defined
Quite simply, a death march project is one whose
"project parameters" exceed the norm by at least
50 percent. In most projects, this means one or
more of the following constraints have been imposed upon the project:
The schedule has been compressed to less than
half the amount estimated by a rational
estimating process; thus, the project that would
normally be expected to take 12 calendar months
is now required to deliver its results in six
months or less. Because of the competitive
pressures of business competition in today's
global marketplace, along with the concept of
"Internet time" from the dot-com era of the
computer industry, this is probably the most
common form of death march project.
The staff has been reduced to less than half the
number that would normally be assigned to a
project of this size and scope; thus, instead of
being given a project team of 10 people, the
project manager has been told that only five
people are available. This may have come about as
a result of someone's naive belief that a new
programming language or application development
environment will magically double the team's
productivitydespite the fact that the team was
given no training or practice with the new
technology and probably wasn't even consulted
about the decision to use the technology in the
first place. Unfortunately, it's happening far
more often, as this edition of Death March is
being written in the spring of 2003, because of
the ongoing economic recession and the associated cutbacks in IT budgets.
The budget and associated resources have been cut
in half. Again, this is often the result of
downsizing and other cost-cutting measures, but
it can also result from competitive bidding on a
fixed-price contract, where the project manager
in a consulting firm is informed by the marketing
department that, "the good news is that we won
the contract; the bad news is that we had to cut
your budget in half in order to beat out the
competitors." This kind of constraint often has
an immediate impact on the number of project team
personnel that can be hired, but the consequences
are sometimes a little more subtlee.g., it may
lead to a decision to hire relatively
inexpensive, inexperienced junior software
developers, rather than higher-cost veterans. And
it can lead to a pervasive atmosphere of
penny-pinching that makes it impossible for the
project manager to order pizza for the project
team when they spend the entire weekend in the office working overtime.
The functionality, features, performance
requirements, or other technical aspects of the
project are twice what they would be under normal
circumstances. Thus, the project team may have
been told that it needs to squeeze twice as many
features into a fixed amount of RAM or disk space
as its competitor; or it may have been told its
system has to handle twice the volume of
transactions that any comparable system has ever
accomplished. The performance constraints may or
may not lead to a death march project; after all,
we can always take advantage of cheaper, faster
hardware, and we can always search for a more
clever algorithm or design approach to accomplish
the improved performance. But doubling the
functionalityi.e., the available
featuresusually means doubling the amount of
work that has to be carried out; that does lead to a death march project.
The immediate consequence of these constraints,
in most organizations, is to ask the project team
to work twice as hard and/or twice as many hours
per week as would be expected in a "normal"
project. Thus, if the normal work-week is 40
hours, then a death march project team is often
found working 14-hour days, six days a week.
Naturally, the tension and pressure escalate in
such environments, so that the death march team
operates as if it is on a steady diet of Jolt cola.
Another way to characterize such projects is as follows:
A death march project is one for which an
unbiased, objective risk assessment (which
includes an assessment of technical risks,
personnel risks, legal risks, political risks,
etc.) determines that the likelihood of failure is 50 percent.
Of course, even a project without the schedule,
staff, budget, or functionality constraints
described above could have a high risk of
failuree.g., because of hostile politics between
the IT department and the user community. But
most commonly, the reason for the high risk
assessment is a combination of the constraints described above.
Categories of Death March Projects
Not all death march projects are the same; not
only do they involve different combinations of
schedule, staff, budget, and functionality
constraints, but they come in different sizes, shapes, and flavors.
In my experience, size is the most important
characteristic that distinguishes one death march
project from another. Consider four different ranges of projects:
Small-scale projects the team consists of three
to six people who are working against nearly
impossible odds to finish a project in three to six months.
Medium-size projects the team consists of 2030
people, who are involved in a project expected to take one to two years.
Large-scale projects the project consists of
100300 people, and the project schedule is three to five years.
Mind-boggling projects the project has an army
of 1,0002,000 or more (including, in many cases,
consultants and subcontractors), and the project
is expected to last seven to ten years.
For several reasons, the small-scale death march
projects are the most common in the organizations
that I visit around the world today; happily,
they have the greatest chance of succeeding. A
tightly knit group of three to six people is more
likely to stick together through thick and thin,
and this same group of highly motivated people is
more likely to be willing and able to sacrifice
their personal lives (as well as risk their
health!) for three to six months if they know
that the regimen of long nights, wasted weekends,
and postponed vacations will come to an end in a matter of months.
The odds of successful completion drop noticeably
with the medium-size projects and disappear
almost completely with the large-scale projects.
With larger numbers of people involved, it's more
difficult to maintain a sense of cohesive team
spirit; and the statistical odds of someone
quitting, being run over by a beer truck, or
succumbing to the various perils of modern
society increase rapidly. What's crucial here is
not just the number of people involved, but the
time-scale: Working 80-hour weeks for six months
may be tolerable, but doing it for two years is
much more likely to cause problems.
As for the "mind-boggling" death march projects:
One wonders why they exist at all. Perhaps the
systems development efforts associated with the
NASA project that landed a man on the moon in
1969 could be considered a successful example of
a death march project; but the vast majority of
such projects are doomed from the beginning.
Fortunately, most senior managers have figured
this out, and most large organizations (which are
the only ones that could afford them in the first
place!) have banned all such projects. Government
organizations, alas, still embark upon them from
time to time; along with potentially unlimited
budgets with which to tackle truly mind-boggling
projects, appeals to patriotic notions (e.g.,
"national security" in the post-9/11 era) may be
sufficient to blind senior management to the
futility of the task they've been given.
In addition to project size, it's also useful to
characterize the "degree" of a death march
project by such criteria as the number of
user-organizations that are involved. Things are
hard enough when the project team has to satisfy
only one user or one group of homogeneous users
within a single department. Enterprise-wide
projects are usually an order of magnitude more
difficult, simply because of the politics and
communication problems involved in
cross-functional activities of any kind. As a
result, the systems development projects
associated with business re-engineering projects
often degenerate into a death march; even though
the development effort is modest in terms of
hardware and software effort, the political
battles can paralyze the entire organization and
cause endless frustration for the project team.
Finally, we can distinguish between projects that
are incredibly difficult and those that are
fundamentally impossible. As John Boddie, author of Crunch Mode, points out,
The combination of excellent technical staff,
superb management, outstanding designers, and
intelligent, committed customers is not enough to
guarantee success for a crunch-mode project.
There really are such things as impossible
projects. New ones are started every day. Most
impossible projects can be recognized as such
early in the development cycle. There seem to be
two major types: "poorly understood systems" and "very complex systems."
This still leaves unanswered the questions of why
a rational organization would embark upon such a
project and why a rational project manager or
technical person would agree to participate in
such a project. We'll deal with those questions below.
More information about the Chchrobotics