Adding the Risk Element

Another aspect of managing scope is estimating the "risk" associated with each feature. In this context, we'll consider risk to be the probability that the implementation of a feature will cause an adverse impact on the schedule and/or the budget. Risk gives us a relative measure of the potential impact of including a particular feature within the project baseline. A high-risk feature has the potential to impact the project negatively, even if all other features can be accomplished within the allotted time.

Table 18-2. Prioritized Features List with Effort Estimates

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

The development team establishes risk based on any heuristic it is comfortable with, using the same low-medium-high scale used to assess effort. Table 18-3 shows the revised features list for the example.

Table 18-3. Prioritized Features List with Effort and Risk Estimates

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

Strategies for mitigating risk vary from project to project, and we won't cover that topic here. For the purposes of scope management, it is adequate to simply be aware of the relative risk associated with each feature so that intelligent decisions can be made early in the project. For example, if a feature has a priority of critical and a risk of high , then an effective mitigation strategy is mandatory. If priority is important and the feature hovers around the baseline, the item may be dropped or simply developed "if time is available." There's no harm in the process, so long as no commitment was made to include the item in the release. If the priority of a high -risk item is only useful , consider skipping that feature entirely.