Late Project: Feature Cuts

Feature-set control continues to be important through the end of a project. Even if you were successful at specifying a minimum feature set up front and controlling changes through the middle of the project, for a variety of all-too-familiar reasons you can still find yourself behind schedule at the end of the project.

By the time you reach that point, one of the most potent schedule-reduction options is the elimination of low-priority features. This practice is effective because it eliminates effort associated with further implementation, testing, and documentation. This practice is in common use at Microsoft, where it has been found to be an effective means of reigning in late software projects (Cusumano and Selby 1995, McCarthy 1995b).

The drawback of this practice is that by the time you reach the end of the project, you've probably already done the design work and part of the implementation and testing for the features that you cut. You might even have to do some small amount of work to remove the feature—strip out unused code or disable it, remove test cases that exercise the feature, remove documentation that refers to the feature, and so on. If you plan to release another version of the product, this is only a small problem because you'll eventually use the work that you strip out or disable for the current version.

For maximum efficiency, start with a scrubbed requirements document, design and implement the features you know will be in the product, and then add lower-priority features if you have time. Don't waste time working on features that will be cut later.

If you don't think you can live up to that ideal, then plan ahead for the eventuality of cutting features late in the project. Use a lifecycle model such as evolutionary prototyping, evolutionary delivery, design-to-schedule, or design-to-tools that supports late-project feature changes.

CROSS-REFERENCE

For more on development styles that support late-inthe- project changes, see Chapter 7, Chapter 7.

Case Study: Managing Change Effectively

Six weeks before Square-Calc 4.0 was scheduled to ship, Kim walked into Eddie's office. "Eddie, we've got a problem. Our competitors have just released a new version, and it has several new features that our product doesn't have. We need to add some new features before we ship this product."

Eddie nodded. "OK. Make a list of the new features, and we'll discuss them at the change-board meeting this afternoon." Kim agreed and went back to her office to prepare the list.

At the change-board meeting, Kim proposed a dozen new features that their competitor's new product had and their new product did not. She felt strongest about the fact that their competitors had greatly simplified their menus, moving many items to context-sensitive pop-up menus. She argued that this seemed like a major user-interface enhancement, and their product would look out of date if it came out without similar menus.

After Kim finished describing the new features, Eddie took over. "First of all, it will probably push our schedule out about a day just to estimate this many changes. Does the group think that these changes are important enough to justify the estimation time?" The group agreed that they were that important. "OK, then," Eddie said. "I'll distribute these new features as change requests to all of the affected groups. I don't want to interrupt their workflow any more than necessary at this critical stage in the project, so I'll give them a few days to respond. Let's plan to decide on these changes at our regular change-board meeting next week." The group agreed, and the meeting broke up.

At the next meeting, the estimates were ready. "According to these preliminary estimates, it would push our schedule out 3 to 4 months to implement all of these changes," Eddie reported. "Development considers them to be relatively minor changes and estimates that they could implement all of them in about 4 weeks, but testing and documentation would be more strongly affected. The pop-up menu change is the most costly in terms of calendar time because it significantly changes the program's user interface. Testing says that that change alone would require rewriting about a third of their test cases, which would take about 6 weeks. Documentation has a long lead-time for printing, and they are scheduled to go to press at the end of this week. They would have to change 80 percent of their document pages and help screens, reshoot virtually all of their screen shots, and then redo their final proofing cycle. That would push their schedule out 3 to 4 months, depending on how quickly they can hire a contract writer. The usability group is lukewarm about whether we should even make this change, so I don't think it's worth doing."

"I still think it's important," Kim said. "But I don't think we should slip the schedule 3 months for it." The group quickly agreed to postpone the pop-up menu change. They added it to a list of features to be considered for the next version.

From among the rest of the change requests, the change board identified three that were estimated to have a total impact on development, testing, and documentation of 1 week. Carlos from marketing wanted those new features and said that a 1-week slip was an acceptable price to pay. The board accepted those changes. Five more changes were identified as features they would like to add if they had time, but the board concluded that they weren't important enough to move the release date. They added those changes to the list of features to be considered for the next version and rejected the remaining requests.

After the meeting, the affected groups were notified of the change board's decision. Since each group's input had been considered in the decision, they all adjusted their schedules accordingly and took the changes in stride.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.202.209