The project scope management process consists of six processes: planning scope management, gathering requirements, defining the scope, creating the WBS, validating the scope, and controlling the scope, each of which is highlighted below.
Planning scope management is the process of creating a scope management plan to document how the project scope and product scope will be defined, validated, and controlled. This process addresses the need to provide a guiding document for how scope will be managed throughout the duration of the project.
In a project environment, "scope" has two meanings:
(1) Product scope: the features and functions of a product, service, or outcome.
(2) Project scope: the work that must be done to deliver the product, service, or outcome.
1-2-1 Inputs
(1) Project Charter
Documents the project purpose, project overview, assumptions, constraints, and high-level requirements that the project intends to fulfill.
(2) Project Management Plan
? Quality Management Plan : The way in which the organization's quality policies, methods, and standards are implemented in the project affects the way in which the project and product scope is managed.
Project Lifecycle Description: The project lifecycle defines the series of phases that a project goes through from inception to completion.
Development methodology: The development methodology defines whether the project is waterfall, iterative, adaptive, agile, or a hybrid development methodology.
(3) Business Environment Factors
Organizational culture; infrastructure; personnel management systems; and market conditions.
(4) Organizational process assets
Policies and procedures; historical information and lessons learned knowledge base.
1-2-2 Tools and Techniques
(1) Expert Judgment
Topics on which judgment needs to be given: previous similar projects; information on specific industries, disciplines, and application areas.
(2) Data Analysis
Various methods used to assess the need for gathering requirements, detailing the scope of the project and product, creating the product, confirming the scope and controlling the scope. For example, the commonly used data analysis techniques alternatives analysis.
(3) Meetings
Attendees may include the project manager, project sponsor, selected project team members, selected interested parties, scope management process owners, and others as necessary.
1-2-3 Outputs
(1) Scope Management Plan
The scope management plan is a component of the project management plan that describes how the project scope will be defined, developed, monitored, controlled, and validated.
Elements of a scope management plan include: developing a project scope statement; creating a WBS based on the detailed project scope statement; determining how the scope baseline will be approved and maintained; and formally accepting the completed project deliverables.
(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.
The main elements of a requirements management plan include: how to track, plan, and report on various requirements activities; how configuration management initiates changes, analyzes the impact, traces, tracks and reports on them, and changes approval authority; requirements prioritization; measurement metrics and the rationale for applying these metrics; and a tracking structure that reflects which requirements attributes will be included in the tracking matrix.
Requirements gathering is the process of identifying, documenting, and managing the needs and requirements of interested parties to achieve objectives.
It addresses the question of what is needed.
2-2-1 Inputs
(1) Project Charter
The focus is on the project overview documented inside the project charter and the high-level requirements that will be used to develop detailed requirements.
(2) Project Management Plan
Scope Management Plan: The scope management plan contains information on how the project scope will be defined and developed.
Requirements Management Plan : The Requirements Management Plan contains information on how to collect, analyze, and document project requirements.
Stakeholder Engagement Plan: The Stakeholder Engagement Plan provides an understanding of the communication needs and level of involvement of stakeholders in order to assess and adapt the level of stakeholder involvement in requirements activities.
(3) Project Documentation
Assumptions Log: Assumptions about the product, project, environment, stakeholders, and other factors that will affect demand.
Lessons Learned Register: An effective requirements gathering technique, especially for projects using an iterative or adaptive product development approach.
Stakeholder registry: Used to understand which stakeholders can provide requirements information and to document their needs and expectations for the project.
(4) Business Documents
The business document that influences the requirements gathering process is the business case, which describes the necessary, desired, and optional criteria that should be met in order to fulfill the business need.
(5) Agreements
Agreements contain the project and product requirements sections.
(6) Business Environment Factors
Business environment factors that can influence the requirements gathering process include: organizational culture, infrastructure, personnel management systems, and market conditions.
(7) Organizational process assets
Organizational process assets that can influence the requirements gathering process include: policies and procedures; and a knowledge base of historical information and lessons learned that includes information from previous projects.
2-2-2 Tools and Techniques
(1) Expert Judgment
Expert opinion is given on: business analysis, requirements acquisition, requirements analysis, requirements documentation, project requirements from previous similar projects, diagramming techniques, guidance, and conflict management.
(2) Data Collection
Brainstorming: A creative technique used to generate and collect requirements for projects and products.
Interviews: Direct conversations with interested parties to identify and define the features and functionality of the desired product deliverables, possibly even obtaining confidential information.
Focus Groups: Bringing together predefined stakeholders and subject matter experts for the purpose of understanding their expectations and attitudes toward the product, service, or outcome being discussed.
Questionnaire: The questionnaire method is ideal for situations where the audience is diverse, the survey needs to be completed quickly, the respondents are geographically dispersed, and it is suitable for statistical analysis.
Benchmarking: Comparing actual or planned products, processes and practices with those of other organizations, either internal or external.
(3) Data Analysis
The data analysis used for this process is primarily document analysis, which involves reviewing and evaluating any relevant documented information to identify and capture requirements.
(4) Decision Making
Decision making techniques applicable to the cell phone requirements process include:
Voting: This technique is used to generate, categorize, and rank product requirements, with results ranging from unanimous agreement (everyone), to majority agreement (more than 50%), and to relative majority agreement
Dictatorial Decision Making: A single person is responsible for making a decision for the entire group.
Multi-Criteria Decision Analysis: A systematic approach to analyzing and establishing criteria such as risk level, uncertainty, and return on value to evaluate and rank ideas using a decision matrix.
(5) Data Representation
Affinity Diagrams: Group a large number of technologies for further review and analysis.
Mind maps: A presentation of brainstorming results to reflect ****ness and differences between ideas and to stimulate new ideas.
(6) Interpersonal and Team Skills
Nominal Group Technique: A structured form of brainstorming with four steps: a question is posed to the group and everyone writes an idea; the facilitator takes notes on everyone's ideas; the group discusses the ideas to reach a clear understanding of the ****; and a private vote is taken to prioritize the ideas, with the highest scoring group winning.
Observation and conversation: Direct observation of how individuals perform work (or tasks) and implement processes in their respective environments.
Bootstrapping: Bringing key stakeholders together to define product requirements, and effectively guiding participants to actively participate in giving input. Suitable scenarios for bootstrapping include Joint Application Design or Development (JAD), Quality Function Deployment (QFD), and User Stories
(7) System Interaction Diagrams
A visualization of the scope of a product that shows the business systems (processes, devices, computer systems, etc.) and how they interact with people and other systems (actors). Shows the inputs to the business system, the input providers, the outputs from the business system, and the output receivers.
(8) Prototyping
Prototyping is the process of building a model of a desired product and soliciting early feedback on requirements accordingly before actually manufacturing that product. This includes miniature products, computer-generated two- and three-dimensional models, solid models, or simulations.
2-2-3 Outputs
(1) Requirements Documentation
A requirements document describes how various single requirements will meet the business needs associated with a project. It may start with only high-level requirements and then progressively refine them as more information about the requirements is added.
Requirement categories include: business requirements, related party requirements, solution requirements (functional/non-functional), transition and readiness requirements, project requirements, and quality requirements
(2) Requirements Traceability Matrix
A Requirements Traceability Matrix is a table that connects a product requirement from its source to a deliverable that satisfies the requirement. Using the Requirements Tracking Matrix to link each requirement to a business goal or project objective helps ensure that each requirement has business value.
It can be applied to track requirements throughout the project lifecycle. Typical attributes recorded in the Requirements Tracking Matrix include a unique identifier, a textual description of the requirement, the reason for its inclusion, the owner, the source, the priority level, the version, the current status (e.g., in-progress, canceled, deferred, newly added, approved, assigned, and completed), and the status date.
3-1 Definition
Defining scope is the process of developing detailed descriptions of projects and products, and the primary role of this process is that describing the boundaries and acceptance criteria for a product, service, or outcome addresses the question of what needs to be done.
The essence is to select the final project requirements from the requirements document (the output of the requirements gathering process) and then develop a detailed description of the project and its products, services, or outcomes.
3-2 Key Descriptions
3-2-1 Inputs
(1) Project charter
The project charter contains a high-level description of the project, product characteristics, and approval requirements.
(2) Project Management Plan
The Scope Management Plan in the Project Management Plan documents how the project scope will be defined, validated, and controlled.
(3) Project Documentation
Assumptions Log: Assumptions and constraints about the product, the project, the environment, the parties involved, and the assumptions and constraints that will affect the scope of the project and the product.
Requirements Document: Requirements to be included in the scope.
Risk Register: Response strategies that may affect the project scope, such as reducing or changing the project and product scope to avoid or mitigate risks.
(4) Business Environment Factors
? Organizational culture; infrastructure; personnel management systems; market conditions.
(5) Organizational Process Assets
Policies, procedures, and templates used to develop the project scope statement; project archives from previous projects; lessons learned from previous phases or projects.
3-2-2 Tools and Techniques
(1) Expert Judgment
(2) Data Analysis
Commonly used in this process, an alternatives analysis can be used to evaluate a variety of approaches to achieving the needs and objectives stated in the project charter.
(3) Decision Making
Commonly used is Multi-Criteria Decision Analysis (MCDA), which is a technique that uses systems analysis methods with the help of decision matrices to establish criteria such as requirements, schedule, budget, and resources to refine the scope of the project and product.
(4) Interpersonal and Team Skills
Facilitates cross-functional **** understanding of project deliverables and project and product boundaries among key stakeholders.
(5) Product Analysis
Product analysis can be used to define products and services, including asking and answering questions about a product or service to describe the uses, features, and other aspects of the product to be delivered.
Product analysis techniques include product decomposition, requirements analysis, systems analysis, systems engineering, value analysis, and value engineering.
3-2-3 Outputs
(1) Project Scope Statement
A project scope statement is a description of the project scope, key deliverables, assumptions, and constraints. It includes:
? Product Scope Description: Progressively refine the characteristics of the product, service, or outcome as described in the project charter and requirements documents.
Deliverable : Any unique and verifiable product, outcome or
service capability that must be produced to complete a process, phase, or project : Deliverables also include ancillary outcomes such as project management reports and documentation.
? Acceptance Criteria: A set of conditions that must be met before a deliverable can be accepted.
Project exclusions: Identify what is excluded from the project.
(2) Project Documentation Updates
Documents that can be updated during the process include: Assumptions Log, Requirements Documentation, Requirements Tracking Matrix, and Stakeholder Register.
4-1 Definitions
Creating a work breakdown structure (WBS) is the process of breaking down project deliverables and project work into smaller, more manageable components. This process addresses the how.
4-2 Key Description
4-2-1 Inputs
(1) Project Management Plan
The Scope Management Plan in the Project Management Plan defines how to create the WBS based on the project's Scope Statement.
(2) Project Documents
The project's Scope Statement: the work that needs to be performed and the work that is not included in the project. work that needs to be performed and work that is not included in the project.
Requirements document: how a single requirement meets the business needs of the project.
(3) Business Environment Factors
Business environment factors that can influence the process of creating a WBS include, but are not limited to, WBS standards for the industry in which the project is located, which can be used as external references for creating the WBS.
(4) Organizational Process Assets
Organizational process assets that can influence the creation of the WBS process include, but are not limited to: policies, procedures, and templates used to create the WBS; project archives from previous projects; and lessons learned from previous projects.
4-2-2 Tools and Techniques
(1) Expert Judgment
(2) Decomposition
Decomposition is a method of creating a WBS process.
Decomposition is a technique for progressively dividing the project scope and project deliverables into smaller, more manageable components; work packages are the lowest level of the WBS at which costs and durations can be estimated and managed.
4-2-3 Outputs
(1) Scope Baseline
The Scope Baseline is the approved Scope Statement, WBS, and corresponding WBS Lexicon.
Project Scope Statement: Includes a description of the project scope, key deliverables, assumptions, and constraints
WBS: A hierarchical decomposition of the full scope of work that needs to be performed by the project team in order to achieve the project's objectives and create the required deliverables.
Work Package: The lowest level of the WBS is the Work Package with a unique identification number. Each work package is part of the control account.
Planning Packages: A control account can contain one or more planning packages, which are components of the WBS that are below the control account and above the work packages, where the content of the work is known, but the detailed schedule activities are unknown.
WBS Dictionary: A document that describes the detailed deliverables, activities, and schedule information for each component in the WBS.
(2) Project Document Updates
Project documents that can be updated during this process include the Assumptions Log and Requirements Document.
Confirmation of scope is the process of formally accepting completed project deliverables. Acceptance is addressed.
5-2-1 Inputs
(1) Project Management Plan
Scope Management Plan, Requirements Management Plan, and Scope Baseline
(2) Project Documents
Lessons Learned Log, Quality Report, Requirements Documentation, and Requirements Tracking Matrix
(3) Verified Deliverables
A verified deliverable is one that is completed and has been accepted. Deliverables are deliverables that have been completed and checked as correct by the control quality process.
(4) Work performance data
Includes the degree of conformance to requirements, the number of inconsistencies, the severity of inconsistencies, or the number of validations performed in a given time period.
5-2-2 Tools and Techniques
(1) Inspection
Inspection refers to the activities of measurement, review, and validation that are performed to determine whether the work and deliverables meet the requirements and product acceptance criteria. Inspections are sometimes referred to as reviews, product reviews, and walk-throughs.
(2) Decision Making
Decision making techniques that can be used for this process include (but are not limited to) voting.
5-2-3 Outputs
(1) Accepted Deliverables
Deliverables that meet the acceptance criteria should be formally signed off on and approved by the customer or sponsor. Formal documentation should be obtained from the client or sponsor to demonstrate formal acceptance of the project deliverables by the relevant parties.
(2) Work performance information
This includes information on the progress of the project, such as which deliverables have been accepted and which have not and why. This information should be documented and communicated to the appropriate parties.
(3) Change Requests
Deliverables that have been completed but not formally accepted, and the reasons why they have not been accepted, should be documented. It may be necessary to make a change request for these deliverables to carry out defect remediation.
(4) Project Document Updates
Project documents that can be updated by this process include: lessons learned registry, requirements document, requirements tracking matrix
Controlling scope is the process of monitoring the scope status of the project and the product, and managing changes to the scope baseline. The primary role of this process is to maintain the maintenance of the scope baseline throughout the project and needs to be carried out throughout the duration of the project.
6-2-1 Inputs
(1) Project Management Plan
Includes Scope Management Plan, Requirements Management Plan, Change Management Plan, Configuration Management Plan, Scope Baseline, and Performance Measurement Baseline
(2) Project Documents
Lessons Learned Register, Requirements Documentation, Requirements Tracking Matrix
(3) Work Performance Data
Includes the number of change requests received, the number of change requests accepted, or the number of deliverables verified, confirmed, and completed.
(4) Organizational Process Assets
Organizational process assets that can influence the process of controlling scope include, but are not limited to: existing, formal and informal policies, procedures, and guidance related to scope control; and available methods and templates for monitoring and reporting.
6-2-2 Tools and Techniques
(1) Data Analysis
Deviation Analysis: Deviation analysis is used to compare the baseline to the actual results to determine if the deviation is within a critical value range or if corrective or preventive action is necessary.
Trend Analysis: Trend analysis is designed to examine how project performance is changing over time to determine whether performance is improving or deteriorating.
6-2-3 Outputs
(1) Work Performance Information
The work performance information generated by this process is interrelated and contextualized information about the implementation of the project and product scope (against the scope baseline), including the classification of changes received, scope deviations identified and their causes, the impact of the deviations on schedule and cost, and predictions of future
(2) Change Requests
After analyzing project performance, change requests may be made to the scope baseline and schedule baseline, or other components of the project management plan. Change requests need to be reviewed and processed by the implementation of the overall change control process.
(3) Project Management Plan Updates
Scope Management Plan
Scope Baseline: After changes to the scope, scope statement, WBS, or WBS lexicon have been approved, corresponding changes need to be made to the scope baseline.
Progress Baseline: Changes to the progress baseline are required after changes to the scope, resource, or schedule estimates have been approved.
Cost Baseline: Changes to the cost baseline are required when changes to scope, resources, or cost estimates are approved.
Performance Measurement Benchmarks: Changes to Performance Measurement Benchmarks are required when changes to Scope, Schedule Performance, or Cost Estimates are approved.
(4) Project Document Updates
Project documents that can be updated during this process include: Lessons Learned Register, Requirements Documents, Requirements Tracking Matrix
.