Project Recovery

Brian Hall, MPM, PMP

A Project in Trouble When is a project in trouble?

Getting things back on track

The three P’s

Timing

Communicate

Characteristics of a Project in Need of a Recovery Plan

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

How to Get Things Back on Track

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

First Steps

Recognize that significant action is requiredo Same ol’, same ol’ won’t work!

Assess – figure out where you are

Apply Theory-W analysisoWhat do all stakeholders need at this

point?oHow does everyone Win?

Theory-W Management

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

Triple Constraints

7

Scope

Tim

e Cos

t

Quality

More First Steps Ask the team what needs to be

doneo Involve everyone*o Evaluate all ideas Be realistic about your team’s ability to recoveroAvoid over-committingoObjectively evaluate your ability to

estimate, and adjust accordingly

… and More First Steps

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?oCould the reason for failure be

beyond your control… recovery plan, or not?

Assess the “political situation”

A Recovery Plan 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

Dealing with People Problems

Address the morale of the teamoCritical 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

Dealing with People Problems

Deal with major leadership problemso 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”

Dealing with People Problems

Focus…oRemoving distractions wherever possible

Add people very carefully, if at alloBrook’s Law: Adding people to a late

project is like pouring gasoline on fire!

oConsider adding only if project can be partitioned to isolate new people

o Err on the side of NOT adding people

Managing the Process Identify and Fix Classic Mistakes

o Stabilize product definition, designo Shore up control and tracking

o Shore up accountability

oValidate product qualityoVerify (and re-verify) the new schedule

oValidate your tools

Managing the Process

oMonitor progress with finer granularity

Identify and fix things that are clearly broken or not workingo Take decisive action

Create “mini-milestones”oMiniature, binary and exhaustive• Miniature- completed in days, not weeks• Binary- done or not done• Exhaustive- when “last” is done, project is

done

Managing the Process

Record reasons for missed milestoneso Look for and fix underlying causes 16

Track schedule progress meticulouslyoMake sure “done” is 100% doneoAsk “the next question”oCalibrate and recalibrate your scheduleo Expect additional work (over-time) to

make up slips on a mini-milestone

Managing the Process

Painstakingly manage risks

Recalibrate the recovery plan after 1 or 2 weeksoDon’t let things get away from you again

Make every recovery schedule a meaningful oneoDon’t give in to pressure or create

“off-the-cuff” estimates

Reining in the Product

o Implement minimum time delay to even consider further change

Stabilize the requirementsoUnstable, changing requirements may

be the root cause of all your problemsoMay need to restart the requirements phase

o Implement a rigid change evaluation process for any further changes (Change Management Plan)

Reining in the Product

oRelegate low-priority features to the next release

Trim the feature seto Prioritize/Re-prioritize featureso Focus on features that create best

possible product at this time

Reining in the Product

o Systematic redesign and implementation will reduce your risk!

Take out the garbageo Eliminate low quality components… carefully!

oRedo them from the beginning if they are critically needed

Reining in the Product

oUse design and code reviews on every module that you touch

Systematically reduce and manage further defectso Track progress daily… • #open, #fixed, #resolved

oDon’t try to take short-cuts… short-cutting the fix inevitably results in more defects

Reining in the Product

oMake maintaining the build each day a top priority

Identify a known good state and build on it

oUse as base for further workoDaily build and test cycle

oConsider a “developers on call” approach

Timing Your Recovery Plan

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

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

Questions?

Thank you!

Brian Hall, MPM, PMPbrian@educationpmp.com