Contents
16.1 General Recovery Options
16.2 Recovery Plan
Related Topics
Rapid-development strategy: Chapter 2
Some projects discover their need for rapid development long after they are underway, usually at some point after the project has been determined to be late. The project might have missed an early deadline. It might have missed its final delivery date. No matter. The project is in trouble and needs to be rescued.
In this chapter, when I refer to a project that's in trouble, I'm not talking about a project that's slipped off its schedule a bit. I'm talking about a project that's crying for help and about to go under for the third time. Such projects have the following characteristics:
No one has any idea when the project will finish, and most people have given up trying to guess.
The product is laden with defects.
Team members are working excessive numbers of hours—60 hours per week or more of involuntary or peer-pressure-induced overtime.
Management has lost its ability to control progress or even to ascertain the project's status with any accuracy.
The customer has lost confidence that the development group will ever deliver the promised software.
The team is defensive about its progress. They feel threatened if anyone outside the team suggests that the project might be in trouble.
Relations between developers, marketers, managers, quality assurance, and customers are strained.
The project is on the verge of being canceled; customers and managers are actively considering that option.
The morale of the development team has hit rock bottom. The fun has gone out of the project, and the team members are grim.
To save a project that's in this much trouble, minor adjustments won't work. You need to take strong corrective action. This chapter describes a strong rescue plan.
Only three fundamental approaches are available to someone rescuing a project:
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, and proceed with damage control, possibly including canceling the project.
Combine these three approaches and a fourth approach emerges:
Drop a few features, increase productivity as much as you can, and slip the schedule as needed.
This last approach is the option that this chapter describes.
When you're 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 much 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 chapter focuses on regaining project control. "Control" can have a negative connotation, especially to independent-minded developers, but I don't think it's possible to rescue a project without concentrating on it. In my experience, as well as the experiences captured in Software Engineering Institute audits and other published and anecdotal reports, the most common reason that projects get into trouble in the first place is that they have not been adequately controlled. A desire for all-out development speed leads projects to take unwise shortcuts, and they inadvertently sacrifice real development speed in the bargain. In the end, there is so little control that neither developers nor managers even know how far off track their projects are.
It's difficult to take back control that you've given away, so the moment that you and your team are forced to confront the reality that recovery is needed represents a singular leadership opportunity. It gives you a chance to redefine your project in fundamental ways, which you can't do if your project is in only a little trouble.
This is a time for decisive action. If you're 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 your management like you don't know what you're doing. It's easier to recapture control all at once than it is to try to take back a little now and a little more later.
