What to Do When Your Project Slips

©2001 Johanna Rothman, www.jrothman.com

You’re not going to meet schedule. Maybe requirements have taken longer. Perhaps in the middle of implementation, you uncover something requiring redesign. Maybe developers haven’t met one milestone yet and you’re worried about the test time. What do you do?

The first slip is the initial indication that something is wrong. Don’t think you can make up time. You can’t. Use the first slip to evaluate what’s going on vs. what you’d like to have going on. When you hit the third or fourth slip, you’ve lost the schedule battle.

Early Schedule Slips

When software projects begin slipping, they’re talking to you. The first slip is a whisper: “Your expectation is not matching my reality. Listen. I can tell you my reality.” If you ignore the first slip, the second slip is a murmur: “Things aren’t quite right. Don’t you want to know what’s going on?”

By the third slip, the project says: “Knock-knock. Are you there? Don’t you want to know what’s going on?” At the fourth slip, the project yells: “Hey, you! You didn’t listen when you could act. Now you’ll have to pay.”

As an observant project manager, when you detect an early schedule slip, you have several options, all related to the project quality requirements and project constraints common to every project:

With an early slip, you can change all, or a combination of these: change the ship date or feature set, allow different defect levels, increase project cost, add more people, or change the work environment.

Mid-Project Schedule Slips

After a couple of schedule slips, when you’re in detailed design or early implementation, it may be possible to inject more people into the project, or change the way you work. I’ve had success with design inspections from people outside the project when we realized the design was not going as well as it should. If you’re in early implementation, maybe you can change the feature set or allow more defects, and still ship on time. If you consider the project requirements and project constraints, changing the feature set or allowing different defect levels are no longer options at this stage.

It’s easiest to slip the ship date, increase the project cost, or change how people work. If you can’t slip the ship date, then you must change how people work. Reviews and inspections can help the design and implementation effort dramatically. The implementation may not meet its milestone date, but with reviews and inspections, you may be able reduce the rework and therefore, some of the test time.

It’s much harder to decrease the feature set (some features may be coupled), or achieve low defect levels in the same amount of time. Generally, it’s also difficult to get more people on the project, but you may be able to hire some people with specific skills: automated test developers or exploratory testers, an external architect to help look at the design, more project managers on a large project. When you add more people to the project, ensure everyone understands their roles so that you don’t slow the project.

Late in the project slips

I recently worked with a company just before they planned to ship a beta release. They were having trouble getting the software ready and they wanted help completing the work done by their beta date. I had questions about the schedule, defect data, testing, and how the developers integrated the code. My first question addressed schedule. “Oh, we planned the schedule six months ago. We haven’t changed it.” I asked if they’d met their milestones. “Well, not really. We missed the first deadline. The requirements weren’t done, but we had to get started, so we started designing without knowing all the requirements.” This is risky, but not a Terrible Thing, especially if they planned to manage the risks. I asked about the other milestones. “Well, since the requirements weren’t done, we couldn’t finish the design on time. Since the design wasn’t done, the coding was late.” The first slip cascaded into every other milestone. Then came the key question: “When did the testers know what to test, if the requirements, design, and implementation were late?” The answer? “Last week.” Uh oh.

I asked one more question: “How much testing did you plan for this project?” They looked at each other. “Well we planned about six weeks worth, but I guess we won’t get to that now.” These people were not stupid. They had a simple problem with a huge cascading effect. Then they had trouble hearing the reality of their project. They started with a small slip, but because they kept going, it magnified the effect of later slips. If they had stopped at the first slip and re-planned their work or schedule, they might have met their beta date. Now, their only option was to extend the schedule.

It’s extremely difficult to recover from late-in-the-project slips. Our only options are to extend the schedule, increase project costs, or change the work environment. In this situation, see if you can change what people are doing. I find that peer review or inspections of every fix helps reduce the number of bad fixes. If you can reduce the amount of rework, especially from bad fixes, you can stop having to extend the schedule. It’s extremely difficult to add more people unless the testers have not yet had a chance to design the tests -you might then be able to use more exploratory testers to save some time.

Summary

If you’re still early in the project you have some options and the most appropriate ones for you depend on what’s driving your project. Clarify your project’s requirements and constraints and you’ll know better what to do. You can reduce the feature set by using peer review on all fixes (to decrease the number of bad fixes), and re-plan the rest of the schedule in detail with the technical staff, using inch-pebbles. If you’ve lost the schedule battle, give up and cut your losses.

Schedule slips are a useful indication that something is not-quite-right on your project. Use that information to make the best decision for your project.