Plan Scope Management Knowledge Area Mapping

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

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

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.

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

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.

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.

-