Monday, February 13, 2012

Replanning a project that is failing
When a project is in trouble and the delivery date is clearly going to be missed, the project stakeholders immediately start asking for a new date. Usually the team's inclination is to answer the question with a revised date that is derived in one of three ways:

1.A new date two to three months out is selected out of thin air.

2.The team discusses options and selects a new date that they believe is aggressive but doable.

3.The team does a replanning exercise and comes up with a new date based on revised estimates.

All three of these methods can lead to only one final answer, disaster. Option 1 assumes that time was the only factor impacting the project and adding an extra month or two will magically fix the those issues. Option 2 is doomed because the stakeholder's inclination is to believe the team wasn't aggressive enough and will insist that they be more aggressive. Option 3 is always a non-starter because the stakeholders don't trust the new timeframe because the original one was obviously incorrect. In most cases the final result is that the stakeholders select a new date that borders on the realm of science fiction or a least a "B" horror film.

Why does this happen? Business stakeholders and senior executives see project work differently than those of us who deliver the project. The goal of the project is to deliver a result that provides strategic or tactical value to the company. When a project is delayed, the reward the stakeholders were counting on doesn't occur. Their number one driver is to get that reward as soon as possible. By providing a new date for delivery without  providing them additional information on why the new date is necessary, the stakeholders will generally react negatively. To avoid this, the stakeholders need to see three things from the replan:

1.That the project team balanced being aggressive with risks.

2.The project team looked at options for delivery and took into account business needs.

3.The team addressed the underlying issues that caused the project to get into trouble in the first place.

No comments:

Post a Comment