Plan Scope Management Knowledge Area Mapping

Flowchart nodes

• Project Documents

• 5.2 Collect Requirements 

• 4.1 Develop Project Charter

• Project Management Plan

• Project Documents

• Business Documents

• 12.2 Conduct Procurements

• EEF's and OPA's

• Project Charter

• Requirements Management Plan 

• Scope Management Plan

• Stakeholder Engagement Plan

• Assumption Log

• Lessons Learned Register

• Stakeholder Register

• Business Case

• Agreements

• Requirements Traceability Matrix 

• Requirements documentation

• 4.1 Develop Project Charter

• Project Management Plan

• EEF's and OPA's

• 5.1 Plan Scope Management 

• Scope Management Plan

• Requirements Management Plan

• Quality Management Plan

• Project Life Cycle Description

• Development Approach

• Project Charter

• Requirements Traceability Matrix (binary/octet-stream)

• Tracing Requirements includes but is not limited to: -Business needs, opportunities, goals, and objectives -Project scope and WBS deliverables  -Product design - Test Strategy and test scenarios - High-level requirements to more detailed requirements

• Links product/project requirements from their origin to their deliverable

• Business Requirements

• Stakeholder Requirements

• Solution Requirements

• Functional Requirements

• Nonfunctional Requirements

• Transition and Readiness Requirements

• Project Requirements

• Quality Requirements

• Higher-level needs of the organization as a whole. 

• Needs of the stakeholder or stakeholder group.

• Behaviors of the product. i.e. actions, processes, data and interactions to exexute

• Environmental conditions or qualities required for the product to be effective. i.e. security, performance, safety, level of service, supportability, retention/purge etc.  

• Solution Requirements are the features, functions, and characteristics of the product

• Temporary capabilities, such as data conversion and training requirements, needed to transitions to the next state.

• Actions, processes, or other conditions the project needs to meet. i.e. milestone dates, contractual obligations, constraints

• Actions, processes, or other conditions the project needs to meet. i.e. milestone dates, contractual obligations, constraints

• How the project requirements will be collected and defined. 

• Information on how project requirements will be collected analyzed and documented.

• Used to understand stakeholder communication requirements and the level of stakeholder engagement in order to asses and adapt to the level of stakeholder participation in the requirements activities

• Identified assumptions about the product, environment, and others.

• Information on effective requirements collection techniques.

• Used to identify stakeholders that can provide information and expectations on the requirements. 

• Documents high-level project description and high-level requirements that will be used to develop detailed requirements

• Can describe the required, desired, and optional criteria for the meeting business needs. 

• Can contain project and product requirements. 

• Enterprise Environmental Factors  -Organizational Culture - Infrastructure - Personnel administration - Marketplace conditions

• Organizational Process Assets - Policies and procedures -  Historical information and lessons learned repository with information from previous projects.

• Expert Judement

• Prototypes

• Interpersonal and team skills

• Data Representation

• Context Diagram

• Data Gathering

• Data Analysis

• Decision Making

• - Brainstorming - Interviews - Focus Groups - Questionnaires and surveys - Benchmarking

• - Document Analysis

• - Voting - Autocratic decision making - Multicriteria decision analysis

• - Nominal group technique - Observation/conversation  - Facilitation

• - Affinity diagrams - Mind Mapping

• Afinity Diagram (binary/octet-stream)

• Mca Flooding Project (binary/octet-stream)

• 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 session can build trust, foster relationships, and improve communication among the participants, which can more quickly lead to increased stakeholder consensus. In addition, issues can be discovered earlier an resolved more quickly than in individual sessions.  Facilitation skills include: - Joint application design/development (JAD). Groups of SMEs working together to define requirements - Quality function deployment (QFD). Start with collecting customer needs also known as voice of the customer or VOC. - 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)

• Observation/conversation can provide a direct way of viewing individuals in their environment  and how they perform their jobs or task and carry out process. 

• Plan Scope Management documents how the project and product scope will be defined, validated, and controlled. 

• Documents the project purpose, high-level project description, assumptions, constraints, and high-level requirements.

• The way the project and product scope will be managed can be influenced by how the org.s  manages quality. 

• Determines the series of phases that the project passes through from its inception. 

• Defines whether waterfall, iterative, adaptive, agile, or a hybrid development approach will be used.

• Expert Judement

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

• Data Analysis

• - Alternatives analysis

• Meetings 

• - Attendee: Project manager, sponsor, selected team members, stakeholders, anyone responsible for any of the the scope management processes. 

• Scope Management Plan components contributed: -Process for preparing a project scope statement -Process that enables creation of WBS from detailed Project Scope Statement.  -Process that establishes how the scope baseline will be approved and maintained -Process that specifies how formal acceptance of the completed project deliverables will be obtained. 

• Context Diagram (binary/octet-stream)

• Project Charter

• Scope Management Plan

• Assumption Log

• Requirements Documentaiton

• EEF's and OPA's

• Risk Register

• 5.3 Define Scope

• Scope Statement

• Project Document Updates

• Assumption Log

• Requirements Documentaiton

• Requirements Traceability Matrix 

• Stakeholder Register

• Define Scope is the process of developing a detailed description of the project and product. It describes the product, or service, or results boundaries and acceptance criteria.  ​​​

• Identifies assumptions and constraints about the product, project, environment, stakeholders, and other factors that can influence scope.

• Contains response strategies that may affect The project scope, such as reducing or changing project scope to avoid or mitigate risk. 

• Identifies requirements that will be incorporated into the scope. 

• Documents how the scope will be defined, validated, and controlled. 

• Provides the high-level project description, product characteristics, and approval requirements.

• Updated with additional assumptions or constraints that were identified  during the process. 

• Updated with additional or changed requirements. 

• Updated to reflect updates in the requirements documentation. 

• Updated with additional information on the existing or new stakeholders  is gathered and recorded. 

• Project Scope Statement is a description of the entire scope, including project and product scope. Detailed deliverable explanations, and project scope exclusions to help manage stakeholder expectations. It provides the baseline for evaluating whether requests for changes or additional work are in/out of project boundaries. It includes the following: - Product Scope Description - Deliverables - Acceptance criteria - Project exclusions

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

• Expert Judement

• Data Analysis

• Decision Making

• Interpersonal and team skills

• Product Analysis

• - Alternatives analysis

• Document Analysis is the analysis of different documents produced as part of the output of the project control processes, such as quality reports, test reports, performance reports, and variance analysis, can point to and focus on processes that may be out of control and may jeopardize meeting the specified requirements or stakeholders expectations.  

• - Alternatives Analysis

• - Multicriteria decision analysis

• - Facilitation

• - Product Breakdown - Requirements analysis - Systems analysis -  System engineering - Value analysis - Value engineering

• - Business Requirements - Stakeholder Requirements - Solution Requirements  -  Transistion and Readiness Requirements - Project Requirements - Quality Requirements

• (Progressively elaborated)

• Project Management Plan

• Project Management Plan

• Project Management Plan

• Project Documents

• EEF's and OPA's

• Scope Statement

• Requirements Documentaiton

• Scope Management Plan

• 5.4 Create WBS

• Scope Baseline

• Assumption Log

• Requirements Documentaiton

• Documents how the WBS will be created from the project scope statement. 

• (Approved Version)

• Updated with additional assumptions or constraints that were identified  during the process. 

• Describes the work that will be performed and work that is excluded. 

• Detailed requirements describe how individual requirements meet business needs for the project. 

• Create WBS is the process of subdividing (decomposing) project deliverables and project work into more easily managed components. Provides a framework of what has to be delivered. 

• Total Scope divided into its smallest parts.

• Industry specific WBS standards may be relevant and serve as an external reference for the WBS. 

• Decomposition

• Expert Judgement

• Wbs Phase (binary/octet-stream)

• Wbs Major Deliverables (binary/octet-stream)

• Wbs 1 (binary/octet-stream)

• Decomposition is used to divide and subdivide the scope and project deliverables into smaller more manageable parts.  Work Package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. Decomposition generally involves: - 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 WBS components. - Verifying that the degree of decomposition of the deliverables is appropriate. 

• Project Phase Breakdown

• Project Deliverables Breakdown

• Project Deliverables Sub-components Breakdown

• Different deliverables can be decomposed to different levels of detail.  Excessive decomposition can lead to decreased efficiency, and may not be possible for a deliverable or subcomponent until the item is agreed on, so the details of the WBS can be developed. This technique is called rolling wave planning. 

• Work Package

• Planning Package

• WBS

• Project Scope Statement

• Hierarchical decomposition of total scope.

• Description of total scope, major deliverables, assumptions and constraints. 

• Lowest level of WBS. Each has unique identifier to provide structure for summation of cost, schedule and resources called control account. 

• A control account may include one or more planning packages. Planning package is a WBS component below the control account but above the work package, or work that has not yet been defined. 

• WBS Dictionary

• Provides detailed information about each component in the WBS to include the following: - 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 - Agreement information 

• Updated with additional or changed requirements. 

• Scope Management Plan

• Requirements Management Plan

• Project Documents

• Scope Baseline

• Requirements Documentaiton

• Requirements Traceability Matrix 

• Quality Reports

• Lessons Learned Register

• Verified Deliverables

• Work Performance Data

• 5.5 Validate Scope

• Specifies how formal acceptance of the completed project deliverables will be obtained. 

• Lessons learned can be applied to improve the validation process in the future. 

• Verified deliverabes are reviewed with the customer or sponsor to ensure they are completed satisfactorily and have received formal acceptance by the customer. Validate scope differs from Control quality in that it is mainly focused on acceptance of deliverables rather than correctness of deliverables.     

• 8.3 Control Quality 

• 4.3 Direct and Manage Project Work

• Information in the quality report may include all quality assurance issues managed or escalated.  This information is reviewed prior to acceptance. 

• Contains information about requirements, including how they will be validated. 

• Requirements are compared to actual results to determine if change, corrective, corrective action are required. 

• Can include the degree of compliance with requirements, number of nonconformities, or the number of validation cycles performed in a period of time. 

• Validate Scope is the process of formalizing acceptance of the completed project deliverables. It helps increase the probability of deliverable acceptance. 

• 4.7 Close Project or Phase

• 4.6  Perform Integrated Change Control 

• 4.5 Monitor and Control Project Work

• Project Documents

• Lessons Learned Register

• Requirements Traceability Matrix 

• Requirements Documentaiton

• Work Performance Information

• Change Requests

• Accepted Deliverables

• Describes how the project requirements are validated. 

• Scope baseline is compared to actual results to determine if a change, corrective, corrective action, or preventative action is necessary. 

• May be updated with actual results of validation,including activity including when the actual results are better than requirement or where a requirement was waived. 

• Updated as a result of the validation, including method used and outcome.

• Updated with information and challenges encountered and how they could have been avoided as well as approaches that worked well. 

• Includes information about project progress, such as which deliverables have been accepted and which have not and why. This information is communicated to stakeholders. 

• For the deliverables that where not formally accepted and require changes for defect repair. These will be processed through the Integrated Change Control Process. 

• Deliverables that meet the acceptance criteria are formally signed off and approved before moving them to the Close Project or Phase. 

• Inspection

• Voting

• Works to obtain validation through team concensus.

• Measuring, examining and validating to determine whether work and deliverables meet requirements. Can be called reviews and walkthroughs. 

• 4.3 Direct and Manage Project Work

• Project Management Plan

• EEF's and OPA's

• Documents how the project and product scope will be controlled. 

• Scope Management Plan

• Requirements Management Plan

• Change Management Plan

• Configuration Management Plan

• Scope Baseline

• Performance Measurement Baselin

• Describes how the project requirements will be managed. 

• Defines the process for managing change on the project. 

• Defines those items that are configurable, those items that require formal change control, and the process for controlling changes to such items.

• 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. 

• Compared to actual results to determine if a change, corrective action is required.

• Lessons Learned Register

• Requirements Traceability Matrix 

• Requirements Documentaiton

• Lessons learned can be applied to later phases in the project to improve scope control. 

• Helps to detect the impact of any change or deviation from the scope baseline. It may also contain status requirements being maintained. 

• Used to detect any deviation in the agreed-upon scope for the project. 

• Work Performance Data

• Includes the number of change requests accepted, and the number of deliverables verified, validated and completed. 

• 5.6 Control Scope

• Project Management Plan

• Project Documents

• 4.6  Perform Integrated Change Control 

• 4.5 Monitor and Control Project Work

• Updated to reflect any changes to how scope is managed. 

• Scope Management Plan

• Schedule Baseline

• Cost Baseline

• Scope Baseline

• Performance Measurement Baselin

• Updated as a result of the validation, including method used and outcome.

• Changes are incorporated in response to approved changes in scope, scope statement, WBS or WBS dictionary. Possibly revise scope baseline. 

• Changed in response to approved changes in scope, schedule or cost performance estimates. 

• Lessons Learned Register

• Requirements Traceability Matrix 

• Requirements Documentaiton

• Updated as a result of the validation, including method used and outcome.

• Updated as a result of the validation, including method used and outcome.

• Updated as a result of the validation, including method used and outcome.

• Change Requests

• Analysis of project performance may result in change requests to the scope baseline or other components of the project management plan. 

• Work Performance Information

• Includes correlated and contextual information on how the project is performing compared to the scope baseline. It can include the catergories of the changes received, identified scope variances and their causes, how they impact cost and the forecast of the future scope performance. 

• Trend Analysis

• Used to compare the baseline to actual results and determine if the variance is within an acceptable threshold. 

• Variance Analysis

• Examines project performance overtime to determine status of project performance. 

• Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. It keeps the Scope baseline in check throughout the project.

• Changed in response to approved changes in scope, schedule or cost performance estimates. 

• Variance Trend Analysis (binary/octet-stream)

• Rt Mtx (binary/octet-stream)

• Earned Value (binary/octet-stream)

• Earned value analysis (EVA). Performance measurement baseline to the actual schedule and cost performance. EVM integrates scope, cost and schedule baselines to form the performance measurement baseline.  EVM monitor 3 key dimensions for each work package and control account.  Planned Value (PV). Is the authorized budget assigned to scheduled work. It does not include management reserve. Total PV for a project is sometimes called the performance measurement baseline. Earned Value (EV).is a measure of work performed expressed in terms of the budget authorized for that work.  EV cannot be more than PV.  Actual Cost (AC). Is the realized cost incurred for work performed on an activity during a specific time period. This only includes direct cost.  ____________________ Variance Analysis as used in EVM (Earned Value Management) is explanation for cost, schedule, and variance at completion variances.  - Variance at completion (VAC) VAC = BAC - EAC - Schedule variance (SV). SV = Earned Value (EV) - Planned Value (PV) Earned Value Analysis EVA is useful to determine if the project is ahead or behind schedule. SV = EV - PV - Cost Variance (CV). Cost variance at the end of a project will be the difference of the Budget at Completion (BAC) and the actual money spent. CV = EV - AC or EV - BAC if at end of project.  - Schedule Performance Index (SPI).  Is a measurement of schedule efficiency expressed as the ratio of earned value to planned value. (Negative i.e. .80 is bad). SPI = EV /PV - Cost Performance Index (CPI).  ​​​​​​Is a measure of cost efficiency expressed in a ratio of earned value to actual cost.  (Negative i.e. .80 is bad and indicates you are getting 80 cents on the dollar.  -