Instructor: Mike O’Dell Project Recovery Instructor: Mike O’Dell 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.

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?

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

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

How to Get Things Back on Track Three fundamental approaches: Cut the size of the project so it can be completed within the time and effort planned Increase productivity by focusing on short-term gains 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 where possible, slip the schedule as necessary

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

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?

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 New Technology User-friendly Software Good Docs. Meets Requirements Successful Project No Grunt Work Fast Software Easy Modifiability A Life Robust Software

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

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

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

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

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

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

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

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

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

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

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

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…

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!

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

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

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