Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996. 660 pages. Retail price: $35. ISBN: 1-55615-900-5. Available from Microsoft Press 1-800-MS-PRESS (1-800-677-7377). Buy Rapid Development from Amazon.com.

Case Studies in Project Recovery 

Case 1: An Unsuccessful Project Recovery

Carl's inventory-control system project, ICS 2.0, was racing toward the finish line. His team had been working on the system for a little more than four months, and now the deadline was three weeks away. He called the team meeting to order. "According to the schedule, everybody should be checking in the final versions of their code this week. How's that going?"

"Pretty good, but not good enough," Joe responded honestly. "I've run into a few problems, and I'm working as hard as I can, but I don't see anyway I can finish in less than five weeks."

"That goes double for me," Jennifer said. "I'm making good progress, but this never should have been scheduled as a five-month project. It's more like a seven-month project. I've got five or six weeks of work left."

Carl instinctively reached for his Rolaids. "All right. I'm going to think about how to break this news to my boss, Bill. Give me the rest of the day to come up with a recovery plan, and I'll let you know the plan."

The next day, Carl laid out his plan. He had talked his boss into sliding their schedule three weeks. He was going to borrow Kip from another group to help Jennifer and Carl. And he had a line on a top-notch contractor named Keiko to pick up the rest of the slack.

"Are you serious," Jennifer asked, incredulously. "Haven't you heard of the mythical man-month syndrome? Adding developers at this point will make our project later. It'll take a lot of time to get two new people up to speed. It'll take a lot of my time."

"I've thought of that, and I want to avoid that problem too." Carl said. "I think we can divide up our project so that you hardly notice the two new developers. I'll train them myself."

"They might be able to help a little," Joe chimed in. "But I honestly need five weeks, and I don't see any way to divide up my work so that I can give any of it to anyone else."

"Are you signed up for this project or not?" Carl said. "The project isn't in that much trouble. Just do your best, and let's see what happens. OK?" Jennifer and Joe didn't see any point in arguing, so they said OK and went back to work.

They worked almost non-stop for the next three weeks, but at the end of that time they were barely any closer to the finish line. "How are we doing," Carl asked.

"About the same," Jennifer reported. "I've still got at least four or five weeks worth of work left."

"Same here," Joe reported.

"What have you guys been doing?" Carl fumed. "Jennifer, you said you had six weeks of work left, and that was three weeks ago. How can you still have four or five weeks left?"

"Some things took longer than I expected," she said. "Plus, no offense to Kip and Keiko, but getting them up to speed is taking a lot of time. They didn't understand how we handle our source-code files, and Keiko overwrite some of our master source files. Recreating them took Joe and me several days."

"How could he overwrite your files?" Carl asked. "Aren't you using automated source-code control and making periodic backups?"

Jennifer's patience was wearing thin. She was tired and had poured everything she had into the project. "Listen, we've been going all-out for more than two months. We're doing our best. No one's had time to setup automated version control, and we've just had a couple of minor setbacks. Look, I said I'll be done in four or five weeks, and that's when I'll be done." The meeting broke up, and Carl optimistically told Bill that the team would be done in four weeks.

Four weeks later, the team reported making good progress, but they still thought it would be another three weeks or so until they were done. A few weeks after that, Jennifer and Joe discovered some design flaws that they couldn't code around, and they had to redesign a major chunk of the system. Each bug fix seemed to cause two more defect reports, and the group's estimated completion times started getting further away instead of closer. Carl admitted that he didn't really know when the project would be finished.

Two months later, after three more three-week schedule slips, Bill canceled the project. He notified the users that they would have to continue using ICS 1.0 or find an off-the-shelf substitute.

Case 2: A Successful Project Recovery

End-user reaction to canceling the new inventory-tracking system had been fierce, and a few weeks after he canceled the project, Bill reconsidered. He concluded that they should finish it after all. By that time, Keiko, the contractor, had moved on to a different project. Kip had been reassigned to a short-term project, but they could get him back. Jennifer and Joe were just returning from vacation, and Bill thought they might be ready to go. He called Carl into his office.

"Carl, I've decided to resuscitate ICS 2.0, and I'm going to give you another chance. Meet Charles. He's a project-recovery expert, and I've hired him to help you bring this sucker in. He's already told me that you can't come up with a new schedule right away. He said it might take a few weeks before we know exactly how long it will take to fix the project. I really got my ass chewed for canceling this thing, so now we've got to finish it no matter what. Let me know as soon as you have a new schedule."

Carl was glad to get another chance at rescuing the project. He had thought of some things he could do better, and he knew that Jennifer and Joe had been depressed about the project being canceled. He and Charles left Bill's office together.

Charles started talking. "From what I've heard, I think the main task here is just to finish the project. I'd like to identify each group's win conditions, and then manage the rest of the project so that those are met. Based on the end-users I've talked to, getting a replacement for the old system by the end of the year would be a win as long as it fixes a few long-standing problems. I've got a list of the major problems, and I got them to agree that the rest could wait. Of course they'd like the next release sooner, but they really just want a guarantee that they'll get it eventually.

"Bill's win condition is the same. He wants to follow-through with the user group. What do you need to make this a win for you?"

Carl thought a minute. "I need to show that I can rescue this project and meet everybody else's win conditions. I've had a rest, and I can work as hard as I need to." Later that day, Carl talked to Jennifer, Joe, and Kip. Their win conditions were that they wanted to finish the job they'd started, and they wanted to lead normal lives outside work while they were doing that.

"I can't sacrifice the rest of my life to this project anymore," Jennifer said. "Even after three weeks of vacation I'm too burned out to do that. It would be nice to finish this project, but I'd rather work on a different project and never finish this one than get that burned out again." Kip said he was willing to work hard, but Joe said he felt the same as Jennifer.

Charles asked the team what they thought needed to be done to save the project, and Jennifer and Joe were in complete agreement. "We were in such a hurry last time that we took all kinds of low-quality shortcuts. We need to go back and clean up some of the product. We shouldn't add any new people this time, either." Carl agreed. He didn't want to make the same mistake twice.

Charles stepped in. "What I'd like you all to do is create a detailed list of every task that needs to be done to release the product, and I really mean everything. Rewriting bad modules, fixing the build script, setting up automated version control, documenting old code, duplicating diskettes, talking to end-users on the phone, everything. And I want you to estimate how long each task will take. If you have any tasks that take more than two days, I want you to break them up into smaller tasks that take less. Then we're going to sit down and plan out the rest of the project.

"I want you to know that your estimates aren't commitments. They're just estimates, and nobody outside of this room will know about them until we're confident that they're right. I know I'm asking for a lot of detail, and it will take time to do all those estimates. I wouldn't be surprised if it takes you at least a day to come up with them. But this project is broken, and this is what we need to do to get it back on track"

The developers spent the next two days coming up with incredibly detailed task lists. Joe was surprised at some of his estimates. He took tasks that he had originally estimated would take three days, broke them down into more detail, and found that the sum of the parts for a few of them was more like five or six days. Charles said he wasn't surprised. The whole group put together a schedule based on the detailed task lists, and Charles told Bill that they would have a revised completion date in about fifteen days.

Carl and Charles checked the team's progress every day for the next week. Kip completed his tasks consistently on time. Jennifer found that one day she finished all of her work by mid-afternoon, and one day she had to work until nine o'clock in the evening. She was getting the work done, but by the end of the week she had logged almost 50 hours. She told Carl that that was too much. Joe had had trouble completing his tasks on time, and by the end of the week he had completed only half of what he had planned.

The team met to look over their progress. Charles insisted that they recalibrate Joe's schedule by multiplying all of his estimates by 2.0. Even though Jennifer was meeting her deadlines, he reminded them that Jennifer's win condition included leading a normal life outside of work, and they recalibrated her schedule by multiplying her estimates by 1.25. The recalibration made everyone's schedules come out uneven, so they reshuffled the work so that everybody on the team had about the same amount of work.

Carl was surprised at the result. If their estimates were right, they would finish the project in 10 weeks, which wasn't nearly as bad as he had feared. "Should I give Bill the good news?" he asked Charles.

"No, we'll work another week to the recalibrated schedule, and if we're hitting the mini milestones consistently, then we'll tell Bill. But we will let Bill know that we'll have a revised schedule for him a week from Monday."

The next week went surprisingly smoothly. Carl continued to check with each developer every day to be sure that each milestone task was getting done, and each one was. Jennifer stayed late one night, but she told Carl that was mainly because she had goofed off part of the day, not because she had too much work to do. By the end of the week, everybody was on schedule. More important, everybody was happy. Jennifer had originally thought she would be annoyed by the mini-milestones' micro-management, but it actually felt good to be able to check off a task every day and to tell someone that she was making progress. Morale had returned.

Carl and Charles told Bill that they would be done in nine weeks. Bill said that was good news and had been worth the wait. For the remainder of the project, Charles and Carl continued to check progress daily. Each person put in a few late nights to keep to their mini-milestone schedules, but by the end of the nine weeks they were really and truly finished. They delivered the software to their end-users and notified Bill. Everyone considered the project a win.

This material is Copyright © 1996 by Steven C. McConnell. All Rights Reserved.