Case Study: Systematic Risk Management

Square-Calc version 3.0 had been a disaster, overrunning its schedule by 50 percent. Eddie agreed to take over the project with version 3.5, and he hoped to do better than the last manager had done.

"As you know, Square-Calc 3.0 didn't do very well compared to its planned schedule," he told the team at the first planning meeting. "It was scheduled to take 10 months, and it took 15. We need to do better. We've got 4 months to complete a medium-sized upgrade, and I think that's a reasonable amount of time for this work. Risk management is going to be a top priority. The first thing I want to do is appoint a risk officer, someone who will look for all of the things that might go wrong on this project. Is anyone interested?"

Jill had worked a lot harder than she wanted to on the last project and was willing to help prevent that from happening again so she said, "Sure, I'm interested. What do I need to do?"

"The first thing you need to do is create a list of known risks," replied Eddie. "I want you to get together with each of the developers this morning and find out what risks they're aware of, and then I want to get together with you this afternoon. We'll look at the risks and go from there."

That afternoon, Eddie and Jill met in Eddie's office. "Everyone, including me, thinks that the biggest risk is the Square-Calc 3.0 code base. It really sucks," Jill said. "None of us wants to make any major changes to it, and there are certain modules we don't even want to touch.

"The next most important risk is the user-documentation schedule. We shipped late last time partly because we didn't coordinate well enough with user documentation. We've got to make sure that doesn't happen again.

"The last big risk is creeping requirements. There were a lot of features that didn't make the cutoff for version 3.5, and I'm afraid that marketing will try to shoehorn them in." Jill went on to note a dozen smaller risks, but the first three were the big ones.

"OK, I want us to come up with a risk-management plan for the major risks," Eddie said. He explained the idea of the Top-10 Risks list to her and said that he wanted to review the top 10 risks with the team every week.

To manage the code-base risk, they decided to analyze their bug database to see whether any modules in the system were truly error prone. They allocated 1 month of their 4-month schedule to focus on rewriting the most error-prone modules.

For the user-documentation risk, they decided to develop a throwaway user-interface prototype that exactly matched the appearance of the new code they'd be writing. They would not allow visual deviations from the prototype. They would also include a rep from user documentation in their weekly risk-management meetings, which would help them to stay in synch with the documentation effort.

For the feature-creep risk, Eddie promised to talk with someone in the marketing department. "I know their number-one goal is to get the product out on time," he said. "We need to restore customer confidence after the schedule problems on 3.0. I'll explain the importance of setting crystal-clear goals to them, and I think that will cut down on the feature requests." They also invited Carlos from marketing to attend their risk meetings, reasoning that if someone from marketing understood all the other risks they faced, marketing might be less inclined to pile on new risks themselves.

During the next 4 weeks, identification and replacement of the error-prone modules went about as planned. It turned out that about 5 percent of the modules accounted for about 50 percent of the errors. They were able to redesign and reimplement those at a careful pace. They subjected each module to a thorough review at each stage, and by the time they were done, they felt comfortable that the code base could sustain the rest of the modifications they needed to make for version 3.5.

At the weekly risk meeting 6 weeks into the schedule, Jill raised a new issue. "As you know, I've been monitoring some lower-priority risks in addition to the bigger ones, and one of them has become more important. Bob has been working on speeding up some of the scientific functions, and he told me a few weeks ago that he wasn't sure he could meet the revised spec. Apparently he researched the best available algorithms, implemented them, and that only made the functions about 50 percent faster. The spec calls for a 100-percent speedup, so Bob's been trying to come up with faster algorithms. I told him that I wanted to set a red-alert point in the schedule so that if he wasn't done at that point I could raise a warning flag. Yesterday we hit the red-alert point, and Bob says he is nowhere near being done. Basically, I think he's doing software research, and there's no way to predict how long he's going to take."

Carlos from marketing spoke up. "I was one of the people who pushed for the speed improvement, and I think that `100 percent' number is flexible. It's more important to me to get the product out on time than it is to meet that performance requirement to the letter. At least we'll be able to show our customers that we're responsive."

"That sounds good," Eddie said. "I think the 50-percent improvement we've already reached is good enough, so I'll redirect Bob to some other tasks. That's one less risk to worry about."

After that, there were few surprises. Minor issues arose and were addressed while they were still minor. Compared to the last project, this one seemed a little boring, but no one minded. A few marketing people tried to add features, but Carlos understood the importance of the schedule goal, and he fended off most of the requests before development even heard about them. The team performed well, and they delivered Square-Calc 3.5 by the 4-month due date.