Project Recovery

1
Project Recovery
Instructor Mike ODell

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

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 werent working hard
  enough?

3
Characteristics of a Project in Need of a
Recovery Plan

• No one knows when they will finish, and cant
  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 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

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 (theres no magic )

7
First Steps

• Assess figure out where you are
• Recognize that significant action is required
• Same ol, same ol wont work!
• Apply Theory-W analysis
• What do all stakeholders need at this point?
• How does everyone win?

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

• Ask the team what needs to be done
• Involve everyone
• Evaluate all ideas
• Be realistic about your teams ability to recover
• Avoid over-committing (again?)
• Objectively evaluate your ability to estimate,
  and adjust accordingly

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

11
A Recovery Plan

• Three components (the 3 Ps)
• 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

12
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

13
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

14
Dealing with People Problems

• Add people very carefully, if at all
• Brookss 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

15
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

16
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
17
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

18
Managing the Process

• Recalibrate the recovery plan after a short time
  after 1 or 2 weeks
• Dont let things get away from you again
• Make every recovery schedule a meaningful one
• Dont give in to pressure or create
  off-the-cuff estimates
• Painstakingly manage risks

19
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

20
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

21
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!

22
Reining in the Product

• Systematically reduce and manage further defects
• Track progress daily
• open, fixed, resolved
• Dont 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

23
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

24
Timing Your Recovery Plan

• Need to find right balance between
• Too early people wont believe there is a
  problem, so they wont take your plan seriously
• Too late youre probably already in a recovery
  mode, having implemented numerous mini-plans, and
  your credibility will already be damaged