death-march projects · 2009. 9. 16. · tool checklist n email, groupware tools n prototyping/rad...

Death-MarchProjects

ICSE conference — May 20, [email protected]

http://www.yourdon.com

2Copyright © 1996 by Edward Yourdon

An informal surveyN In general, our projects are:

N Under budget and ahead of schedule

N About 10% over budget, 10% behindschedule

N About 50-100% over budget, 50-100%behind schedule

N Substantially more than 100% overbudget, 100% behind schedule


Death-March definitionsN Definition 1: Project parameters exceed the

norm by >50%3 Schedule compression (most common)

3 Staff reduction

3 Budget/resource constraints

3 Functionality/performance demands

N Definition 2: risk assessment (technical,legal, political, etc.) indicates >50% chanceof failure

N Observation: this is now the norm, not theexception


Different kinds of Death-March projects

N Small-scale: 3-6 people for 3-6 months

N Large-scale: 100-200 people for 3-5years

N Mind-boggling: 1,000 - 2,000 peoplefor 7-10 years


Why Do Death-MarchProjects Occur?

N The technical answer: we’re dumb3We don’t practice software engineering3We don’t use the right methods and tools3We don’t know how to estimate our projects

N The “don’t blame us” answer:3it’s all the fault of Machiavellian managers3Managers are evil, and they cunningly force us to take

on 12-month projects with a 6-month deadline

N The sobering reality: whatever the reason, thishas now become the “norm,” not the exception


Why Do Death-Marches Occur?N Politics, politics, politicsN Naive promises made by marketing, senior executives,

project managers, etc.N Naive optimism of youth: “we can do it over the weekend”N “Startup” mentalityN “Marine Corps” mentality: “real men don’t need sleep”N Intense competition caused by globalization of marketsN Intense competition caused by appearance of new

technologiesN Intense pressures caused by unexpected government

regulationsN Unexpected and/or unplanned crises — e.g., your vendor

went bankrupt, or your 3 best programmers just died ofBubonic Plague


Why Would Anyone Want to be Involvedin a Death-March?

N Risks may be high, but so are the rewards

N The thrill of the challenge

N The naivete and optimism of youth

N The alternative is unemployment

N The alternative is bankruptcy or some othercalamity

N The project will provide training in valuable newtechnologies and skills, and then you can quit!

N Revenge


Determining the Basic Nature of theDeath-March Project

chances of success

happiness

Key point: get the project team members to indicate wherethey think they fit into this grid.

suicide

missionimpossible

kamikaze

ugly


How to Survive?N “What is the one thing you feel would be most

important advice for a project manager to dowhen involved in a “mission impossible”project?”

N “What is the one thing you feel would be mostimportant for a project manager to avoid doingwhen involved in a mission impossible project?”

N It’s usually a combination of:3 negotiating techniques

3 peopleware

3 processes (and project management)

3 tools/technology


Tools for rational Death-Marchnegotiations

N Estimating tools — e.g., SLIM, ESTIMACS,and other commercial products

N System dynamics models, e.g., TarekAbdel-Hamid’s model in iThink

N Copies of The Mythical Man-Month for allconcerned

N Time-boxing to see how feasible/infeasiblethe project constraints really are


Rational negotiations, cont’d

N Beware the temptation to give up... e.g.,

N “We have no idea how long this project willreally take, and it doesn’t matter, sincethey’ve already told us the deadline...

N ...so we’ll just work 7 days a week, 24hours a day, until we drop fromexhaustion. They can whip us and beat us,but we can’t do any more than that...”


Negotiating gamesN Doubling and add some...N Reverse doublingN Guess the Number I’m Thinking of...N Double Dummy SpitN The X-Plus GameN Spanish InquisitionN Low BidN Gotcha — throwing good money after badN Chinese Water TortureN Smoke and Mirrows/Blinding with Science

3 thanks to Rob Thomsett, “Double Dummy Spit, and OtherEstimating Games”, American Programmer, June 1996


What to do when rationalnegotiation breaks down

N Quit (the project or the company)

N Appeal to a higher authority

N Determine your own constraints

N Redefine the project as a kamikaze, suicide, etc.,and make sure entire project team knows it.

N Key point: project leader has to believe in thepossibility of achieving project goals

N ...and must be able to convince team memberswithout “conning” them


Quitting and the “social contract”

N Traditional corporate culture used to be basedon “a job for life” — like marriage, till death dous part...

N Which meant that we were expected to put upwith a lot of grief in death-march projects

N But many employers have already indicated thatthe “social contract” is no longer valid...

N If the employer threatens to fire you if death-march project fails, then you should be equallycold-blooded if you’re given impossibleconstraints for the project


DEATH-MARCHPEOPLEWARE ISSUES

N Hiring and staffing issues: putting the bestpossible people on the project

N Identifying loyalty and commitment issues:oneself, family, project, company, etc.

N The importance of communicatingurgency, priorities, constrains, risks

N Team-building issues: team roles, “gel”,keeping teams together, etc.


Hiring and Staffing Issues

N Strategy #1: hire superstars and turn themloose

N Strategy #2: insist on a well-honed“mission impossible” team that hasworked together before

N Strategy #3: choose mere mortals, butmake sure they know what they’re gettingin for

N Strategy #4: take whoever you’re given andconvert them into a mission-impossibleteam


Hiring and Staffing, cont’dN Risk increases substantially if project

manager can’t choose his/her teammembers

N Crucial to avoid losing people during theproject; highly desirable not to add newpeople during project

N What to do if you can’t choose your ownteam:3 Quit3 Appeal to a higher authority3 Determine your own constraints3 Redefine the project as a kamikaze, suicide, etc., and make sure

entire project team knows it.


Question:N You’re half-way through a death-march

project, and the latest status report makesyou realize that the odds of failure haveincreased significantly — to perhaps 90%.

N What is the one thing you feel would bemost important advice to do at this point,from a peopleware perspective?

N What is the one thing you feel would bemost important for to avoid doing at thispoint?


My answers:N Do communicate the status to the key

players. If the project is allowed tocontinue, then triage mercilessly —but cut non-critical “features,” not keyprocesses (like testing).

N Don’t lie to your project team. They’renot idiots — they read “Dilbert.”


DEATH-MARCH PROCESSES

N Formal vs informal processes

N Getting the team to “own” the process

N SEI models vs. “mad-world” models

N Prototyping

N Using simulation models to explore theimpact of different process strategies

N Best practices, worst practices, andbreathalyzer test


Formal vs. Informal ProcessesN Formal processes are great if you know what you’re

doing...

N ...and if you’ve done the same thing several times before

N Watts Humphrey: “if a process can’t be used in a crisis, itshouldn’t be used at all.”

N But many death-march projects involve doing things thathave never been done before — with teams that havenever worked together before.

N Nevertheless, team needs to agree on what processeswill be formalized (e.g., change management, sourcecode control, testing(?)), and what processes will bedone on a completely ad hoc basis.


Getting the team to “own” the process

N In a death-march project, it’s pointless forMethodology Police to mandate a formalsoftware process if it’s not going to befollowed

N Which either means that project managermust impose it in a dictatorial fashion...

N ...or the team must sincerely agree toadopt it, because they believe in it.

N A corollary: it’s usually a disaster tointroduce a new, unfamiliar process in andeath-march project.


Question:N Howard Rubin and I conducted a World-Wide

Benchmarking Survey for the government ofCanada in 1995, in which we found productivitydifferences of 200-to-1 at the organizational level

N What is the one thing you feel would be the mostimportant way of accomplishing this in terms ofchanging/adapting/improving processes?

N What is the one thing you feel would be the mostimportant thing to avoid in terms ofchanging/adapting/improving processes?


My answers:N Do reuse

N Do triage — early and often, with fulluser involvement

N Don’t implement any softwareprocess that buries the developers inpaper, or activities that are not part ofthe “by-product” of the work theyneed to accomplish.


DEATH-MARCHTOOLS

N Identifying a minimal toolset

N A checklist of tools for prototyping, CM,groupware, testing, etc.

N The risks of choosing new tools in andeath-march project.


Identifying a minimaltoolset

N Death-march projects must be allowed to chooseits own tools, regardless of whether it conformsto organizational standards

N ...but team members need to agree on commontools within the project — otherwise, chaos willoccur

N Unless team has worked together before onseveral projects, this implies a “minimal” set oftools that everyone will use


Tool checklistN Email, groupware tools

N Prototyping/RAD development tools

N Configuration management/version control

N CASE tools for analysis/design?

N Requirements management tool!!

N Testing, debugging tools

N Project management (estimating, scheduling,PERT/GANTT, etc)

N toolbag of reusable components


Risks of choosing new toolsN Some death-march projects grab new tools as a

“silver bullet” to accomplish much higher levelsof productivity than would otherwise bepossible...

N ...but they ignore the learning curve, confusion,and political debates associated with theintroduction of new tool

N And the tools are often so new that they don’teven work properly yet

N An irony: new tool sometimes is the straw thatbreaks the camel’s back — and project failure isthen blamed on the tool


DEATH-MARCH AS A WAYOF LIFE

N What if this is the first of many death-march projects?

N Establishing an death-march “culture”in the organization

N Death-march training and annualvisits to the death-march “flightsimulator”


What if this is the first of manyDeath-March projects?

N Because the company is in the midst ofongoing crises...

N ...or management/customers have adoptedthis as their negotiating position

N Or (in software/consulting firms) it’s part ofthe company’s “strategic advantage”

N Key question: having survived one death-march project, would you do it again?

N Important to ask this question early


Establishing a death-march“culture” in the company

N Presumes that death-march is a conscious strategy

N May have an impact on hiring strategies — e.g.,preference for young, unmarried, anti-social workaholictechno-nerds

N May have an impact on formal career advancementpolicies — e.g., “if you survive a death march for 7 years,we’ll make you a partner.”

N Also impacts project management strategy — e.g., shouldmanagers plan to “burn out” their team members anddiscard them at the end of the death-march project?

N Should be accompanied by formal training, so that newrecruits understand it’s proactive rather than reactive


Death-March TrainingN Currently consists of OJT and osmosis —

if you survive one death-march project,you’ve become a veteran

N Management training consists of twowords: “good luck”

N Suggestion: consider annual visits to adeath-march “flight simulator”


ConclusionN For many of us, death-march projects are

inevitable in today’s crazy times

N Interesting question is whether yourcompany acknowledges it...

N Succeeding with death-march projects isobviously desirable, but surviving them isalso important!

N Recognize that younger generation ofsoftware people may have differentattitudes about this than older generation

Death-MarchProjects

ICSE conference — May 20, 1997

[email protected]

http://www.yourdon.com

death-march projects · 2009. 9. 16. · tool checklist n email, groupware tools n prototyping/rad...

Documents