1. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt1 Team Software Project (TSP) July 24, 2007 Cycle 2 Requirements, Standards & Death Marches

2. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt2 Due today Cycle 2 Requirements: Cycle 2 Requirements

3. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt3 Remaining Lectures Plan/Discussion July 24 – Cycle 2 Requirements Complete Cycle 2 Requirements Death March Projects continued Process topics – Configuration Management - July 31 – Cycle 2 Implementation Complete System Test Plan Baselined Cycle 2 Design & Implementation Process topics – CMMI Details August 7 – Cycle 2 Test Complete Cycle 2 Test Complete Other topics TBD August 14 - Course Review Cycle 2 Post-Mortem Complete Course Review Final

4. Death March Projects From Death March by Edward Yourdon

5. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt5 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?

6. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt6 How Do We Get Here? Start: High risk factors: Optimism Wishful thinking Unrealistic schedule & budget Realistic plan, but then it goes downhill e.g. user adds requirements Results: Overtime Wasted weekends Emotional & physical burnout before the end

7. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt7 Key Takeaway Confronted with joining a Death March project, Recognize & understand your own motivations, so you can make a rational decision to join the team or look elsewhere for your next job. You always have options!

8. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt8 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!

9. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt9 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

10. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt10 Types of Death March Projects Size Small < 10 people 3-6 months Most 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 Medium 20-30 people 1-2 years Little chance of success Large 100-300 people 3-5 years No chance of success

11. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt11 Reasons Politics … ugly politics! Naïve promises Hysterical 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 youth No problem, we can do it in a weekend! Start-up mentality of fledgling, entrepreneurial companies Intense competition Markets Technologies Government regulations Unexpected &/or unplanned crises

12. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt12 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?

13. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt13 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)*

14. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt14 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

15. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt15 Politics Politics are normal Death March politics tend to be more intensive & unhealthy

16. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt16 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

17. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt17 Death March Project Types Happiness Gauge Would you do this again? Mission Impossible High team morale, thrive on challenge, dream of rewards of success Kamikaze Go type project, happiness derived from technology or team dynamics Ugly Low team morale, heavy duty politics Suicide Everyone doomed, everyone miserable UglySuicide Mission Impossible Kamikaze Happiness Success Probability Low

18. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt18 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

19. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt19 Mitigation Tactics Commercial Estimation Tools 50+ available (e.g. SLIM, Checkpoint, Estimacs) Best estimates, +/- 10%, but Death March projects typically off by 1000%! Systems Dynamics Models Prediction of impact from constraint changes e.g. Overtime: initially output increases, then errors increase & output decreases Prototyping & Timeboxing Acceptable Trade-offs Pose alternatives 80/20 rule “everybody wants things good, wants them fast & wants them cheap … pick two” Balancing Time, Resources, Capability 10% change in one variable, change another variable 10% What happens if greater than 10% change?

20. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt20 Negotiation Games Negotiation is a game Safety factor in most projects is? But, for Death March projects …

21. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt21 Basic Negotiation Games Doubling & add some Bosses know this one, so they halve it. But, actually sound logic behind this one Reverse Doubling Client / 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

22. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt22 Advanced Negotiation Games Low Bid / What are they prepared to pay Gotcha! Smoke & Mirrors / Blinding with science (GIGO rule) False Precision

23. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt23 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

24. You are leading a Death March Project How do you survive?

25. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt25 People Choose your own team (if possible) Superstars? Well honed Mission Impossible team Well prepared mere mortals Pot luck Prepare for some overtime Preferably short sprints Reward the team well if project succeeds Focus on building a loyal, cohesive & cooperative team Commitment Motivation Rewards

26. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt26 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

27. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt27 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!

28. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt28 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 Rule Key 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

29. 7/24/2007SE 652- 2007_7_24_DeathMarch.ppt29 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