The document discusses signs that a project is in trouble and provides recommendations for getting a failing project back on track. It notes that common signs include missed deadlines, declining quality, low morale, and lost customer confidence. The key recommendations are to cut scope, increase productivity, or slip the schedule. The document also emphasizes focusing on the three P's - people, process, and product. It provides specific suggestions in each of these areas, such as improving communication and leadership, stabilizing requirements, and breaking work into smaller milestones. Regularly reassessing progress and the recovery plan is also stressed.

1.  
Brian Hall, MPM, PMP

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

7. 7
Scope
Qualit
y

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!

25. Thank you!
Brian Hall, MPM, PMP
brian@educationpmp.com