1 / 23

Project Recovery

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. A Project in Trouble (C.S. 16-1). What was the first indication of trouble?

salena
Download Presentation

Project Recovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. 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? • Signs of denial? Defensiveness? • Was the problem that people weren’t working hard enough?

  3. 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 • Stake holder confidence is low/lost

  4. Characteristics of a Project in Need of a Recovery Plan • Developers become defensiveof 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

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

  6. 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 (“not enough time to…”) • Add people (mythical man-month) • Rely on silver bullets (there’s no “magic” )

  7. 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?

  8. Theory-W Management Everyone Wins

  9. 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

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

  11. 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. 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. 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. 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. 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 Always a Best Practice

  16. 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. 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 “off-the-cuff” estimates • Painstakingly manage risks

  18. 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. 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, minimize…

  20. 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. Reining in the Product • Systematically reduce and manage further defects • Track progress daily… • #open, #fixed, #resolved • Don’t try to take short-cuts… short-cutting the fix inevitably results in more defects • Use design and code reviews on every module that you touch

  22. 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. 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

More Related