CSE Senior Design I
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.
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?
Signs of denial? 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
Stake holder confidence is low/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. Increase productivity by focusing on shortterm 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
Or (usually best), combine these three:

Drop a few features, increase productivity
when 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 (“not enough time to…”)
 Add people (mythical man-month)
 Rely on silver bullets (there’s no
“magic” )
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 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
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”
Always a
Best Practice
 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, 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…
#open, #fixed, #resolved
 Don’t try to take 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