1. Instructor: Vassilis Athitsos
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 McConnell. The presentation was prepared by Mr. Mike O'Dell and modified by Vassilis Athitsos.

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
Customer confidence is 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:
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

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
Add people (mythical man-month)
Rely on silver bullets

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 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 team’s 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 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

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

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

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

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

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