We have made substantial progress. We now have a prioritized features set with associated relative effort and risk. Note that there is often little correlation between priority and effort or between priority and risk. Indeed, many critical items require low effort; many items that are only useful are very difficult. This can help the team further prioritize the features. For example, a feature that is critical priority, medium effort, and low risk may be a candidate for immediate resourcing. Between these extremes, we can determine where to apply our fixed resources so as to maximize the benefit to the customer. Table 18-4 provides a few guidelines for prioritizing the development of critical features based on these attributes.
Table 18-4. Scope Prioritization Techniques
A Reasonable First Estimate
Better yet, if the team uses even a rough, labor-based estimate, it can determine the baseline by simply adding the labor estimates until the time limit has been met; the team will have established the project baseline. Often, however, the team will not have even this data available and yet must make a first cut at project scope. In this case, we still do not know where to draw the baseline, but if it is the team's gut feel that scope is greater than 100 percent, the list will likely have to be cut.
The next step is the trickiest. If we assume, for example, that the features add up to 200 percent scope, the baseline must be chopped in half or more. How do we go about this process?
The first consideration is whether we can do only the critical items on the list. Ask the project manager, "If all else fails, can we be certain of achieving at least the critical items by the deadline?" After all, if we applied the prioritization scheme well, only one-third or so of the items on the list will be critical to the release. Unless some of the critical features represent a highly disproportionate level of effort, the answer should be yes, even if we have 200 percent scope. If the answer is yes, and in our experience it is almost always yes, even at this first early cut, we have the beginnings of a plan. If the answer is no, the project is way out of scope (300 percent to 400 percent or more), and a smaller-scope project must be defined and the prioritization process repeated.
Since our estimating process was crude at best, we cannot say for sure how many items beyond the critical ones can be achieved. A further estimating effort, based on more detailed requirements and appraisal of technical feasibility, can be used to refine the baseline further. (Also, this is the time to do the detailed project plan to validate the assumptions that have been made.)
In our experience, however, it is sufficient in many real-world projects to draw the baseline at the critical requirements (perhaps including one or two important items), leaving the development team to make further decisions about the inclusion of other important items, based on project progress. No, it isn't scientific. But yes, it does work.
If expectations are properly set and managed, anything that can be accomplished beyond the baseline will be a bonus. Table 18-5 applies this simple heuristic to the baseline for our sample project.
Features below the baseline are now future features and will be considered in later releases. Such features may be later promoted to a higher priority, based on what is accomplished in the near- term release and based on future customer input.
Table 18-5. Final Prioritized Features List
Of course, the features are not always independent. In many cases, one of the features below the baseline is integral to one of the features above the baseline or can be implemented more readily as a result of the accomplishment of another feature. Or perhaps the project team is good or lucky and gets ahead of schedule (now a conceivable notion!) or finds a class library that makes a below-the-baseline feature easy to implement. In these cases, the team should be empowered to reprioritize and reset the baseline so that feature can be included in the release, subject to proper communication processes, of course.
In this fashion, the team should be able to create a project plan, at least at the first order of approximation . However, in all likelihood , many of the desired features did not make the first cut, and there will be expectations to be managed, both inside and outside the company. We'll cover that topic in Chapter 19. But first let's revisit the case study and see what the team came up with for the scope of the HOLIS v1.0 release.