5

PROJECT SCOPE MANAGEMENT

Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.

The Project Scope Management processes are:

5.1 Plan Scope Management—The process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled.

5.2 Collect Requirements—The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.

5.3 Define Scope—The process of developing a detailed description of the project and product.

5.4 Create WBS—The process of subdividing project deliverables and project work into smaller, more manageable components.

5.5 Validate Scope—The process of formalizing acceptance of the completed project deliverables.

5.6 Control Scope—The process of monitoring the status of the project and product scope and managing changes to the scope baseline.

Figure 5-1 provides an overview of the Project Scope Management processes. The Project Scope Management processes are presented as discrete processes with defined interfaces while, in practice, they overlap and interact in ways that cannot be completely detailed in the PMBOK® Guide.

KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT

In the project context, the term “scope” can refer to:

• Product scope. The features and functions that characterize a product, service, or result.
• Project scope. The work performed to deliver a product, service, or result with the specified features and functions. The term “project scope” is sometimes viewed as including product scope.

Project life cycles can range along a continuum from predictive approaches at one end to adaptive or agile approaches at the other. In a predictive life cycle, the project deliverables are defined at the beginning of the project and any changes to the scope are progressively managed. In an adaptive or agile life cycle, the deliverables are developed over multiple iterations where a detailed scope is defined and approved for each iteration when it begins.

Projects with adaptive life cycles are intended to respond to high levels of change and require ongoing stakeholder engagement. The overall scope of an adaptive project will be decomposed into a set of requirements and work to be performed, sometimes referred to as a product backlog. At the beginning of an iteration, the team will work to determine how many of the highest-priority items on the backlog list can be delivered within the next iteration. Three processes (Collect Requirements, Define Scope, and Create WBS) are repeated for each iteration. On the contrary, in a predictive project, these processes are performed toward the beginning of the project and updated as necessary, using the integrated change control process.

In an adaptive or agile life cycle, the sponsor and customer representatives should be continuously engaged with the project to provide feedback on deliverables as they are created and to ensure that the product backlog reflects their current needs. Two processes (Validate Scope and Control Scope) are repeated for each iteration. On the contrary, in a predictive project, Validate Scope occurs with each deliverable or phase review and Control Scope is an ongoing process.

In predictive projects, the scope baseline for the project is the approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only through formal change control procedures and is used as a basis for comparison while performing Validate Scope and Control Scope processes as well as other controlling processes. Projects with adaptive life cycles use backlogs (including product requirements and user stories) to reflect their current needs.

Completion of the project scope is measured against the project management plan, while completion of the product scope is measured against the product requirements. The term “requirement” is defined as a condition or capability that is required to be present in a product, service, or result to satisfy an agreement or other formally imposed specification.

Validate Scope is the process of formalizing acceptance of the completed project deliverables. The verified deliverables obtained from the Control Quality process are an input to the Validate Scope process. One of the outputs of Validate Scope is accepted deliverables that are formally signed off and approved by the authorized stakeholder. Therefore, the stakeholder needs to get involved early on during planning (sometimes initiating as well) and to provide inputs about quality of deliverables so that Control Quality can assess the performance and recommend necessary changes.

TRENDS AND EMERGING PRACTICES IN PROJECT SCOPE MANAGEMENT

Requirements have always been a concern in project management and have continued to gain more attention in the profession. As the global environment becomes more complex, organizations are starting to recognize how to use business analysis to their competitive advantage by defining, managing, and controlling requirements activities. Activities of business analysis may start before a project is initiated and a project manager is assigned. According to Requirements Management: A Practice Guide [14], the requirements management process starts with a needs assessment, which may begin in portfolio planning, in program planning, or within a discrete project.

Eliciting, documenting, and managing stakeholder requirements takes place within the Project Scope Management processes. Trends and emerging practices for Project Scope Management include but are not limited to a focus on collaborating with business analysis professionals to:

• Determine problems and identify business needs;
• Identify and recommend viable solutions for meeting those needs;
• Elicit, document, and manage stakeholder requirements in order to meet business and project objectives; and
• Facilitate the successful implementation of the product, service, or end result of the program or project [7].

The process ends with the requirements closure, which transitions the product, service, or result to the recipient in order to measure, monitor, realize, and sustain benefits over time.

The role with responsibility to conduct business analysis should be assigned to resources with sufficient business analysis skills and expertise. If a business analyst is assigned to a project, requirement-related activities are the responsibility of that role. The project manager is responsible for ensuring that requirements-related work is accounted for in the project management plan and that requirements-related activities are performed on time and within budget and deliver value.

The relationship between a project manager and a business analyst should be a collaborative partnership. A project will have a higher likelihood of being successful if project managers and business analysts fully understand each other's roles and responsibilities to successfully achieve project objectives.

TAILORING CONSIDERATIONS

Because each project is unique, the project manager will need to tailor the way Project Scope Management processes are applied. Considerations for tailoring include but are not limited to:

• Knowledge and requirements management. Does the organization have formal or informal knowledge and requirements management systems? What guidelines should the project manager establish for requirements to be reused in the future?
• Validation and control. Does the organization have existing formal or informal validation and control-related policies, procedures, and guidelines?
• Development approach. Does the organization use agile approaches in managing projects? Is the development approach iterative or incremental? Is a predictive approach used? Will a hybrid approach be productive?
• Stability of requirements. Are there areas of the project with unstable requirements? Do unstable requirements necessitate the use of lean, agile, or other adaptive techniques until they are stable and well defined?
• Governance. Does the organization have formal or informal audit and governance policies, procedures, and guidelines?

CONSIDERATIONS FOR AGILE/ADAPTIVE ENVIRONMENTS

In projects with evolving requirements, high risk, or significant uncertainty, the scope is often not understood at the beginning of the project or it evolves during the project. Agile methods deliberately spend less time trying to define and agree on scope in the early stage of the project and spend more time establishing the process for its ongoing discovery and refinement. Many environments with emerging requirements find that there is often a gap between the real business requirements and the business requirements that were originally stated. Therefore, agile methods purposefully build and review prototypes and release versions in order to refine the requirements. As a result, scope is defined and redefined throughout the project. In agile approaches, the requirements constitute the backlog.

5.1 PLAN SCOPE MANAGEMENT

Plan Scope Management is the process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled. The key benefit of this process is that it provides guidance and direction on how scope will be managed throughout the project. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-2. Figure 5-3 depicts the data flow diagram of the process.

The scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The development of the scope management plan and the detailing of the project scope begin with the analysis of information contained in the project charter (Section 4.1.3.1), the latest approved subsidiary plans of the project management plan (Section 4.2.3.1), historical information contained in the organizational process assets (Section 2.3), and any other relevant enterprise environmental factors (Section 2.2).

5.1.1 PLAN SCOPE MANAGEMENT: INPUTS

5.1.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter documents the project purpose, high-level project description, assumptions, constraints, and high-level requirements that the project is intended to satisfy.

5.1.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Quality management plan. Described in Section 8.1.3.1. The way the project and product scope will be managed can be influenced by how the organization's quality policy, methodologies, and standards are implemented on the project.
• Project life cycle description. The project life cycle determines the series of phases that a project passes through from its inception to the end of the project.
• Development approach. The development approach defines whether waterfall, iterative, adaptive, agile, or a hybrid development approach will be used.

5.1.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Plan Scope Management process include but are not limited to:

• Organization's culture,
• Infrastructure,
• Personnel administration, and
• Marketplace conditions.

5.1.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Plan Scope Management process include but are not limited to:

• Policies and procedures, and
• Historical information and lessons learned repositories.

5.1.2 PLAN SCOPE MANAGEMENT: TOOLS AND TECHNIQUES

5.1.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1 Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Previous similar projects, and
• Information in the industry, discipline, and application area.

5.1.2.2 DATA ANALYSIS

A data analysis technique that can be used for this process includes but is not limited to alternatives analysis. Various ways of collecting requirements, elaborating the project and product scope, creating the product, validating the scope, and controlling the scope are evaluated.

5.1.2.3 MEETINGS

Project teams may attend project meetings to develop the scope management plan. Attendees may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for any of the scope management processes, and others as needed.

5.1.3 PLAN SCOPE MANAGEMENT: OUTPUTS

5.1.3.1 SCOPE MANAGEMENT PLAN

The scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The components of a scope management plan include:

• Process for preparing a project scope statement;
• Process that enables the creation of the WBS from the detailed project scope statement;
• Process that establishes how the scope baseline will be approved and maintained; and
• Process that specifies how formal acceptance of the completed project deliverables will be obtained.

The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.

5.1.3.2 REQUIREMENTS MANAGEMENT PLAN

The requirements management plan is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed. According to Business Analysis for Practitioners: A Practice Guide [7], some organizations refer to it as a business analysis plan. Components of the requirements management plan can include but are not limited to:

• How requirements activities will be planned, tracked, and reported;
• Configuration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes;
• Requirements prioritization process;
• Metrics that will be used and the rationale for using them; and
• Traceability structure that reflects the requirement attributes captured on the traceability matrix.

5.2 COLLECT REQUIREMENTS

Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet objectives. The key benefit of this process is that it provides the basis for defining the product scope and project scope. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-4. Figure 5-5 depicts the data flow diagram of the process.

The PMBOK® Guide does not specifically address product requirements since those are industry specific. Note that Business Analysis for Practitioners: A Practice Guide [7] provides more in-depth information about product requirements. The project's success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into project and product requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project. Requirements include conditions or capabilities that are required to be present in a product, service, or result to satisfy an agreement or other formally imposed specification. Requirements include the quantified and documented needs and expectations of the sponsor, customer, and other stakeholders. These requirements need to be elicited, analyzed, and recorded in enough detail to be included in the scope baseline and to be measured once project execution begins. Requirements become the foundation of the WBS. Cost, schedule, quality planning, and procurement are all based on these requirements.

5.2.1 COLLECT REQUIREMENTS: INPUTS

5.2.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter documents the high-level project description and high-level requirements that will be used to develop detailed requirements.

5.2.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Scope management plan. Described in Section 5.1.3.1. The scope management plan contains information on how the project scope will be defined and developed.
• Requirements management plan. Described in Section 5.1.3.2. The requirements management plan has information on how project requirements will be collected, analyzed, and documented.
• Stakeholder engagement plan. Described in Section 13.2.3.1. The stakeholder engagement plan is used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities.

5.2.1.3 PROJECT DOCUMENTS

Examples of project documents that can be considered as inputs for this process include but are not limited to:

• Assumption Log. Described in Section 4.1.3.2. The assumption log identified assumptions about the product, project, environment, stakeholders, and other factors that can influence requirements.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is used to provide information on effective requirements collection techniques, especially for projects that are using an iterative or adaptive product development methodology.
• Stakeholder Register. Described in Section 13.1.3.1. The stakeholder register is used to identify stakeholders who can provide information on the requirements. It also captures requirements and expectations that stakeholders have for the project.

5.2.1.4 BUSINESS DOCUMENTS

Described in Section 1.2.6. A business document that can influence the Collect Requirements process is the business case, which can describe required, desired, and optional criteria for meeting the business needs.

5.2.1.5 AGREEMENTS

Described in Section 12.2.3.2. Agreements can contain project and product requirements.

5.2.1.6 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Collect Requirements process include but are not limited to:

• Organization's culture,
• Infrastructure,
• Personnel administration, and
• Marketplace conditions.

5.2.1.7 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Collect Requirements process include but are not limited to:

• Policies and procedures, and
• Historical information and lessons learned repository with information from previous projects.

5.2.2 COLLECT REQUIREMENTS: TOOLS AND TECHNIQUES

5.2.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Business analysis,
• Requirements elicitation,
• Requirements analysis,
• Requirements documentation,
• Project requirements in previous similar projects,
• Diagramming techniques,
• Facilitation, and
• Conflict management.

5.2.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to:

• Brainstorming. Described in Section 4.1.2.2. Brainstorming is a technique used to generate and collect multiple ideas related to project and product requirements.
• Interviews. An interview is a formal or informal approach to elicit information from stakeholders by talking to them directly. It is typically performed by asking prepared and spontaneous questions and recording the responses. Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced project participants, sponsors, other executives, and subject matter experts can aid in identifying and defining the features and functions of the desired product deliverables. Interviews are also useful for obtaining confidential information.
• Focus groups. Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion designed to be more conversational than a one-on-one interview.
• Questionnaires and surveys. Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large number of respondents. Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis could be appropriate.
• Benchmarking. Described in Section 8.1.2.2. Benchmarking involves comparing actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.

5.2.2.3 DATA ANALYSIS

Described in Section 4.5.2.2. Data analysis techniques that can be used for this process include but are not limited to document analysis. Document analysis consists of reviewing and assessing any relevant documented information. In this process, document analysis is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. There is a wide range of documents that may be analyzed to help elicit relevant requirements. Examples of documents that may be analyzed include but are not limited to:

• Agreements;
• Business plans;
• Business process or interface documentation;
• Business rules repositories;
• Current process flows;
• Marketing literature;
• Problem/issue logs;
• Policies and procedures;
• Regulatory documentation such as laws, codes, or ordinances, etc.;
• Requests for proposal; and
• Use cases.

5.2.2.4 DECISION MAKING

Decision-making techniques that can be used in the Collect Requirements process include but are not limited to:

• Voting. Voting is a collective decision-making technique and an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements. Examples of voting techniques include:

• Unanimity. A decision that is reached whereby everyone agrees on a single course of action.
• Majority. A decision that is reached with support obtained from more than 50% of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
• Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.

• Autocratic decision making. In this method, one individual takes responsibility for making the decision for the group.
• Multicriteria decision analysis. A technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.

5.2.2.5 DATA REPRESENTATION

Data representation techniques that can be used for this process include but are not limited to:

• Affinity diagrams. Affinity diagrams allow large numbers of ideas to be classified into groups for review and analysis.
• Mind mapping. Mind mapping consolidates ideas created through individual brainstorming sessions into a single map to reflect commonality and differences in understanding and to generate new ideas.

5.2.2.6 INTERPERSONAL AND TEAM SKILLS

Described in Section 4.1.2.3. The interpersonal and team skills that can be used in this process include but are not limited to:

• Nominal group technique. The nominal group technique enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. The nominal group technique is a structured form of brainstorming consisting of four steps:

• A question or problem is posed to the group. Each person silently generates and writes down their ideas.
• The moderator writes down the ideas on a flip chart until all ideas are recorded.
• Each recorded idea is discussed until all group members have a clear understanding.
• Individuals vote privately to prioritize the ideas, usually using a scale of 1 – 5, with 1 being the lowest and 5 being the highest. Voting may take place in many rounds to reduce and focus in on ideas. After each round, the votes are tallied and the highest scoring ideas are selected.

• Observation/conversation. Observation and conversation provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people who use the product have difficulty or are reluctant to articulate their requirements. Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a business expert performing a job. It can also be done by a “participant observer” who actually performs a process or procedure to experience how it is done to uncover hidden requirements.
• Facilitation. Described in Section 4.1.2.3. Facilitation is used with focused sessions that bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.

Facilitation skills are used in the following situations, but are not limited to:

• Joint application design/development (JAD). JAD sessions are used in the software development industry. These facilitated sessions focus on bringing business subject matter experts and the development team together to gather requirements and improve the software development process.
• Quality function deployment (QFD). In the manufacturing industry, QFD is another facilitation technique that helps determine critical characteristics for new product development. QFD starts by collecting customer needs, also known as voice of the customer (VOC). These needs are then objectively sorted and prioritized, and goals are set for achieving them.
• User stories. User stories, which are short, textual descriptions of required functionality, are often developed during a requirements workshop. User stories describe the stakeholder role, who benefits from the feature (role), what the stakeholder needs to accomplish (goal), and the benefit to the stakeholder (motivation).

5.2.2.7 CONTEXT DIAGRAM

The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it (see Figure 5-6). Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.

5.2.2.8 PROTOTYPES

Prototyping is a method of obtaining early feedback on requirements by providing a model of the expected product before actually building it. Examples of prototypes are small-scale products, computer generated 2D and 3D models, mock-ups, or simulations. Prototypes allow stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements. Prototypes support the concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision. When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase.

Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations. Storyboards are used on a variety of projects in a variety of industries, such as film, advertising, instructional design, and on agile and other software development projects. In software development, storyboards use mock-ups to show navigation paths through web pages, screens, or other user interfaces.

5.2.3 COLLECT REQUIREMENTS: OUTPUTS

5.2.3.1 REQUIREMENTS DOCUMENTATION

Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more information about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of the requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.

Many organizations categorize requirements into different types, such as business and technical solutions, the former referring to stakeholder needs and the latter as to how those needs will be implemented. Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated. These classifications include:

• Business requirements. These describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.
• Stakeholder requirements. These describe needs of a stakeholder or stakeholder group.
• Solution requirements. These describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:

• Functional requirements. Functional requirements describe the behaviors of the product. Examples include actions, processes, data, and interactions that the product should execute.
• Nonfunctional requirements. Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.

• Transition and readiness requirements. These describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the desired future state.
• Project requirements. These describe the actions, processes, or other conditions the project needs to meet. Examples include milestone dates, contractual obligations, constraints, etc.
• Quality requirements. These capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements. Examples include tests, certifications, validations, etc.

5.2.3.2 REQUIREMENTS TRACEABILITY MATRIX

The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.

Tracing requirements includes but is not limited to:

• Business needs, opportunities, goals, and objectives;
• Project objectives;
• Project scope and WBS deliverables;
• Product design;
• Product development;
• Test strategy and test scenarios; and
• High-level requirements to more detailed requirements.

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved, assigned, completed), and status date. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria. Figure 5-7 provides an example of a requirements traceability matrix with its associated attributes.

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 and acceptance criteria. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-8. Figure 5-9 depicts the data flow diagram of the process.

Since all 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 developed 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 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 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter provides the high-level project description, product characteristics, and approval requirements.

5.3.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. A project management plan component includes but is not limited to the scope management plan as described in Section 5.1.3.1, which documents how the project scope will be defined, validated, and controlled.

5.3.1.3 PROJECT DOCUMENTS

Examples of project documents that can be considered as inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log identifies assumptions and constraints about the product, project, environment, stakeholders, and other factors that can influence the project and product scope.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation identifies requirements that will be incorporated into the scope.
• Risk register. Described in Section 11.2.3.1. The risk register contains response strategies that may affect the project scope, such as reducing or changing project and product scope to avoid or mitigate a risk.

5.3.1.4 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Define Scope process include but are not limited to:

• Organization's culture,
• Infrastructure,
• Personnel administration, and
• Marketplace conditions.

5.3.1.5 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Define Scope process 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

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with knowledge of or experience with similar projects.

5.3.2.2 DATA ANALYSIS

An example of a data analysis technique that can be used in this process includes but is not limited to alternatives analysis. Alternatives analysis can be used to evaluate ways to meet the requirements and the objectives identified in the charter.

5.3.2.3 DECISION MAKING

Described in Section 5.1.2.2. A decision-making technique that can be used in this process includes but is not limited to multicriteria decision analysis. Described in Section 8.1.2.4, multicriteria decision analysis is a technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as requirements, schedule, budget, and resources, in order to refine the project and product scope for the project.

5.3.2.4 INTERPERSONAL AND TEAM SKILLS

Described in Section 4.1.2.3. An example of an interpersonal and team skills technique is facilitation. Facilitation is used in workshops and working sessions with key stakeholders who have a variety of expectations or fields of expertise. The goal is to reach a cross-functional and common understanding of the project deliverables and project and product boundaries.

5.3.2.5 PRODUCT ANALYSIS

Product analysis can be used to define products and services. It includes asking questions about a product or service and forming answers to describe the use, characteristics, and other relevant aspects of what is going to be delivered.

Each application area has one or more generally accepted methods for translating high-level product or service descriptions into meaningful deliverables. Requirements are captured at a high level and decomposed to the level of detail needed to design the final product. Examples of product analysis techniques include but are not limited to:

• Product breakdown,
• Requirements analysis,
• Systems analysis,
• Systems engineering,
• Value analysis, and
• Value engineering.

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 the project's deliverables in detail. 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.
• Deliverables. 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.
• Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted.
• Project exclusions. Identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps manage stakeholders’ expectations and can reduce scope creep.

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 components. These components 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 as a result of carrying out this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log is updated with additional assumptions or constraints that were identified during this process.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation may be updated with additional or changed requirements.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix may be updated to reflect updates in requirement documentation.
• Stakeholder register. Described in Section 13.1.3.1. Where additional information on existing or new stakeholders is gathered as a result of this process, it is recorded in the stakeholder register.

5.4 CREATE WBS

Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. The key benefit of this process is that it provides a framework of what has to be delivered. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-10. Figure 5-11 depicts the data flow diagram of the process.

The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement.

The planned work is contained within the lowest level of WBS components, which are called work packages. A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled. In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself.

5.4.1 CREATE WBS: INPUTS

5.4.1.1 PROJECT MANAGEMENT PLAN

A project management plan component includes but is not limited to the scope management plan. Described in Section 5.1.3.1, the scope management plan documents how the WBS will be created from the project scope statement.

5.4.1.2 PROJECT DOCUMENTS

Examples of project documents that can be considered as inputs for this process include but are not limited to:

• Project scope statement. Described in Section 5.3.3.1. The project scope statement describes the work that will be performed and the work that is excluded.
• Requirements documentation. Described in Section 5.2.3.1. Detailed requirements describe how individual requirements meet the business need for the project.

5.4.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Create WBS process include but are not limited to industry-specific WBS standards that are relevant to the nature of the project. These industry-specific standards may serve as external reference sources for creating the WBS.

5.4.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Create WBS process include but are not limited to:

• Policies, procedures, and templates for the WBS;
• Project files from previous projects; and
• Lessons learned from previous projects.

5.4.2 CREATE WBS: TOOLS AND TECHNIQUES

5.4.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with knowledge of or experience with similar projects.

5.4.2.2 DECOMPOSITION

Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project. Decomposition of the total project work into work packages generally involves the following activities:

• Identifying and analyzing the deliverables and related work,
• Structuring and organizing the WBS,
• Decomposing the upper WBS levels into lower-level detailed components,
• Developing and assigning identification codes to the WBS components, and
• Verifying that the degree of decomposition of the deliverables is appropriate.

A portion of a WBS with some branches of the WBS decomposed down through the work package level is shown in Figure 5-12.

A WBS structure may be created through various approaches. Some of the popular methods include the top-down approach, the use of organization-specific guidelines, and the use of WBS templates. A bottom-up approach can be used to group subcomponents. The WBS structure can be represented in a number of forms, such as:

• Using phases of the project life cycle as the second level of decomposition, with the product and project deliverables inserted at the third level, as shown in Figure 5-13;
• Using major deliverables as the second level of decomposition, as shown in Figure 5-14; and
• Incorporating subcomponents that may be developed by organizations outside the project team, such as contracted work. The seller then develops the supporting contract WBS as part of the contracted work.

Decomposition of the upper-level WBS components requires subdividing the work for each of the deliverables or subcomponents into its most fundamental components, where the WBS components represent verifiable products, services, or results. If an agile approach is used, epics can be decomposed into user stories. The WBS may be structured as an outline, an organizational chart, or other method that identifies a hierarchical breakdown. Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher-level deliverables. Different deliverables can have different levels of decomposition. To arrive at a work package, the work for some deliverables needs to be decomposed only to the next level, while others need additional levels of decomposition. As the work is decomposed to greater levels of detail, the ability to plan, manage, and control the work is enhanced. However, excessive decomposition can lead to nonproductive management effort, inefficient use of resources, decreased efficiency in performing the work, and difficulty aggregating data over different levels of the WBS.

Decomposition may not be possible for a deliverable or subcomponent that will be accomplished far into the future. The project management team usually waits until the deliverable or subcomponent is agreed on, so the details of the WBS can be developed. This technique is sometimes referred to as rolling wave planning.

The WBS represents all product and project work, including the project management work. The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed. This is sometimes called the 100 percent rule.

For specific information regarding the WBS, refer to the Practice Standard for Work Breakdown Structures – Second Edition [15]. This standard contains industry-specific examples of WBS templates that can be tailored to specific projects in a particular application area.

5.4.3 CREATE WBS: OUTPUTS

5.4.3.1 SCOPE BASELINE

The scope baseline is the approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan. Components of the scope baseline include:

• Project scope statement. The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints (Section 5.3.3.1).
• WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work.
• Work package. The lowest level of the WBS is a work package with a unique identifier. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of accounts. Each work package is part of a control account. A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, though each work package is associated with a single control account.
• Planning package. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.
• WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage. Information in the WBS dictionary may include but is not limited to:

• Code of account identifier,
• Description of work,
• Assumptions and constraints,
• Responsible organization,
• Schedule milestones,
• Associated schedule activities,
• Resources required,
• Cost estimates,
• Quality requirements,
• Acceptance criteria,
• Technical references, and
• Agreement information.

5.4.3.2 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log is updated with additional assumptions or constraints that were identified during the Create WBS process.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation may be updated to include approved changes resulting from the Create WBS process.

5.5 VALIDATE SCOPE

Validate Scope is the process of formalizing acceptance of the completed project deliverables. The key benefit of this process is that it brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable. This process is performed periodically throughout the project as needed. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-15. Figure 5-16 depicts the data flow diagram of the process.

The verified deliverables obtained from the Control Quality process are reviewed with the customer or sponsor to ensure they are completed satisfactorily and have received formal acceptance of the deliverables by the customer or sponsor. In this process, the outputs obtained as a result of the Planning processes in the Project Scope Management Knowledge Area, such as the requirements documentation or the scope baseline, as well as the work performance data obtained from the Execution processes in other Knowledge Areas, are the basis for performing the validation and for final acceptance.

The Validate Scope process differs from the Control Quality process in that the former is primarily concerned with acceptance of the deliverables, while the latter is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. Control Quality is generally performed before Validate Scope, although the two processes may be performed in parallel.

5.5.1 VALIDATE SCOPE: INPUTS

5.5.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Scope management plan. Described in Section 5.1.3.1. The project management plan specifies how formal acceptance of the completed project deliverables will be obtained.
• Requirements management plan. Described in Section 5.1.3.2. The requirements management plan describes how the project requirements are validated.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline is compared to actual results to determine if a change, corrective action, or preventive action is necessary.

5.5.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register: Described in Section 4.4.3.1. Lessons learned earlier in the project can be applied to later phases in the project to improve the efficiency and effectiveness of validating deliverables.
• Quality reports. Described in Section 8.2.3.1. The information presented in the quality report may include all quality assurance issues managed or escalated by the team, recommendations for improvement, and the summary of findings from the Control Quality process. This information is reviewed prior to product acceptance.
• Requirements documentation. Described in Section 5.2.3.1. Requirements are compared to the actual results to determine if a change, corrective action, or preventive action is necessary.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix contains information about requirements, including how they will be validated.

5.5.1.3 VERIFIED DELIVERABLES

Verified deliverables are project deliverables that are completed and checked for correctness through the Control Quality process.

5.5.1.4 WORK PERFORMANCE DATA

Described in Section 4.3.3.2. Work performance data can include the degree of compliance with requirements, number of nonconformities, severity of the nonconformities, or the number of validation cycles performed in a period of time.

5.5.2 VALIDATE SCOPE: TOOLS AND TECHNIQUES

5.5.2.1 INSPECTION

Described in Section 8.3.2.3. Inspection includes activities such as measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, and walkthroughs. In some application areas, these different terms have unique and specific meanings.

5.5.2.2 DECISION MAKING

Described in Section 5.2.2.4. An example of decision making that may be used in this process includes but is not limited to voting. Voting is used to reach a conclusion when the validation is performed by the project team and other stakeholders.

5.5.3 VALIDATE SCOPE: OUTPUTS

5.5.3.1 ACCEPTED DELIVERABLES

Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor. Formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project's deliverables is forwarded to the Close Project or Phase process (Section 4.7).

5.5.3.2 WORK PERFORMANCE INFORMATION

Work performance information includes information about project progress, such as which deliverables have been accepted and which have not been accepted and the reasons why. This information is documented as described in Section 10.3.3.1 and communicated to stakeholders.

5.5.3.3 CHANGE REQUESTS

The completed deliverables that have not been formally accepted are documented, along with the reasons for non-acceptance of those deliverables. Those deliverables may require a change request for defect repair. The change requests (described in Section 4.3.3.4) are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6).

5.5.3.4 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with information on challenges encountered and how they could have been avoided as well as approaches that worked well for validating deliverables.
• Requirements documentation. Described in Section 5.2.3.1. The requirements documentation may be updated with the actual results of validation activity. Of particular interest is when the actual results are better than the requirement or where a requirement was waived.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix is updated with the results of the validation, including the method used and the outcome.

5.6 CONTROL SCOPE

Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. The key benefit of this process is that the scope baseline is maintained throughout the project. This process is performed throughout the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-17. Figure 5-18 depicts the data flow diagram of the process.

Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process (see Section 4.6). Control Scope is also used to manage the actual changes when they occur and is integrated with the other control processes. The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources is referred to as scope creep. Change is inevitable; therefore, some type of change control process is mandatory for every project.

5.6.1 CONTROL SCOPE: INPUTS

5.6.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Scope management plan. Described in Section 5.1.3.1. The scope management plan documents how the project and product scope will be controlled.
• Requirements management plan. Described in Section 5.1.3.2. The requirements management plan describes how the project requirements will be managed.
• Change management plan. Described in Section 4.2.3.1. The change management plan defines the process for managing change on the project.
• Configuration management plan. Described in Section 4.2.3.1. The configuration management plan defines those items that are configurable, those items that require formal change control, and the process for controlling changes to such items.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline is compared to actual results to determine if a change, corrective action, or preventive action is necessary.
• Performance measurement baseline. Described in Section 4.2.3.1. When using earned value analysis, the performance measurement baseline is compared to actual results to determine if a change, corrective action, or preventive action is necessary.

5.6.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. Lessons learned earlier in the project can be applied to later phases in the project to improve scope control.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation is used to detect any deviation in the agreed-upon scope for the project or product.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix helps to detect the impact of any change or deviation from the scope baseline on the project objectives. It may also provide status of requirements being controlled.

5.6.1.3 WORK PERFORMANCE DATA

Work performance data can include the number of change requests received, the number of requests accepted, and the number of deliverables verified, validated, and completed.

5.6.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Control Scope process include but are not limited to:

• Existing formal and informal scope, control-related policies, procedures, guidelines; and
• Monitoring and reporting methods and templates to be used.

5.6.2 CONTROL SCOPE: TOOLS AND TECHNIQUES

5.6.2.1 DATA ANALYSIS

Data analysis techniques that can be used in the Control Scope process include but are not limited to:

• Variance analysis. Described in Section 4.5.2.2. Variance analysis is used to compare the baseline to the actual results and determine if the variance is within the threshold amount or if corrective or preventive action is appropriate.
• Trend analysis. Described in Section 4.5.2.2. Trend analysis examines project performance over time to determine if performance is improving or deteriorating.

Important aspects of project scope control include determining the cause and degree of variance relative to the scope baseline (Section 5.4.3.1) and deciding whether corrective or preventive action is required.

5.6.3 CONTROL SCOPE: OUTPUTS

5.6.3.1 WORK PERFORMANCE INFORMATION

Work performance information produced includes correlated and contextualized information on how the project and product scope are performing compared to the scope baseline. It can include the categories of the changes received, the identified scope variances and their causes, how they impact schedule or cost, and the forecast of the future scope performance.

5.6.3.2 CHANGE REQUESTS

Described in Section 4.3.3.4. Analysis of project performance may result in a change request to the scope and schedule baselines or other components of the project management plan. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6).

5.6.3.3 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Components that may require a change request for the project management plan include but are not limited to:

• Scope management plan. Described in Section 5.1.3.1. The scope management plan may be updated to reflect a change in how the scope is managed.
• Scope baseline. Described in Section 5.4.3.1. Changes to the scope baseline are incorporated in response to approved changes in scope, scope statement, the WBS, or the WBS dictionary. In some cases, scope variances can be so severe that a revised scope baseline is needed to provide a realistic basis for performance measurement.
• Schedule baseline. Described in Section 6.5.3.1. Changes to the schedule baseline are incorporated in response to approved changes in scope, resources, or schedule estimates. In some cases, schedule variances can be so severe that a revised schedule baseline is needed to provide a realistic basis for performance measurement.
• Cost baseline. Described in Section 7.3.3.1. Changes to the cost baseline are incorporated in response to approved changes in scope, resources, or cost estimates. In some cases, cost variances can be so severe that a revised cost baseline is needed to provide a realistic basis for performance measurement.
• Performance measurement baseline. Described in Section 4.2.3.1. Changes to the performance measurement baseline are incorporated in response to approved changes in scope, schedule performance, or cost estimates. In some cases, the performance variances can be so severe that a change request is put forth to revise the performance measurement baseline to provide a realistic basis for performance measurement.

5.6.3.4 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register can be updated with techniques that are efficient and effective in controlling scope, including causes of variances and corrective actions chosen.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation may be updated with additional or changed requirements.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix may be updated to reflect updates in requirement documentation.