CSE Senior Design I Project Recovery Instructor Vassilis

CSE Senior Design I Project Recovery Instructor: Vassilis Athitsos 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 Mc. Connell. The presentation was prepared by Mr. Mike O'Dell and modified by Vassilis Athitsos.

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

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

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

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

8 Recovery Plan Basics ØOne plan does not fit all § Adopt a plan that is right for where you are on your project ØIt almost never helps to… § Cut corners § Add people (mythical man-month) § Rely on silver bullets 6

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

8 Theory-W Management Everyone Wins Customers Bosses Developers End-Users Maintainers Quick Schedule No Overruns Interesting Work Loss of Features No Defects Low Budget No Surprises Exploration of User-friendly New Software Technology Meets Requirements Successful Project No Grunt Work Fast Software Easy Modifiability A Life Robust Software Good Docs. 8

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

8 … and More First Steps ØAssess the “political situation” § 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. 10

8 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 11

8 Dealing with People Problems Ø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 12

8 Dealing with People Problems ØDeal with “problem people” § Recall discussion of “Welch Grid” Ø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 13

8 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… § Removing distractions wherever possible 14

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

8 Managing the Process ØIdentify and fix things that are clearly broken or not working § 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 § Monitor progress with finer granularity 16

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

8 Managing the Process Ø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 “offthe-cuff” estimates ØPainstakingly manage risks 18

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

8 Reining in the Product Ø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… 20

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

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

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

8 Timing Your Recovery Plan Ø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 24