1. CSE Senior Design I Project Recovery The slides in this presentation are derived from materials in the textbook used for CSE 4316/4317, Rapid Development: Taming Wild Software Schedules, by Steve McConnell. Instructor: Mike O’Dell

2. 8 2 A Project in Trouble (C.S. 16-1) first indication  What was the first indication of trouble? recovery plan  How was the recovery plan developed?  What was the recovery plan?  Mythical man-month  Mythical man-month? denialDefensiveness  Signs of denial? Defensiveness? working hard  Was the problem that people weren’t working hard enough?

3. 8 3 Characteristics of a Project in Need of a Recovery Plan  No one knows  No one knows when they will finish, and can’t even guess quality has plummeted  Product quality has plummeted and defects are on the rise working long, hard hours  Everyone is working long, hard hours pressure is on the rise  Peer-pressure and management pressure is on the rise confidence is low/lost  Stake holder confidence is low/lost

4. 8 4 Characteristics of a Project in Need of a Recovery Plan defensive  Developers become defensive of their progress relationships deteriorate… finger pointing  Project team (development, marketing, management, etc.) relationships deteriorate… finger pointing  Morale  Morale is at rock bottom  Cancellation  Cancellation appears imminent fun  No one's having any fun anymore

5. 8 5 How to Get Things Back on Track Three Three fundamental approaches: 1.Increase productivity by focusing on short- term gains 2.Cut the size of the project so it can be completed within the time and effort planned 3.Face the facts – slip the schedule, do damage control, possibly cancel the project combine these three Or (usually best), combine these three: featuresproductivity schedule  Drop a few features, increase productivity when possible, slip the schedule as necessary

6. 8 6 Recovery Plan Basics  One plan does not fit all where you areyour project  Adopt a plan that is right for where you are on your project  It almost never helps to…  Cut corners (“not enough time to…”)  Add people (mythical man-month)  Rely on silver bullets (there’s no “magic” )

7. 8 7 First Steps  Assess  Assess – figure out where you are significant action  Recognize that significant action is required  Same ol’, same ol’ won’t work! Theory-W analysis  Apply Theory-W analysis  What do all stakeholders need at this point?  How does everyone win?

8. 8 Theory-W Management CustomersBossesDevelopersEnd-UsersMaintainers Quick Schedule No OverrunsInteresting Work Loss of Features No Defects Low BudgetNo SurprisesExploration of New Technology User-friendly Software Good Docs. Meets Requirements Successful Project No Grunt Work Fast SoftwareEasy Modifiability A LifeRobust Software 8 Everyone W ins

9. 8 9 More First Steps  Ask  Ask the team what needs to be done everyone  Involve everyone  Evaluate all ideas  Be realistic about your team’s ability to recover over-committing  Avoid over-committing (again?) evaluate your ability  Objectively evaluate your ability to estimate, and adjust accordingly

10. 8 10 … and More First Steps  Assess  Assess the “political situation” “why”  Identify and fix the “why” if others are not helping the project succeed Everyone onboard with Theory-W? Is there a power struggle going on? What are the priorities of the stakeholders?  Could be the reason for failure beyond your control… recovery plan, or not.

11. 8 11 A Recovery Plan  Three components (the 3 P’s)  People  People… fix these problems and you will get the most leverage toward getting the project back on track  Process  Process… fix these problems or your recovery plan will fail  Product/Technology  Product/Technology… getting the feature-set under control and minimized is critical to project/product stability

12. 8 12 Dealing with People Problems morale  Address the morale of the team  Critical to productivity  Potential Approaches Sacrifice the sacred cows Take explicit action that makes the development team feel important Remove unreasonable schedule pressure Remove micro-management practices

13. 8 13 Dealing with People Problems “problem people”  Deal with “problem people”  Recall discussion of “Welch Grid” leadership  Deal with major leadership problems  Is the project leader who got you in this hole the right one to get you out?  Identify where on the team the leadership is weak

14. 8 14 Dealing with People Problems  Add people very carefully, if at all  Brooks’s Law: Adding people to a late project is like pouring gasoline on fire!  Consider adding only if project can be partitioned to isolate new people  Err on the side of NOT adding people  Focus… distractions  Removing distractions wherever possible

15. 8 15 Managing the Process  Identify and Fix Classic Mistakes  Stabilize  Stabilize product definition, design control and tracking  Shore up control and tracking quality  Validate product quality schedule  Verify (and re-verify) the new schedule tools  Validate your tools (any silver-bullets?) accountability  Shore up accountability

16. 8 16 Managing the Process  Identify and fix things that are clearly broken or not working decisive  Take decisive action  Create “mini-milestones”  Miniature, binary and exhaustive Miniature- completed in days, not weeks Binary- done or not done Exhaustive- when last is done, project is done finer granularity  Monitor progress with finer granularity Always a Best Practice

17. 8 17 Managing the Process  Track  Track schedule progress meticulously  Make sure “done” is 100% done  Ask “the next question”  Calibrate and recalibrate  Calibrate and recalibrate your schedule  Expect additional work (over-time) to make up slips on a mini-milestone  Record reasons for missed milestones fix underlying causes  Look for and fix underlying causes

18. 8 18 Managing the Process  Recalibrate  Recalibrate the recovery plan after a short time after 1 or 2 weeks  Don’t let things get away from you again  Make every recovery schedule a meaningful one  Don’t give in to pressure or create “off- the-cuff” estimates manage risks  Painstakingly manage risks

19. 8 19 Reining in the Product  Stabilize  Stabilize the requirements root cause  Unstable, changing requirements may be the root cause of all your problems restart requirements phase  May need to restart requirements phase rigid change evaluation  Implement a rigid change evaluation process for any further changes minimum time delay  Implement minimum time delay to even consider further change

20. 8 20 Reining in the Product  Trim  Trim the feature set  Prioritize/Re-prioritize features  Focus on features that create best possible product at this time  Relegate low-priority features to the next release  Minimize, minimize, minimize…

21. 8 21 Reining in the Product garbage  Take out the garbage  Eliminate low quality components… carefully! from the beginning  Redo them from the beginning if they are critically needed  Systematic redesign and implementation will reduce your risk!

22. 8 22 Reining in the Product  Systematically reduce and manage  Systematically reduce and manage further defects  Track progress daily  Track progress daily… #open, #fixed, #resolved short-cuts  Don’t try to take short-cuts… short- cutting the fix inevitably results in more defects reviews on every module  Use design and code reviews on every module that you touch

23. 8 23 Reining in the Product  Identify a known good state  Identify a known good state and build on it base  Use as base for further work  Daily build and test cycle maintaining the build  Make maintaining the build each day a top priority  Consider a “developers on call” approach

24. 8 24 Timing Your Recovery Plan right balance  Need to find right balance between:  Too early – people won’t believe there is a problem, so they won’t take your plan seriously  Too late – you’re probably already in a recovery mode, having implemented numerous mini-plans, and your credibility will already be damaged