Managing the Baseline

Successful development managers create margins for error in estimating effort and allow for time to incorporate legitimate changes during the development cycle. These managers also resist feature creep, which Weinberg [1995] notes can increase scope by as much as 50 percent to 100 percent after the start of a project. Focusing the development effort on the customer's critical priorities can mitigate even hostile political environments. With scope negotiated to an achievable level, and with development focused almost exclusively on the customer's "must haves," the team will establish credibility by meeting schedules with quality and, occasionally, with utility that could not have been predicted in advance.

However, your customers, be they internal or external, naturally want as much functionality as possible with each release of a software system. After all, it's the functionality that delivers the added value they need to meet their business objectives. Indeed, we must have a healthy respect for customers who are demanding, for they are the ones who will ultimately be the most successful in the marketplace . Demanding, competent customers are the only ones really worth having.

Left unchecked, however, the demand for more and more functionality can compromise the quality and the overall viability of the project. More becomes the enemy of adequate. Better becomes the enemy of good enough .

If we were operating in a business sector where the physics are better defined, where the industry had a few hundred years of experience in reliably delivering the goods, things would be different. But we operate in the software world; the physics are indeterminate, the processes are immature, and the technology changes with every application. Let's first focus on learning how to get the job done right: enough functionality at the right time to meet the customer's real need . We can tune our process later to see if we can exceed expectations, but for now, let's focus on just meeting them! In order to do so, we need to manage the baseline.

Once established, the baseline provides the center of focus for many project activities. The features baseline can be used to assess progress more realistically . Resources can be adjusted, based on progress relative to the baseline. The features within the baseline can be refined into further detail suited for code development. Requirements traceability can be applied from user needs to the features in the baseline. Traceability can be further extended from features into additional specifications and implementation.

Perhaps most important, the high-level baseline can be used as part of an effective change management process. Change is an integral part of every application development activity. Managing change is so critical that we have devoted Chapter 28 to this topic. For now, we'll look at how we can apply the features baseline to this important aspect of software management.

Official Changes

The features baseline provides an excellent mechanism for managing high-level change. For example, when the customer requests a new system capability (an official change) and that capability is not part of the features baseline, the impact of the change must be assessed before including the new feature in the baseline. If the project team has done a good job of defining the baseline to begin with, the assumption must be that any change to the baseline must affect the resources, the schedule, or the features set to be delivered in the release.

If the resources are fixed and the schedule cannot be changed, the project team must engage the customer in a decision-making process that prioritizes the new feature relative to the other features scheduled for the release. If the new feature is critical , it must, by definition, be included in the release, and the customer and the project team should jointly determine which features will be excluded from the release or at least lowered in priority, with accompanying lower expectations. If the feature is important but not critical , the project team can proceed with the implementation of the feature on a best-efforts basis, allowing progress to dictate whether the feature makes the release.

Unofficial Changes

Paradoxically, the problem of customer-initiated change may be the easiest scope management challenge to handle. It is externally focused, we can establish certain safeguards, and the impact of change can be assessed and made clear to this external stakeholder.

However, experience shows that another class of change threat is even more subversive to the development process. In Chapter 28, we will discuss the hidden dangers of various forms of change and gain additional ammunition with which to address the scope management challenge.