Assessing Effort

Prioritization is only one piece of the scope puzzle. After all, if we could do all the work, the prioritization would be unnecessary. If we can't do all the work, we still haven't figured out how much we can do, and therefore, we do not yet know where to draw the baseline for the project.

Table 18-1. Prioritized Features List

Feature	Priority
Feature 1: External relational database support	Critical
Feature 4: Portability to a new OS release	Critical
Feature 6: Import of external data by style	Critical
Feature 3: Ability to clone a project	Important
Feature 2: Multiuser security	Important
Feature 5: New project wizard	Important
Feature 7: Implementation of tool tips	Useful
Feature 8: Integration with a version-manager subsystem	Useful

The next step is to establish the rough level of effort implied by each feature of the proposed baseline. Doing so is tricky since little useful information is available yet on which to estimate the work; we have no detailed requirements or design output on which to base an estimate. The best we can do is to determine a "rough order of magnitude" of the level of effort for each feature.

Estimating effort at this early time is a learned team skill. The engineering team will be naturally reluctant to provide estimates before feasibility and requirements are fully understood , and yet the first cut at scope management must happen before this next level of detail is known.

Let's assume that the product or project manager is the champion for our project and has the following dialogue with the developers for the project. ^[2]

^[2] The team may wish to use "team-weeks" or "team-months" as a gross estimate of the total impact of a feature on the project. This rough heuristic serves as a substitute for a more detailed estimate and is arguably better than the result of this dialogue. Then, using these totals and the total time available for the project, the team can determine where to initially draw the baseline. If it is past the critical-features set, all is well; if not, the project is out of scope, and a new, smaller, project must be defined.

P RODUCT MANAGER:	How difficult is this feature to do ?
D EVELOPMENT TEAM:	We don't know. We don't have any requirements or design yet .
P RODUCT MANAGER:	I respect that, but is it the easiest thing we've ever done ?
D EVELOPMENT TEAM:	No .
P RODUCT MANAGER:	OK, is it the most difficult feature on the list ?
D EVELOPMENT TEAM:	No .
P RODUCT MANAGER:	On a scale of low-medium-high, we'll give it a medium. OK ?
D EVELOPMENT TEAM:	OK. Medium it is .
P RODUCT MANAGER:	OK, on to the next feature .

Why can we not allow for a process that creates detailed requirements and design information for each feature so that we can create more meaningful estimates? Isn't that the professional way to approach the problem? If the schedule provides time for more detailed estimating at this time, by all means do it!

However, we believe that it is crucial to be able to make some quick decisions about the scope of the activity without a more detailed estimate. Why? Because to do otherwise invests resources in what will later be determined to be " wasted inventory," including requirements specifications for features that will not be implemented, design information for those features, test scripts for requirements that will be scope-managed out of the project later, a false determination of the critical path for the project, and so on. We cannot afford to invest any resources in these scrap-producing activities, or we will fail to optimize the resources invested. In other words, scope management will reduce the number of features that will be developed in the initial release, and since resources are extraordinarily scarce , we cannot afford any additional investment in features that are not going to be implemented in the current baseline. Table 18-2 illustrates the addition of effort information to our feature list.