5.2.1 Inputs to Scope Planning

.1 Product description. The product description is discussed in Section 5.1.1.1.

.2 Project charter. The project charter is described in Section 5.1.3.1.

.3 Constraints. Constraints are described in Section 5.1.3.3.

.4 Assumptions. Assumptions are described in Section 4.1.1.5.

5.2.2 Tools and Techniques for Scope Planning

.1 Product analysis. Product analysis involves developing a better understanding of the product of the project. It includes techniques such as product breakdown analysis systems engineering, value engineering, value analysis, function analysis, and quality function deployment.

.2 Benefit/cost analysis. Benefit/cost analysis involves estimating tangible and intangi-ble costs (outlays) and benefits (returns) of various project and product alternatives, and then using financial measures, such as return on investment or payback period, to assess the relative desirability of the identified alternatives.

.3 Alternatives identification. This is a general term for any technique used to gener-ate different approaches to the project. There are a variety of general management techniques often used here, the most common of which are brainstorming and lateral thinking.

.4 Expert judgment. Expert judgment is described in Section 5.1.2.2.

5.2.3 Outputs from Scope Planning

.1 Scope statement. The scope statement provides a documented basis for making future project decisions and for confirming or developing common understanding of project scope among the stakeholders. As the project progresses, the scope statement may need to be revised or refined to reflect approved changes to the scope of the project. The scope statement should include, either directly or by reference to other documents:

   Project justification—the business need that the project was undertaken to address. The project justification provides the basis for evaluating future tradeoffs.

   Project product—a brief summary of the product description (the product description is discussed in Section 5.1.1.1).

   Project deliverables—a list of the summary-level subproducts whose full and satisfactory delivery marks completion of the project. For example, the major deliverables for a software development project might include the working computer code, a user manual, and an interactive tutorial. When known, exclusions should be identified, but anything not explicitly included is implicitly excluded.

   Project objectives—the quantifiable criteria that must be met for the project to be considered successful. Project objectives must include, at least, cost, schedule, and quality measures. Project objectives should have an attribute (e.g., cost), a metric (e.g., U.S. dollars), and an absolute or relative value (e.g., less than 1.5 million). Unquantified objectives (e.g., “customer satisfaction”) entail high risk to successful accomplishment.

.2 Supporting detail .Supporting detail for the scope statement should be documented and organized as needed to facilitate its use by other project management processes. Supporting detail should always include documentation of all identified assumptions and constraints. The amount of additional detail may vary by application area.

.3 Scope management plan This document describes how project scope will be managed and how scope changes will be integrated into the project. It should also in-clude an assessment of the expected stability of the project scope (i.e., how likely is it to change, how frequently, and by how much). The scope management plan should also include a clear description of how scope changes will be identified and classified. (This is particularly difficult—and therefore absolutely essential—when the product characteristics are still being elaborated).
  A scope management plan may be formal or informal, highly detailed or broadly framed, based on the needs of the project. It is a subsidiary component of the project plan (described in Section 4.1.3.1).