PDF version of the "Managing Death March" projects keynote presentation that I'll be giving at the ProMAC 2013 conference in Hanoi on Nov 7, 2013

1. Death March
Project Management
Ed Yourdon
email: ed@yourdon.com
Website: www.yourdon.com
Blog: www.yourdonreport.com
Twitter, LinkedIn, Facebook, Flickr: “yourdon”
Hanoi, November 2013

2. Intro: what is a “death march” project?
Wikipedia definition (“death march”)
Current example: Obamacare website (see Oct 16, 2013
Bloomberg article, “The Obamacare Website Didn’t Have
to Fail. How to Do Better Next Time”)
Almost always: Significant schedule pressure –
project must be finished in far less than “nominal” time.
Often: Staffing shortages – project must be done with
significantly fewer people than in a “normal” project
Sometimes: budget limitations – inadequate funding to
pay for people, development tools, and other resources.
Inevitably: greater risks (>50% chance of failure), more
pressure, unpleasant politics
Almost always: heavy overtime (more than just 10-20%
extra effort), personal sacrifices, increased burnout,
higher turnover, lower productivity, lower quality
Increasingly often: significant corporate consequences
(e.g., bankruptcy), lawsuits, personal legal liabilities
2

3. Succeeding with death-march projects
Not: tyrannical behavior (which rarely works anyway)
Not: Breath-taking charismatic, visionary leadership.
Compatible with, but not the same as: extreme programming (XP), agile
methods, rapid application development (RAD), etc.
An appreciation that time is the most precious resource
Avoiding the squandering of time (usually raises political issues)
Requires appreciation of the dynamics of soft ware processes
Must help project team members manage their time effectively
Usually a combination of several things:
Sav vy "political" behavior — including the absolute necessity of breaking some
rules
Skillful negotiation of deadlines, budget, resources
Appropriate “peopleware” strategies
Appropriate system development processes (especially agile, perhaps also SEICMM, XP, etc)
Monitoring and controlling real progress on a day-by-day basis
Appropriate use of development tools & technologies
3

4. More on Steve Jobs
None of us can be exactly like Steve Jobs ... and it’s not clear
whether any of us would want to be exactly like him
But he achieved remarkable things, and it may be useful to adopt/adapt some
of his best ideas
Many of his successful accomplishments involved death-march projects
Suggestion #1: watch his 2005 Stanford commencement address. “Stay
hungry, stay foolish.”
Suggestion #2: See October 13, 2013 New York Times article, “And Then
Steve Said, ‘Let There Be an iPhone!’”
Watch Steve’s comments on the importance of passion
Read the Walter Isaacson biography, “Steve Jobs”
Some key ideas/concepts to think about:
Look for projects that will “put a dent in the universe”
Be demanding and brutally honest, to eliminate “B” players and have a project team
with only “A” players
Is it really necessary to be a mean, nasty, un-generous bastard to succeed?
Is the demand for perfection necessary, or is “good enough” really good enough?
Consider breaking rules in your organization!!!!!!!
4

5. If You’ve Got an iPhone
Project, You’d better Be Agile
Most of us will never have an “iPhone project” — ‘one is very
fortunate if you get to work on just one of these projects in
your career’
Some things to remember:
You won’t anticipate all of the technical problems that you’ll face
Some problems will seem insurmountable; initial design(s) will fail
The users will have no idea what their requirements are, for they will be
looking at something completely new
But they will change their opinions and expectations dramatically
Nevertheless, their opinions will change dramatically
Estimation is impossible, since it’s something never done before
Published under the GNU Free Documentation License (GFDL)
5

6. More on breaking rules
This is often a cultural/ethnic/national issue
And it may be a generational/age issue — e.g., younger employees might find
it easier to be rebellious, and break any rules they don’t like
It may be a question of degree: everyone is nervous, to some extent, about
confronting authority, inviting punishment, risking being fired, etc.
But it depends on the stakes: all of us would break rules — without
hesitation — to save our childrens’ lives
Perhaps I should say, “Reinterpret the rules to your advantage”
Or just, “Be brave!”
Examples of rules that you might break (or reinterpret)
Refusing to accept deadlines or schedules that are clearly impossible
Refusing to make project team work 9-to-5 hours in unproductive office environment
Refusal to allow/disallow (depending on situation) massive amounts of overtime
Refusal to wait for approval before allowing “morale budget” expenditures
Download (free) first four chapters of “Hacking Work: Breaking Stupid Rules
6
for Smart Results” — or buy the book on Amazon

7. 2. PROJECT POLITICS
Key questions for death march projects
Identifying owners, customers,
shareholders, and stakeholders in a death
march soft ware project
Stakeholder disagreement
Determining the basic nature of the project
Levels of commitment
A new idea: prediction markets
7

8. Identifying the players
Key point: your chances of success in a death march project are
often zero if you don’t know who the key players are
Also crucial that everyone on the project understands this – not
just the project manager
Typical players:
Owner: who pays for, or “
accepts” the system?
Customer: who will actually use the system?
Stakeholder: someone whose interests are affected by the success/failure of the
project, and who can affect the outcome of the project – and who may thus
become an ally or obstacle to project success. See “Project Clarity Through
Stakeholder Analysis,” by Larry Smith, Crosstalk: The Journal of Defense
Soft ware Engineering, Dec 2000
The "loser user"
Note: these roles may not be obvious, and they may shift during the
course of the project
8

9. Stakeholder disagreement
An observation from Tom DeMarco: incomplete,
ambiguous specifications are often a sign of
irreconcilable disagreements among stakeholders,
rather than incompetence on the part of systems
analysts
In addition, these disagreements invariably cause
significant project delays, which imperils the deadline.
One solution that project manager should try very hard
to implement: JAD sessions. (see Joint Application
Development for good discussion of techniques.)
If that's not possible, try to get a commitment from
stakeholders that all issues requiring their approval,
consent, or review will be resolved in no more than 24
hours. For a good example of this, see discussion of
“death march soft ware engineering” in the 100-day
projects carried out by Tom Love's ShouldersCorp.
9

10. Determining the Basic Nature
of the Project
h
a
p
p
i
n
e
s
s
kamikaze
suicide
mission
impossible
“Ugly”
chances of success
Key point: get the project team members to indicate where they think
they fit into this grid.
10

11. Levels of Commitment
The parable of the chicken and the pig
Remember that different members of the “key players” have
different levels of commitment...
... some of which may be publicly stated, and some of which
may not
... and all of this may change on a daily basis
A reminder: one of the primary reasons we succeeded with
Y2K is that (for the first time!) we actually had substantial
commitment from the CEO and the Board of Directors
11

12. Wisdom of crowds
Refers to the process of taking into account the collective opinion of a
group of individuals, rather than a single expert, to answer a question or
provide information
One popular example, involving collecting/gathering of information:
Wikipedia
Another popular example, involving non-experts to determine what
news is important, so that people outside the group can view the news
based on those ratings: Digg
But also used to for estimating/predicting outcomes and results (e.g.,
elections winners, likelihood of achieving a deadline/schedule, value of
coins in a jar, etc). Remember: such events may change dynamically!
Works best when crowd has: diversity, independence, decentralization,
and ability to aggregate judgments/opinions.
Group does not have to be cohesive; members do not even have to know
each other.
Failures more likely if crowd exhibits: homogeneity, centralization,
division (lack of access to other’s info), imitation, emotionality
12

13. Prediction markets
Basic concept: let “wisdom of the crowds” provide
assessment of likelihood of achieving deadlines and/or other
organizational goals
Currently being studied/researched by Google, Microsoft, and
other soft ware/IT organizations
See “Using Prediction Markets to Support IT Project
Management,” by Herbert Remidez and Curt Joslin
Basic idea: assign a value of, say, $1.00, to the achievement of a
specific goal (e.g., meeting a deadline)
And then let participants buy and sell “shares” of stock in a
fictional company trying to achieve that goal
If average price is $0.55, then there the “crowd” is saying there
is a 55% chance of achieving that goal.
A tool to consider: Inkling Markets (see case study from large
telecommunications company)
13

14. Details on Inkling Markets
Spoke recently to Adam Siegel,
adam@inklingmarkets.com
Hosted version of service uses U.S.-based hosting vendor
— not acceptable to many European/Asian IT
organizations
Hosted version of service costs $6 per user per month,
with minimum of 250 users. Volume discounts for larger
groups
“Installed” service (on your servers, behind your own
firewall) is $45,000 plus $4 per user per month, min 250
ppl
45-day free demo lets you try it at no risk
“Public” Web-based access is free, and you can create a
“private group” to try out the concept within your
organization
14

15. 3. PROJECT NEGOTIATIONS
Managing project definition at the beginning of
the project
Using project definition to manage requirements
creep
Estimating techniques
Tools for assisting estimation process
Tradeoffs bet ween schedule, budget, staff, quality
Tools for rational negotiation
Documenting political issues and decisions
What to do when rational communications are
impossible
15

16. Managing Project Definition:
What does “success” mean?
Many projects succeed/fail at the very beginning, before any tech. work is done.
Fundamental requirement: identifying who has the right to declare “success” – owner,
shareholder, etc, etc.
Typical definitions of “success”
finishing on time, or at least "reasonably close" to on-time
staying within budget, or at least not too far above the budget
delivering the required functionality, or at least a tolerable amount of functionality
providing “good enough” level of quality, in terms of "show-stopper" bugs
Providing adequate efficiency/capacity/performance to get the work done
getting the next round of VC funding, or launching the IPO
Key indicators of a doomed project:
Nobody can articulate what “success” means for this project…
…or it’s such a vague definition that it will be hard to demonstrate success
Key stakeholders cannot reach agreement on definition of success
The combination of these constraints may prove impossible to achieve – so the pragmatic
aspect of success often depends on agreement as to which areas can be compromised or
satisfied.
Biggest risk: lack of realistic triage at beginning of project
For more details, see my articles, “Spelling Success,” Computer world; and “Long-Term Thinking,”
Computer world; and “The Value of Triage,” Computer world
16

17. General concepts
"Good Enough"
Facebook’s version: “Move fast and break things”, and “Done is better than perfect.” (See Mark
Zuckerberg’s Feb 1, 2012 letter to investors: “the Hacker Way”)
Familiar concepts of Pareto Principle (the “80-20 rule”) are often ignored
Remember: "triage" is not the same as "prioritization"
Early triage is crucial
Documentation of good-enough standards is crucial
Functionality
Critical: without these functions, system can't be used at all
Important: without these functions, there will be substantial cost/problems
Desirable: without these functions, users will whine and complain
Quality
Defects by severity
Mean Time To Repair (MTTR) by severity level
Credible evidence of “convergence” to an acceptable level of quality
Performance (response time, throughput, volume, capacity, etc.)
Critical: failing this level means that daily/weekly workload can't be done
Important: failing this level means significant loss of productivity/capacity
Desirable: failing this level creates a noticeable, annoying impact
17

18. Estimating: Introduction
What is estimation? The calculated
approximation of a result (e.g., a completed
deliverable), even if the
input data is incomplete or uncertain
Estimation is not the same as negotiation
Estimation is not the same as a political
demand/decree that a project be finished on a
particular date
Traditionally, there have been many, many
problems with the way estimating has been
carried out in IT development projects...
Published under the GNU Free Documentation License (GFDL)
18

19. Problems with
traditional estimation
The estimate is actually a thinly-disguised acceptance of a political demand for
a specific completion date
The estimate is the result of a negotiating process analogous to haggling over
the price of a rug in a Middle East bazaar
The estimate is carried out by people with no experience in the details of the
work to be done — so it’s just a guess
The estimate is carried out by people who have a vested interest in achieving a
desired result, and/or who are susceptible to persuasion and “group-think”
Even if it’s acknowledged that the initial estimate is only approximate, the
“cone of uncertainty” is ignored — re-estimating is forbidden.
Stakeholders (managers, key customers, etc.) are extremely loath to
acknowledge the need for re-estimating
Even project leaders and IT professionals are often reluctant to re-estimate
Note: all of this has been well understood in the IT field for 30 years or more —
but we have rarely confronted the problem directly and chosen a different
approach
And there’s no guarantee that it will “magically” change just because someone
says “we’re agile now!”
19
Published under the GNU Free Documentation License (GFDL)

20. Agile Estimating
Initial estimate of entire project often necessary as a
result of “envisioning” activity
Key point: envisioning activity takes hours or days,
not weeks or months
Fundamental concept: accept the reality that the
initial estimate is likely to be quite inaccurate
Take advantage of “wisdom of the crowd”
Use techniques to reduce the likelihood of “group-think”
Revise estimates after every iteration/version/sprint
Use previous “
actuals” to guide future estimates
Resist temptation to promise future miracles/overtime
to compensate for past shortfalls
Published under the GNU Free Documentation License (GFDL)
20

21. Estimating Techniques
For complex projects, get a commercial estimating tool
Fundamental truth: to estimate a project you need metrics from
previous projects. Most IT organizations have almost no metrics about
previous death march projects.
Thus, most of what’s described as “estimating” is either “guessing” or
“negotiating” (see “Metrics and the Seven Elements of Negotiation,” by
Michael Mah, IT Metrics Strategies, April 2001)
Political reality: estimates are produced by people with little prior
estimating experience, and who have a vested interest in believing
their optimistic predictions
A radical suggestion: create a separate estimating group whose work is
judged and rewarded by accuracy of its estimates, not the political
acceptability of estimates
For a new approach to estimating, see “critical chain” approach, which
“pools” safety estimates across several tasks within a project.
Also, try the concept of “prediction markets”
21

22. Additional strategies
for estimating
System dynamics models, e.g., Tarek AbdelHamid’s model in iThink
Copies of The Mythical Man-Month for all
concerned
…or copies of Tom DeMarco’s The Deadline for
those who prefer a less serious book.
Estimating tools, such as COCOMO-2; also, COSTAR
and SLIM (Michael Mah) and SPR-20 and SEERSEM (see YouTube video)
Time-boxing to see how feasible/infeasible the
project constraints really are
22

23. Tradeoffs bet ween schedule, budget,
functionality, staff, quality
Key point: it’s not a linear tradeoff – see Fred
Brooks, The Mythical Man-Month (Addison-Wesley,
1995)
Relationship is a non-linear, third-order polynomial
relationship – see Larry Putnam and Ware Myers,
Measures for Excellence: Reliable Soft ware on Time,
Within Budget (Prentice-Hall, 1992)
Biggest risk: tradeoffs are usually negotiated, under
pressure, late in the project schedule – without
accepting the non-linear tradeoffs ...
... and without accepting the reality that much of the
partially-finished work will be lost forever
To negotiate tradeoffs rationally, you need to have
one of the estimating packages mentioned earlier
23

24. Project Negotiations
Even if the boss’ “estimate” seems reasonable, it’s
still a political demand
The boss has almost certainly not spoken with the
users about their detailed requirements
So he has no basis at all for the “estimate” he has
given you
More likely, his “estimate” is based on a similar
dialogue with someone else at the higher level of
executive politics where he spends his time
In any case, he is creating an environment in
which you know that the most you can hope for is
an “incremental” change in the proposed schedule
or budget
Published under the GNU Free Documentation License (GFDL)
24

25. Negotiating games
Doubling and add some...
Reverse doubling
Guess the Number
I’m Thinking of...
Double Dummy Spit
The X-Plus Game
Spanish Inquisition
Low Bid
Gotcha – throwing good money after bad
Chinese Water Torture
Smoke and Mirrors/Blinding with Science
thanks to Rob Thomsett, for his “Estimating Games” Web article
25

26. Estimating strategies
Don’t get tricked into making an “instant estimate” – ask for
time to think about (a week, a day, even an hour)
State the estimate in terms of confidence levels, or ± ranges,
etc.
Jim McCarthy (formerly of Microsoft, author of Dynamics of
Soft ware Development): make the customer, or other members
of the organization, share some of the uncertainty.
Project manager: “I don’t know precisely when we’ll finish –
but I’m more likely to be able to figure it out than anyone else in
the organization. I promise that as soon as I have a more
precise estimate, I’ll tell you right away.”
Do some reading and research to become better at this area,
e.g.:
Bargaining for Advantage: Negotiating Strategies for Reasonable
People, by G. Richard Shell (reissue edition, Penguin Books, June 2000)
Getting Past No: Negotiating Your Way from Confrontation to
Cooperation, by William Ury (Bantam Doubleday Dell, 1993)
26

27. Documenting political items
Document all of these key issues, as part of the permanent record –
other wise, you're likely to find that people “forget” unpleasant realities
that you told them about when the project began
Or even worse, the people who made commitments to you about key
political issues may have quit, died, retired, been fired, or gotten run
over by a crazy Hanoi motorcycle driver.
Key things to document (probably in a “project plan” document)
Background of the project (why is this project being carried out?)
Scope (what to leave in, what to leave out; use a context diagram for
simplicity)
Technical assumptions
Technical dependencies
Constraints
Project approach (what kind of development process will be used)
Quality approach
Development plan (resource schedule, project schedule, release schedule)
27

28. What to do when rational negotiation
breaks down
Remember Nancy Reagan's advice: “Just say no!”
Would you commit to running a marathon in one hour?
Quit (the project or the company)
Appeal to a higher authority
Go see the movie Gladiator, and learn to say, like Russell Crowe, “We
who are about to die salute you!”
Decide which “rules” you’re going to break in order to achieve an
“irrational” set of schedule/resource demands that have been imposed
upon you.
Redefine the project as a kamikaze, suicide, etc., and make sure entire
project team knows it.
Key point: project leader has to believe in the possibility of achieving
project goals
... and must be able to convince team members without lying to them
28

29. Succeeding with death-march projects
Not: tyrannical behavior (which rarely works anyway)
Not: Breath-taking charismatic, visionary leadership.
Compatible with, but not the same as: extreme programming (XP), agile
methods, rapid application development (RAD), etc.
An appreciation that time is the most precious resource
Avoiding the squandering of time (usually raises political issues)
Requires appreciation of the dynamics of soft ware processes
Must help project team members manage their time effectively
Usually a combination of several things:
Sav vy "political" behavior — including the absolute necessity of breaking some
rules
Skillful negotiation of deadlines, budget, resources
Appropriate “peopleware” strategies
Appropriate system development processes (especially agile, perhaps also SEICMM, XP, etc)
Monitoring and controlling real progress on a day-by-day basis
Appropriate use of development tools & technologies
29

30. Death March
Project Management
Ed Yourdon
email: ed@yourdon.com
Website: www.yourdon.com
Blog: www.yourdonreport.com
Twitter, LinkedIn, Facebook, Flickr: “yourdon”
Hanoi, November 2013