[chbot] Edward Yourdon and his take on the death-march

[Mark Atherton]

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

	or

"I thought it was only me"

-mark

=======

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."[1] 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."[2]

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 
productivity—despite 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 subtle—e.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 
functionality—i.e., the available 
features—usually 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 
failure—e.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 20–30 
people, who are involved in a project expected to take one to two years.

Large-scale projects— the project consists of 
100–300 people, and the project schedule is three to five years.

Mind-boggling projects— the project has an army 
of 1,000–2,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."[3]

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.

etc...