7/24/2007se 652- 2007_7_24_deathmarch.ppt1 team software project (tsp) july 24, 2007 cycle 2...
Post on 19-Dec-2015
223 views
TRANSCRIPT
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 1
Team Software Project (TSP)
July 24, 2007
Cycle 2 Requirements,
Standards
&
Death Marches
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 3
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
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 5
Death March
Odds of a software project delivering on its committed schedule, budget & capabilities is extremely poor
Average Project
6-12 months behind schedule
50-100% over budget
But Why?
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 6
How Do We Get Here?
Start:
High risk factors:• Optimism
• Wishful thinking
Unrealistic schedule & budget
Realistic plan, but then it goes downhille.g. user adds requirements
Results:
Overtime
Wasted weekends
Emotional & physical burnout before the end
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 7
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!
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 8
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!
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 9
Common Root Causes
Compressed schedule (e.g. < ½ time estimated by a rational process)
½ Staff of what a comparable project typically requires
½ Budget & associated resources
Twice the functionality, feature & performance requirements given schedule, staff & budget constraints
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 10
Types of Death March ProjectsSize
Small< 10 people
3-6 months
Most common & greatest chance of successHow: 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 people
1-2 years
Little chance of success
Large100-300 people
3-5 years
No chance of success
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 11
Reasons
Politics … ugly politics!
Naïve promises
Hysterical Optimisme.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 companies
Intense competitionMarkets
Technologies
Government regulations
Unexpected &/or unplanned crises
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 12
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?
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 13
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
Unemployment
Pre-requisite of promotion or future advancement
Bankruptcy
Revenge!
Escape normal company bureaucracy (e.g. skunkworks, Apple’s Mac)*
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 14
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
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 15
Politics
Politics are normal
Death March politics tend to be more intensive & unhealthy
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 16
Identifying Stakeholders
Why?
Need to know friend from foe
Owner (potential friend)
Customer
Shareholders
Stakeholders
Champions
Probably more important to project’s success than any technology or methodology
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 17
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
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 18
Negotiations
Negotiations at start of projects tend to be irrational
Why?
Negotiations at 1-2 months prior to deadline tend to be more rational
Customer realizes original deadline, budget & functionality won’t be achieved
But, 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
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 19
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 & Timeboxing
Acceptable Trade-offsPose alternatives
80/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?
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 20
Negotiation Games
Negotiation is a game
Safety factor in most projects is?
But, for Death March projects …
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 21
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 estimate
Development team another
Price is Right? (or Guess the # I’m thinking of)Benefits for boss?
Double Dummy Spit
The X Plus Game
Spanish Inquisition
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 22
Advanced Negotiation Games
Low Bid / What are they prepared to pay
Gotcha!
Smoke & Mirrors / Blinding with science (GIGO rule)
False Precision
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 23
Tactics
Not playing along is risky, but negotiation games can be countered
First, recognize the game
e.g. Price is Right, response “what do you think is a good estimate”
Delay
Use data, sound estimation practices & comparable examples
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 25
People
Choose your own team (if possible)Superstars?
Well honed Mission Impossible team
Well prepared mere mortals
Pot luck
Prepare for some overtimePreferably short sprints
Reward the team well if project succeeds
Focus on building a loyal, cohesive & cooperative teamCommitment
Motivation
Rewards
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 26
Teams
Open & honest Communication
Assume no secrets & you won’t get burned
Share everything you can
For stuff you can’t share, say so!
Remember the Peopleware lessons
You need every productivity improving factor you can get
Overall,
Talented people,
Cohesive teams &
Decent working conditions give you the greatest chance of success
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 27
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!
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 28
Requirements Management
Ultimately a crisis will occur & reality will hit
Several scenarios could occur:Fire project manager
Renegotiate schedule
Renegotiate functionality (at which point most WIP gets thrown away)
Alternatively, plan at start
80/20 RuleKey is to choose the “right” 20%
Approach:Prioritize (subtly) requirements into must do, should do, could do
At start, identify what will ultimately be thrown away & avoid spending energy on those items
7/24/2007 SE 652- 2007_7_24_DeathMarch.ppt 29
Death March Processes
Back to basics
Manage requirements
Initial baseline
Changes – high threshold & very visible
Don’t try out new tools & processes
Agree on & formalize some important processes, then follow them
e.g. source code control, change management, requirements management
Leave other processes ad hoc
Pay careful attention to risk management
e.g. Top 10 list