team software project (tsp) july 24, 2007 cycle 2 requirements, standards & death marches

7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 1

Team Software Project (TSP)July 24, 2007

Cycle 2 Requirements,Standards

&Death Marches


Due today

Cycle 2 Requirements:Cycle 2 Requirements


Remaining Lectures Plan/Discussion

July 24 – Cycle 2 Requirements CompleteCycle 2 RequirementsDeath March Projects continuedProcess topics – Configuration Management -

July 31 – Cycle 2 Implementation CompleteSystem Test Plan BaselinedCycle 2 Design & ImplementationProcess topics – CMMI Details

August 7 – Cycle 2 Test CompleteCycle 2 Test CompleteOther topics TBD

August 14 - Course ReviewCycle 2 Post-Mortem CompleteCourse ReviewFinal

Death March Projects

From Death March by Edward Yourdon


Death March

Odds of a software project delivering on its committed schedule, budget & capabilities is extremely poor

Average Project6-12 months behind schedule

50-100% over budget

But Why?


How Do We Get Here?

Start:High risk factors:

• Optimism• Wishful thinking

Unrealistic schedule & budgetRealistic plan, but then it goes downhill

e.g. user adds requirements

Results:OvertimeWasted weekendsEmotional & physical burnout before the end


Key Takeaway

Confronted with joining a Death March project,Recognize & understand your own motivations, soyou can make a rational decision to join the team or look elsewhere for your next job.

You always have options!


Death March Defined

Project where an unbiased objective risk assessment (including technical, interpersonal & legal risks) determines the likelihood of failure at greater than 50%.

Death March projects are the norm, not the exception!


Common Root Causes

Compressed schedule (e.g. < ½ time estimated by a rational process)½ Staff of what a comparable project typically requires½ Budget & associated resourcesTwice the functionality, feature & performance requirements given

schedule, staff & budget constraints


Types of Death March ProjectsSize

Small< 10 people3-6 monthsMost common & greatest chance of success

How: small, tight knit, motivated group can totally sacrifice their personal lives, provided …They know the hardships (nights & weekends) will end in a few months

Medium20-30 people1-2 yearsLittle chance of success

Large100-300 people3-5 yearsNo chance of success


Reasons

Politics … ugly politics!Naïve promisesHysterical Optimism

e.g. Everyone in organization desperately wants to believe that a complex project, never before completed in < 3 years, can somehow be finished in 9 months.

Naïve optimism of youthNo problem, we can do it in a weekend!

Start-up mentality of fledgling, entrepreneurial companiesIntense competition

MarketsTechnologiesGovernment regulations

Unexpected &/or unplanned crises


Questions?

Why would anyone in his/her right mind agree to work on a death march project?

If a colleague of yours was to take on the task of managing a death march project, what is the one thing you would advise him/her to do?

To not do?


Reasons for signing up

High Risk / High Reward (e.g. Microsoft example)“Mt Everest” syndrome

For the challenge!Noble failures may promise glory even if not successful (e.g. Go)But watch for … pre-determined failures and “so what” value props

UnemploymentPre-requisite of promotion or future advancementBankruptcyRevenge!Escape normal company bureaucracy (e.g. skunkworks, Apple’s Mac)*


Politics

The often internally conflicting interrelationships among people in a society.

Intrigue or maneuvering within a political unit or group in order to gain control.

Source: The American Heritage® Dictionary of the English Language, Fourth Edition


Politics

Politics are normalDeath March politics tend to be more intensive & unhealthy


Identifying Stakeholders

Why?Need to know friend from foe

Owner (potential friend)CustomerShareholdersStakeholdersChampions

Probably more important to project’s success than any technology or methodology


Death March Project Types

Happiness GaugeWould you do this again?

Mission ImpossibleHigh team morale, thrive on challenge, dream of rewards of success

KamikazeGo type project, happiness derived from technology or team dynamics

UglyLow team morale, heavy duty politics

SuicideEveryone doomed, everyone miserable

UglySuicide

MissionImpossible

Kamikaze

Hap

pine

ss

Success ProbabilityLow


Negotiations

Negotiations at start of projects tend to be irrationalWhy?

Negotiations at 1-2 months prior to deadline tend to be more rationalCustomer realizes original deadline, budget & functionality won’t be achievedBut, it’s too late for some project members (e.g. project leader)

“You need to understand your own management’s negotiating stance, if they love to play roll over, you have to keep them well away from the project.”

Doug Scott


Mitigation Tactics

Commercial Estimation Tools50+ available (e.g. SLIM, Checkpoint, Estimacs)Best estimates, +/- 10%, but Death March projects typically off by 1000%!

Systems Dynamics ModelsPrediction of impact from constraint changes

e.g. Overtime: initially output increases, then errors increase & output decreases

Prototyping & TimeboxingAcceptable Trade-offs

Pose alternatives80/20 rule“everybody wants things good, wants them fast & wants them cheap … pick two”

Balancing Time, Resources, Capability10% change in one variable, change another variable 10%What happens if greater than 10% change?


Negotiation Games

Negotiation is a gameSafety factor in most projects is?But, for Death March projects …


Basic Negotiation Games

Doubling & add someBosses know this one, so they halve it.But, actually sound logic behind this one

Reverse DoublingClient / customer gets one estimateDevelopment team another

Price is Right? (or Guess the # I’m thinking of)Benefits for boss?

Double Dummy SpitThe X Plus GameSpanish Inquisition


Advanced Negotiation Games

Low Bid / What are they prepared to payGotcha!

Smoke & Mirrors / Blinding with science (GIGO rule)False Precision


Tactics

Not playing along is risky, but negotiation games can be counteredFirst, recognize the game

e.g. Price is Right, response “what do you think is a good estimate”

DelayUse data, sound estimation practices & comparable examples

You are leading a Death March Project

How do you survive?


People

Choose your own team (if possible)Superstars?Well honed Mission Impossible teamWell prepared mere mortalsPot luck

Prepare for some overtimePreferably short sprints

Reward the team well if project succeedsFocus on building a loyal, cohesive & cooperative team

CommitmentMotivationRewards


Teams

Open & honest CommunicationAssume no secrets & you won’t get burnedShare everything you canFor stuff you can’t share, say so!

Remember the Peopleware lessonsYou need every productivity improving factor you can get

Overall,Talented people,Cohesive teams &Decent working conditions give you the greatest chance of success


Death March Approaches

Key:You can’t do everything, so …Don’t put together a plan or processes that assume you can(e.g. waterfall)

Solution:Triage!


Requirements Management

Ultimately a crisis will occur & reality will hitSeveral scenarios could occur:

Fire project managerRenegotiate scheduleRenegotiate functionality (at which point most WIP gets thrown away)

Alternatively, plan at start80/20 Rule

Key is to choose the “right” 20%

Approach:Prioritize (subtly) requirements into must do, should do, could doAt start, identify what will ultimately be thrown away & avoid spending energy on those

items


Death March Processes

Back to basicsManage requirements

Initial baselineChanges – high threshold & very visible

Don’t try out new tools & processesAgree on & formalize some important processes, then follow them

e.g. source code control, change management, requirements managementLeave other processes ad hoc

Pay careful attention to risk managemente.g. Top 10 list

team software project (tsp) july 24, 2007 cycle 2 requirements, standards & death marches

Documents

comparable project

complex project

projectsfrom death

ppttypes of death

requirements completecycle

team software project

test completecycle

committed schedule