2. When is a project in trouble?
Getting things back on track
The three P’s
Timing
Communicate
3. No one's having any fun anymore
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
Developers become defensive of their progress
Project team (development, marketing, management, etc.) relationships
deteriorate… finger pointing
Morale is at rock bottom
Cancellation appears imminent
4. 1. Cut the size of the project so it can be
completed within the time and effort planned
Or (usually best), COMBINE THESE THREE:
Drop a few features, increase productivity where
possible, slip the schedule as necessary
Three fundamental approaches:
2. Increase productivity by focusing on short-
term gains
3. Face the facts – slip the schedule, do damage
control, possibly cancel the project
5. Recognize that significant action is
required
o Same ol’, same ol’ won’t work!
Assess – figure out where you are
Apply Theory-W analysis
o What do all stakeholders need at this
point?
o How does everyone Win?
6. Sponsor Bosses Developers End-Users Support
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
Everyone Wins
8. Ask the team what needs to be done
o Involve everyone*
o Evaluate all ideas
Be realistic about your team’s ability to
recover
o Avoid over-committing
o Objectively evaluate your ability to
estimate, and adjust accordingly
9. o 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?
o Could the reason for failure be beyond your
control… recovery plan, or not?
Assess the “political situation”
10. Three components (the 3 P’s)
o People… fix these problems and you will
get the most leverage toward getting the
project back on track
o Process… fix these problems or your
recovery plan will fail
o Product… getting the feature-set under
control and minimized is critical to
project/product stability
11. Address the morale of the team
o Critical to productivity
o 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. Deal with major leadership problems
o Is the project leader who got you in this
hole the right one to get you out?
o Identify where on the team the
leadership is weak
Deal with “problem people”
13. Focus…
o Removing distractions wherever
possible
Add people very carefully, if at all
o Brook’s Law: Adding people to a late
project is like pouring gasoline on fire!
o Consider adding only if project can be
partitioned to isolate new people
o Err on the side of NOT adding people
14. Identify and Fix Classic Mistakes
o Stabilize product definition, design
o Shore up control and tracking
o Shore up accountability
o Validate product quality
o Verify (and re-verify) the new schedule
o Validate your tools
15. o Monitor progress with finer granularity
Identify and fix things that are clearly
broken or not working
o Take decisive action
Create “mini-milestones”
o Miniature, binary and exhaustive
• Miniature- completed in days, not weeks
• Binary- done or not done
• Exhaustive- when “last” is done, project is
done
16. Record reasons for missed milestones
o Look for and fix underlying causes
16
Track schedule progress meticulously
o Make sure “done” is 100% done
o Ask “the next question”
o Calibrate and recalibrate your schedule
o Expect additional work (over-time) to make
up slips on a mini-milestone
17. Painstakingly manage risks
Recalibrate the recovery plan after 1 or
2 weeks
o Don’t let things get away from you again
Make every recovery schedule a
meaningful one
o Don’t give in to pressure or create “off-the-
cuff” estimates
18. o Implement minimum time delay to even
consider further change
Stabilize the requirements
o Unstable, changing requirements may be
the root cause of all your problems
o May need to restart the requirements
phaseo Implement a rigid change evaluation
process for any further changes (Change
Management Plan)
19. o Relegate low-priority features to the next
release
Trim the feature set
o Prioritize/Re-prioritize features
o Focus on features that create best possible
product at this time
20. o Systematic redesign and implementation
will reduce your risk!
Take out the garbage
o Eliminate low quality components…
carefully!o Redo them from the beginning if they are
critically needed
21. o Use design and code reviews on every
module that you touch
Systematically reduce and manage
further defects
o Track progress daily…
• #open, #fixed, #resolved
o Don’t try to take short-cuts… short-cutting
the fix inevitably results in more defects
22. o Make maintaining the build each day a top
priority
Identify a known good state and build on
ito Use as base for further work
o Daily build and test cycle
o Consider a “developers on call” approach
23. o Too early – people won’t believe there is a
problem, so they won’t take your plan
seriously
Need to find right balance between:
o Too late – you’re probably already in a
recovery mode, having implemented
numerous mini-plans, and your credibility
will already be damaged
24. Stop and assess
Recognize that things have to change
Be sure you really understand the project requirements
Break the project into smaller manageable “chunks”
Reassess consistently
Communicate, Communicate, Communicate!
