Before you launch a recovery plan, find out what kind of plan you need.

Assess your situation. Determine how critical the deadline really is and what precisely is needed to meet it. You might find out that there isn't really any hard deadline, and you don't need to worry about project recovery at all. Or you might find that your customers are much more willing to negotiate the feature set to avoid a late project than they were at the beginning.

Apply Theory-W analysis. What do you and your team need to succeed? What do your customers need? What do you need to do to salvage the customer relationship? Don't focus on the past. Focus on the present. If you can't find a way to make winners out of everyone by their own standards, scuttle the project.

Prepare yourself to fix the project. If your project is in recovery mode and not merely a little behind, your project is broken. Realize that your project is broken. Realize that you can't fix it by doing the same things you've been doing. Mentally prepare yourself to make significant changes. Prepare both your team and your management for the reality that significant changes will be needed if they want to rescue the project. If people aren't willing to make significant changes, you've already lost the battle. Consider canceling the project.

Ask your team what needs to be done. Ask everyone on your team to contribute at least five practical ideas about how to rescue the project. Evaluate the ideas, then implement as many of them as you can.

Be realistic. If you're in project-recovery mode, you're probably wearing a string of broken schedule promises around your neck. They drag you down as much as the albatross around the neck of the Ancient Mariner dragged him down. If you're in recovery mode, your team desperately needs a strong dose of clear-headed, realistic project leadership. When you start your project recovery, admit that you don't know how long it will take to finish. Explain your plan for getting the project back on track, and then give a date by which you can commit to a new deadline. Don't commit to a new deadline until you have good reasons to think you can meet it.

People are the most important point of leverage in rapid development, and you need to put that room of your rapid-development house in order before you proceed to the areas of process and product.

Do whatever is needed to restore the group's morale. During project recovery, morale plays a critical role in your team's productivity. Upper managers will want to know how to motivate your group more. This is a false question during project recovery. If your group has been working hard, the question is not how to motivate them to the utmost, but how to restore their morale so that they will be motivated at all.

One of the best ways to restore morale is to take a symbolic action that shows you're behind the developers, and one of the best ways to do that is to sacrifice one of your organization's sacred cows. That shows the developers that the company is behind them and illustrates the importance of the project. Your actions say, "We are committed to releasing this product, and we will do whatever it takes to make that happen." Sacred cows vary among different organizations, but as long as you're breaking precedent, the developers will get the message. Let them come to work later than the rest of the organization. Let them go home early. Suspend the dress code. Move them off-site. Buy them the new large-screen monitors they've wanted. Bring in catered meals. In short, make them feel important. To your project, they are.

One of the most sacred of sacred cows to a project that's behind schedule is the disallowance of time off. If you've been in 3-weeks-until-product-release mode for several months, not only will time off be appreciated by the developers, it will be necessary to keep your team healthy and productive. A whole weekend off can seem like a lifetime to a developer who has been working with no end in sight.

Be sure that you're providing for the team's hygiene factors. Remove excessive schedule pressure, poor working conditions, management manipulation, and other morale killers.

Clean up major personnel problems. The most common complaint about team leaders is that they don't address problems caused by troublesome team members. If you think you have a problem person, face up to that fact and eliminate the problem. Replace uncooperative team members even if they're key contributors. They cost more in team morale than they contribute technically. You're regrouping anyway, so this is a good time to cut your losses.

Clean up major leadership problems. The leader who has brought the project to the brink of disaster might not have enough credibility left to make the changes needed to lead the project to success. In some cases, the ineffective leader is the technical lead; in other cases, it's the project manager. If you're in a position to do so, consider shaking up the project leadership. Replacing the leader is one option, but if you're the technical lead, you probably can't fire an ineffective manager. If you're the manager, firing a technical lead isn't always the best course of action anyway. Fortunately, several options that are more subtle and often more effective than "you're fired!" are available.

These points focus on management changes, but they apply just as well to changes in the project's technical leadership.

Add people carefully, if at all. Remember Brooks's law that adding people to a late project is like pouring gasoline on a fire (Brooks 1975). Don't add people to a late project willy-nilly.

But remember the whole law. If you can partition your project's work in such a way that an additional person can contribute without interacting with the other people on the project, it's OK to add a person. Think about whether it makes sense to add someone who will spend 8 hours doing what an existing developer could do in 1 hour. If your project is that desperate, go ahead and add someone. But stick to the plan. Some people can't abide watching another person spend 8 hours on a 1-hour job regardless of their original intentions. Know what kind of person you are. If you think you might err, err on the side of not adding anyone.

Focus people's time. When you're in project-recovery mode, you need to make the best possible use of the people who are already familiar with the project. Consider taking the money you would have spent adding people and use it instead to focus the efforts of your existing people. You'll come out ahead.

You can focus existing people in a variety of ways. Give them private offices. Move them off-site. Be sure that they are not distracted by other projects within your organization, so relieve them of tech-support duty, maintenance of other systems, proposal work, and all of the other responsibilities that eat into a developer's time. The point is not to hold their noses to the grindstone, but to relieve them of all nonessential tasks.

If you must hire additional people, consider not hiring developers. Hire administrative people who can take care of clerical work and help your developers minimize personal downtime (for example, laundry, shopping, bill paying, yard work, and so on).

Allow team members to be different. Some people will rise to the challenge of project recovery and become heroes. Others will be too burned out and will refuse to give their all. That's fine. Some people want to be heroes, and other people don't. In the late stages of a project, you have room for quiet, steady contributors who don't rise to heroic heights but who know their way around the product. What you don't have room for are loud naysayers who chide their heroic teammates for being heroic. Morale during project recovery is fragile, and you can't tolerate people who bring the rest of the team down.

See that developers pace themselves. Runners run at different speeds depending on the distance to the finish line. Runners run faster toward a nearby finish line than they do toward a finish line that's miles away. The best runners learn to pace themselves.

Allow your team to break the vicious circle of schedule pressure leading to stress leading to more defects leading to more work leading back to more schedule pressure. Ease the schedule pressure, give the developers time to focus on quality, and the schedule will follow.

Although you'll find your greatest leverage in the area of people, you must also clean up your process if you want to rescue a project that's in trouble.

Identify and fix classic mistakes. Survey your project to see whether you're falling victim to any of the classic mistakes. Here are the most important questions to ask:

Fix the parts of your development processes that are obviously broken. When a project is in trouble, everyone usually knows that a few parts of the process are broken. This is where back-to-basics really comes into play—the broken parts are often broken because the project has consciously or unconsciously been ignoring the software fundamentals.

If the team is tripping over itself because you haven't set up version control, set up version control. If you're losing track of the defects being reported, set up a defect tracking system. If end-users or the customer have been adding changes uncontrollably, set up a change-control board. If the team hasn't been able to concentrate because of a steady stream of interruptions, move them off-site, have the facilities group physically wall-off their area, or put up your own floor-to-ceiling boundary with empty computer boxes. If people haven't been getting the timely decisions they need, set up a war room: meet at 5:00 p.m. every day and promise that anybody who needs a decision will get one.

Create detailed miniature milestones. In rescuing a drowning project, it is absolutely essential that you set up a tracking mechanism that allows you to monitor progress accurately. This is your key to controlling the rest of the project. If the project is in trouble, you have all the justification you need to set up miniature milestones.

Miniature milestones allow you to know on a day-by-day basis whether your project is on schedule. The milestones should be miniature, binary, and exhaustive. They're miniature because each of them can be completed in one or two days, no longer. They're binary because either they're done or they're not—they're not "90 percent done." They're exhaustive because when you check off the last milestone, you're done with the project. If you have tasks that aren't on the milestone schedule, add them to the schedule. No work is done "off schedule."

Setting and meeting even trivial milestones provides a boost to morale. It shows that you can make progress and that there's a possibility of regaining control.

One of the biggest problems with setting up mini milestones at the beginning of a project is that you don't know enough to identify all the work in detail. In project-recovery mode, the situation is different. At that late stage in the project, developers have learned enough about the product to be able to say in detail what needs to be done. Thus mini milestones are particularly appropriate for use in project recovery.

Set up a schedule linked to milestone completion. Plan completion dates for each mini milestone. Don't plan on massive overtime: that hasn't worked so far, and it won't work going forward. If you plan massive overtime into your schedule, developers can't catch up by working more overtime when they get behind. Set the schedule so that if developers get behind on their miniature milestones, they can catch up by working overtime the same day. That allows them to stay on schedule on a day-by-day basis. If you stay on schedule day by day, you stay on schedule week by week and month by month, and that's the only way it's possible to stay on schedule for a whole project.

Track schedule progress meticulously. If you don't track progress after you set up the mini milestones, the schedule-creation process will have been just an exercise in wasting time. Check with developers daily to assess their progress against the mini milestones. Be sure that when a milestone is marked "done" it is truly, 100 percent done. Ask the developer, "If I take the source code for this module that's 'done' and lock it in a vault for the rest of the project, can we ship it? Do you still have some tweaking or polishing to do, or is it 100 percent done?" If the developer says, "It's 99 percent done," then it's not done, and the milestone has not been met.

Do not allow developers to get off track on their mini-milestone schedules. The easiest way to get off track is to miss one milestone and then to stop keeping track. A 1-day slip turns into a 2-day slip, which turns into 3 days, and then into a week or more. Soon there is no correspondence between the developer's work and the milestone schedule. Once a schedule has been calibrated, do not take schedule slips lightly. If a single developer falls behind on a single milestone, expect him or her to work overtime that day to catch up. (If a developer meets a single milestone early, it's OK to allow him or her to go home early that day.) Daily milestones must be met consistently or the schedule must be recalibrated so that they can be met consistently.

Record the reasons for missed milestones. Having a record of the reasons that each milestone was missed can help to detect the underlying causes. A record might point to an individual developer's need for training or highlight organizational dynamics that make it hard for any developers to make good on their estimates. It can help to distinguish between estimate-related problems and other schedule-related problems.

Recalibrate after a short time—one or two weeks. If a developer consistently misses milestones and falls more than ½ day behind, it's time to recalibrate that developer's schedule. Recalibrate by increasing the current schedule by the percentage of the slip so far. If the developer has needed 7 days to do 4 days' work, multiply the rest of the work by . Don't play games by thinking that you'll make up the lost time later. If you're in project-recovery mode, that game has already been lost.

Don't commit to a new schedule until you can create a meaningful one. Do not give a new schedule to upper management until after you have created a mini-milestone schedule, worked to it for at least a week or two, recalibrated, and worked a week or two more to check your recalibration. Giving a new schedule to management any other way is tantamount to replacing one bad schedule with a different but equally bad schedule. If you follow these steps first, you will have a more solid basis for your future schedule commitments.

Manage risks painstakingly. Focus on risk management using the guidelines spelled out in Chapter 5, Chapter 5. Create a top-10 risks list, and hold daily risk-monitoring meetings. You can expand the 5:00 p.m. war-room meetings to review risks and address new issues that have arisen as well as to provide timely decisions.

It's often not possible to recover a project until you rein in the product's feature set.

Stabilize the requirements. If requirements have been changing throughout the project, you don't need to look any further for the source of your problems. You must stabilize requirements before you can bring your project to a successful conclusion. A system with significantly changing requirements cannot be developed quickly and often cannot be developed at all.

It is not uncommon to need to do a nearly complete requirements specification at this stage. Some products change so much during their development that, by the time the crisis hits, no one knows for sure what features the product is supposed to contain. Developers and testers are working on features that might or might not need to be in the product.

Some projects will resist the work involved with formalizing a statement of requirements this late in the project, but keep in mind that the other approach is the one that's causing all the problems. You have to do something different, and you have to know what your feature set is before you can finish the product, before you can even be sure that the development team is working on the product you want.

If the project has been running for some time, formalizing requirements will be a painful step because it will involve eliminating some people's pet features. That's too bad, but it should have been done early on, and it has to be done before you can complete the project. If you can't get the parties involved to commit to a set of requirements when the project is hanging on by its fingernails in recovery mode, then you might as well give up. You're fighting a battle you can't win.

After you do get a set of requirements, set the bar for accepting changes very high. Require a full day even to consider a change. Require more than a day as the minimum time needed to implement a change. (This is for feature changes, not defect corrections.)

Trim the feature set. Recovery mode presents an opportunity to reduce the requirements to the minimal acceptable set. Cut low-priority features ruthlessly. You don't need to fix everything, and you don't need to implement every feature. Prioritize. Remember, the real problem at this stage is not developing the product in the shortest possible time or creating the best possible product: it's completing the product at all. Worry about low-priority features on the next version.

People should be ready and willing to define a minimal feature set at this point. If they aren't willing to sacrifice pet features when the project is in recovery mode, they probably won't ever be willing to.

Assess your political position. If people aren't willing to freeze requirements or fall back to minimal requirements, this is a good time to take a step back and look at what's really happening on your project. Think about why the other parties are still not focused on the product. What are they focused on? What is more important to them than the product? Are they focused on a power struggle? Are they focused on making you or your boss look bad? As ugly as organizational politics can be, they do exist, and an unwillingness to make crucial compromises when there's no other choice is a telltale sign. If you're caught in the middle of a political skirmish rather than a product development, the project-recovery plan in this chapter won't be of much help, and you should choose your actions accordingly.

Take out the garbage. Find out if there are any parts of the product that everyone knows are extremely low quality. When you've found a lot of defects in a particular piece of code, it's tempting to think that you've found the last one. But buggy modules tend to produce an amazing, continuing stream of defects. Error-prone modules are responsible for a disproportionate amount of the work on a project, and it is better to throw them out and start over than to continue working with them.

Throw them out. Go through a design cycle. Review the design. Implement the design. Review the implementation. This will seem like work that you can't afford when you're in recovery mode, but what will really kill you in recovery mode is getting nickeled-and-dimed to death by an uncontrollable number of defects. Systematic redesign and implementation reduces your risk.

Reduce the number of defects, and keep them reduced. Projects that are in schedule trouble often start to focus on schedule and expedient shortcuts to the exclusion of quality. Those compromises invariably return to haunt the developers before the product is released. If you've been in 3-weeks-to-ship mode for awhile, you've almost certainly been making quality compromises and shortcuts during that time that will make your project take longer rather than shorter.

Start using an "open-defects" graph, and update it daily. Figure 16-2 is an example.

Figure 16-2. Example of an "open defects" graph. Publishing this graph emphasizes that reducing defects is a high priority and helps to gain control on projects with quality problems.

The goal of the open-defects graph is to emphasize how many open defects there are and to highlight the priority of reducing them. Bring the number of open defects down to a manageable level, and keep it there. Start using design and code reviews to maintain a consistent level of low defects. Development time is wasted working and reworking low-quality software. Focusing on quality is one way to reduce development time, and doing so is essential to project recovery.

Get to a known good state, and build on that. Plot out the shortest possible course from wherever your product is now to a state at which you can build and test some subset of it. When you get the product to that point, use daily builds to keep the product in a buildable, testable state every day. Add code to the build, and make sure that the code you add doesn't break the build. Make maintaining the build a top priority. Some projects have developers wear beepers and require them to fix the build day or night if they are responsible for breaking it.

Surprisingly, the best time to launch a project-recovery plan might not be the first moment you notice your project is in trouble. You need to be sure that your management and the development team are ready to hear the message and ready to take the steps needed to truly recover the project. This is something that you need to do right the first time.

You have to walk a line between two considerations. If you launch your recovery plan too early, people won't yet believe that there's a need for it. It is not in your best interest to cry "Wolf!" before other people can see that the wolf is there. If you launch it too late, it will likely follow on the heels of a series of small corrections or mini-recovery attempts that didn't completely work, and you will have undermined your credibility in leading a more effective, larger-scale recovery effort. You will have cried "Wolf!" too many times.

I don't recommend letting your project run into the weeds merely so that you can do a better job of rescuing it. However, if your project has already run into the weeds, I do recommend that you time the presentation of your recovery plan so that everyone else on the project will be receptive enough for it to succeed.