5.3 Define Scope – A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition

5.3 Define Scope

Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-7. Figure 5-8 depicts the data flow diagram of the process.

Since all of the requirements identified in Collect Requirements may not be included in the project, the Define Scope process selects the final project requirements from the requirements documentation delivered during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.

The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary. The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.

5.3.1. Define Scope: Inputs

5.3.1.1 Scope Management Plan

Described in Section 5.1.3.1. The scope management plan is a component of the project management plan that establishes the activities for developing, monitoring, and controlling the project scope.

5.3.1.2 Project Charter

Described in Section 4.1.3.1. The project charter provides the high-level project description and product characteristics. It also contains project approval requirements. If a project charter is not used in the performing organization, then comparable information needs to be acquired or developed, and used as a basis for the detailed project scope statement. Organizations that do not produce a formal project charter will usually perform an informal analysis to identify the content necessary for further scope planning.

5.3.1.3 Requirements Documentation

Described in Section 5.2.3.1. This documentation will be used to select the requirements that will be included in the project.

5.3.1.4 Organizational Process Assets

Described in Section 2.1.4. Organizational process assets can influence how scope is defined. Examples include, but are not limited to:

  • Policies, procedures, and templates for a project scope statement;
  • Project files from previous projects; and
  • Lessons learned from previous phases or projects.

5.3.2. Define Scope: Tools and Techniques

5.3.2.1 Expert Judgment

Expert judgment is often used to analyze the information needed to develop the project scope statement. Such judgment and expertise is applied to any technical detail. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including but not limited to:

  • Other units within the organization;
  • Consultants;
  • Stakeholders, including customers or sponsors;
  • Professional and technical associations;
  • Industry groups; and
  • Subject matter experts.

5.3.2.2 Product Analysis

For projects that have a product as a deliverable, as opposed to a service or result, product analysis can be an effective tool. Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.

5.3.2.3 Alternatives Generation

Alternatives generation is a technique used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management techniques can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc.

5.3.2.4 Facilitated Workshops

Described in Section 5.2.2.3. The participation of key players with a variety of expectations and/or fields of expertise in these intensive working sessions helps to reach a cross-functional and common understanding of the project objectives and its limits.

5.3.3. Define Scope: Outputs

5.3.3.1 Project Scope Statement

The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project's deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to perform more detailed planning, guides the project team's work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project's boundaries.

The degree and level of detail to which the project scope statement defines the work that will be performed and the work that is excluded can help determine how well the project management team can control the overall project scope. The detailed project scope statement, either directly, or by reference to other documents, includes the following:

  • Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation.
  • Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted.
  • Deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as project management reports and documentation. These deliverables may be described at a summary level or in great detail.
  • Project exclusion. Generally identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders' expectations.
  • Constraints. A limiting factor that affects the execution of a project or process. Constraints identified with the project scope statement list and describe the specific internal or external restrictions or limitations associated with the project scope that affect the execution of the project, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization. When a project is performed under an agreement, contractual provisions will generally be constraints. Information on constraints may be listed in the project scope statement or in a separate log.
  • Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration. Also describes the potential impact of those factors if they prove to be false. Project teams frequently identify, document, and validate assumptions as part of their planning process. Information on assumptions may be listed in the project scope statement or in a separate log.

Although the project charter and the project scope statement are sometimes perceived as containing a certain degree of redundancy, they are different in the level of detail contained in each. The project charter contains high-level information, while the project scope statement contains a detailed description of the scope elements. These elements are progressively elaborated throughout the project. Table 5-1 describes some of the key elements for each document.

5.3.3.2 Project Documents Updates

Project documents that may be updated include, but are not limited to:

  • Stakeholder register,
  • Requirements documentation, and
  • Requirements traceability matrix.