To save a project that is in trouble, minor adjustments won’t work. We need to take strong corrective action.
This section contains a strong rescue plan and guidelines.
General Recovery Options
Only four fundamental approaches are available to someone rescuing a project:
- Pause the project and take a NEW, fresh look at everything
- Cut the size of the software so that you can build it within the time and effort planned
- Increase the process productivity by focusing on short-term improvements
- Face the fact that the software will not be ready on time, slip the schedule with damage control, possibly including canceling the project
Combine the last three approaches and a fourth approach emerges:
- Drop a few features, increase productivity as much as you can and slip the schedule as needed
When we are in project-recovery mode, it’s easy to focus on the wrong issue: how to finish quickly, how to catch up? This is rarely the real problem. For projects that are in this trouble, the primary problem is usually how to finish at all.
There are lots of directions to go with a recovery plan; the plan in this section focuses on regaining control. “Control” can have a negative connection, especially to independent-minded developers but I don’t think it’s possible to rescue a project without concentrating on it.
The most common reason that projects get into trouble in the first place is that they have not been adequately controlled. In the end, there is so little control that neither developers, managers or users even know how far off-track their projects are.
This is time for decisive action. If you are going to make changes, make BIG changes and make them all at once. Lots of small corrections are demoralizing to the development team and make it look to our management like we don’t know what we are doing. It’s easier to recapture control all at once than it is to take a little now and a little more later.