Scope Management: Cut Early and Often

At the beginning of this chapter, we said that reality hits home in the Elaboration phase. You begin to see what you can and cannot do in the time you have, with the budget allocated, and the resources available. Even though our project was a part-time project with no fixed end date, we were forced to confront the limitations of what we could do and what we were prepared to do.

The best example of this brush with reality came early in the Elaboration phase. In retrospect, our vision was grandiose. We planned to create a general-purpose PSP tool that would allow the user to select specific processes for a given database. We envisioned users selecting a process from a menu when they created a new project database. The software would then populate the database with the correct tables, phases, and other data needed to support the process. In the PSP description as defined by Watts Humphrey, there are different levels of PSP and different forms and data items that are recorded for each level. The purpose of PSP is to become better at estimating and delivering quality, so it is natural to assume that as engineers improve, they will want to use a higher level of PSP implementation.

We even thought it would be a great idea to let users create their own forms and develop their own personal process. The emphasis here is that we thought it would be a great idea! Russell didn't care. Russell wanted an implementation of PSP level 0.1 or 1.0 that his engineers could use, and he wanted it sooner rather than later. Our loss of customer focus cost us significantly as we began to design the system.

We spent time brainstorming different ways of representing the flexible solution that we wanted. We considered ways of creating dynamic schemas for the database, representing forms via XML, creating a form editor for the user, and other creative ideas that never made it into the release. Not only did they not make it into the release, but the time and effort spent on thinking up the ideas and possible solutions took time away from building the system our customer wanted.

There is a critical lesson learned from this experience: Keep your focus on your customers' needs. Build what they want, not what you want.

The ultimate Vision for PSP Tools didn't change. What did change was our plan for the first release of PSP Tools. To tie this realization back to tools, a requirements management tool allows you to quickly change the attributes, such as the release number, for requirements captured in the Vision. Changing the release number to something greater than 1.0 takes it out of the initial release but retains it in the overall Vision.

Because we used Rational RequisitePro, it was easy to change the requirement attributes for the release number and the status of the features. Making these changes helped us maintain a clear and shared understanding of which features we expected to deliver to our customer for the initial release.

Figure 6.11 shows a screen shot of a part of the attribute matrix for the feature requirements specified in our Vision document as we exited the Elaboration phase. Notice the change in the release for the FEA1 requirement. Release 2 at this point represents the next , or some other future, release. The Vision document didn't change. It still reflected our vision of what we wanted to include in PSP Tools. The attributes changed to reflect what we would deliver for this release.

Figure 6.11. A portion of the feature requirement attribute matrix