#5 PMP - Project Scope Management

#5 Project Scope Management

Scope Management Processes

The knowledge area of Scope Management includes the processes required to ensure that the project includes all the work, and only all the work required to complete the project successfully. It is primarily concerned with controlling what is and what is not in the scope.

Project Portfolio Management is the process of project selection. It involves making a decision about which project an organization should execute.

The knowledge area of Project Scope Management consists of the following processes:

Process	Project Group	Key Deliverables
Plan Scope Management	Planning	Plan Scope Management
Collect Requirements	Planning	Requirements document
Define Scope	Planning	project scope statement
Create WBS	Planning	WBS, WBS dictionary
Validate Scope	Monitoring and Controlling	Acceptance deliverables
Control Scope	Monitoring and Controlling	Change Requests

Plan Scope Management

Plan Scope Management is the process of creating a scope management plan that documents how the project 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. The Inputs, Tools and Techniques, and Outputs of Collect Requirements process are given below.

Inputs	Tools and Techniques	Outputs
Project Management Plan	Expert judgment	Scope Management Plan
Project Charter	Meetings	Requirements Management Plan
Enterprise environmental factors
Organizational process assets

Scope Management Plan

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 verified. The scope management plan is a major input into the Develop Project Management Plan process, and the other scope management processes. The components of a scope management plan include:

-          Process for preparing a detailed project scope statement;

-          Process that enables the creation of the WBS from the detailed project scope statement;

-          Process that establishes how the WBS will be maintained and approved;

-          Process that specifies how formal acceptance of the completed project deliverables will be obtained; and

-          Process to control how requests for changes to the detailed project scope statement will be processed.

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

Requirements Management Plan

The requirements management plan is a component of the project management plan that describes how requirements will be analyzed, documented, and managed.

The project manager chooses the most effective relationship for the project and documents this approach in the requirements management plan. Many of the requirements management plan components are based on that relationship.

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 to the product 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;

-          Product metrics that will be used and the rationale for using them; and

-          Traceability structure to reflect which requirement attributes will be captured on the traceability matrix.

Collect Requirements Process

Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives. The key benefit of this process is that it provides the basis for defining and managing the project scope including product scope. The Inputs, Tools and Techniques, and Outputs of Collect Requirements process are given below.

Inputs	Tools & Techniques	Outputs
Scope management plan	Interviews	Requirements documentation
Requirements management plan	Focus groups	Requirements traceability matrix
Stakeholder management plan	Facilitated workshops
Project Charter	Group creativity techniques
Stakeholder register	Questionnaires and surveys
	Observations
	Prototypes
	Group decision-making techniques
	Benchmarking
	Document analysis
	Context diagram

The project’s success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project. Requirements become the foundation of the WBS. Cost, schedule, quality planning, and sometimes procurement are all based upon these requirements.

Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated. These classifications include:

-          Business requirements, which 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, which describe needs of a stakeholder or stakeholder group.

-          Solution requirements, which 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:

o   Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product.

o   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 requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.

-          Project requirements, which describe the actions, processes, or other conditions the project needs to meet.

-          Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.

Requirements documentation

Requirements documentation describes how individual requirements meet the business need for the project. Components of requirements documentation can include, but, are not limited to:

-          Business requirements, including:

o   Business and project objectives for traceability;

o   Business rules for the performing organization; and

o   Guiding principles of the organization.

-          Stakeholder requirements, including:

o   Impacts to other organizational areas;

o   Impacts to other entities inside or outside the performing organization; and

o   Stakeholder communication and reporting requirements.

-          Solution requirements, including: Functional and nonfunctional requirements;

o   Technology and standard compliance requirements;

o   Support and training requirements;

o   Quality requirements; and

o   Reporting requirements, etc. (solution requirements can be documented textually, in models, or both).

-          Project requirements, such as:

o   Levels of service, performance, safety, compliance, etc.; and

o   Acceptance criteria.

-          Transition requirements.

-          Requirements assumptions, dependencies, and constraints.

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.

Tracing includes, but is not limited to, tracing requirements for the following:

-          Business needs, opportunities, goals, and objectives;

-          Project objectives;

-          Project scope/WBS deliverables;

-          Product design;

-          Product development;

-          Test strategy and test scenarios; and

-          High-level requirements to more detailed requirements.

Elements of Project Charter and Project Scope Statement

Project Charter	Project Scope Statement
Project Purpose or Justification	Project scope description (progressive elaborated)
Measurable project objectives and related process criteria	Acceptance criteria
High level requirements	Project deliverables
High level project description	Project exclusions
High level risk	Project Constraints
Summary milestone schedule	Project assumptions
Summary budget
Stakeholder list
Project approval requirements (what constitutes success, who decide it, and authority level)
Assign project manager responsibility, and authority level
Name and authority of the sponsor or other person(s) authorizing the project charter

Define Scope Process

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 project, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope. The Input, Tools and Techniques and Output of the Define Scope process are:

Inputs	Tools & Techniques	Outputs
Scope management plan	Expert judgment	Project scope statement
Project charter	Product analysis	Project document updates
Requirements documentation	Alternative identification
Organizational process assets	Facilitated workshops

Project Scope Statement

The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project’s deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations.

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

-          Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation.

-          Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted.

-          Deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as project management reports and documentation. These deliverables may be described at a summary level or in great detail.

-          Project exclusion. Generally identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations.

-          Constraints. A limiting factor that affects the execution of a project or process. Constraints identified with the project scope statement list and describe the specific internal or external restrictions or limitations associated with the project scope that affect the execution of the project, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization. When a project is performed under an agreement, contractual provisions will generally be constraints. Information on constraints may be listed in the project scope statement or in a separate log.

-          Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration. Also describes the potential impact of those factors if they prove to be false. Project teams frequently identify, document, and validate assumptions as part of their planning process. Information on assumptions may be listed in the project scope statement or in a separate log.

Create WBS Process

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 structured vision of what has to be delivered. The Inputs, Tools and Techniques and Outputs of Create WBS process are:

Inputs	Tools & Techniques	Outputs
Scope management plan	Decomposition	Scope baseline: ·         WBS ·         WBS dictionary ·         Project scope statement
Project Scope Statement	Expert judgment	Project document updates
Requirements documentation
Enterprise environmental assets
Organizational process assets

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.

Work Breakdown Structure (WBS) is an important part of the exam. It is a graphical representation of the hierarchy of the project. The WBS template can be reused across projects. WBS forces the project team to think through all the levels of the project. If a task is not in the WBS, then it is not part of the project.

8/80 rule for WBS - No task should be less than 8 hours or more than 80 hours.

WBS dictionary explains all the WBS components. Also WBS is input to most of the planning processes. Specifically WBS is input to the following processes -

·         Cost Estimating

·         Cost Budgeting

·         Scope control

·         Activity Definition

·         Plan Purchases and Acquisitions

Scope Baseline

The scope baseline is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that 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.

-          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. The WBS is finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account 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. Information in the WBS dictionary may include, but is not limited to:

o   Code of account identifier,

o   Description of work,

o   Assumptions and constraints,

o   Responsible organization,

o   Schedule milestones,

o   Associated schedule activities,

o   Resources required,

o   Cost estimates,

o   Quality requirements,

o   Acceptance criteria,

o   Technical references, and

o   Agreement information.

Validate Scope Process

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 chance of final product, service, or result acceptance by validating each deliverable. The table below gives inputs, Tools & Techniques, and Outputs of the Validate Scope process.

Inputs	Tools & Techniques	Outputs
Project management plan	Inspection	Accepted Deliverables
Requirements documentation	Group decision making techniques	Change requests
Requirements traceability matrix		Project document updates
Verified deliverables		Work performance information
Work performance data

The verified deliverables obtained from the Control Quality process are reviewed with the customer or sponsor to ensure that 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 quality control 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.

Control Scope Process

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 it allows the scope baseline to be maintained throughout the project. The Inputs, Tools and Techniques and Outputs of Control Scope process are:

Inputs	Tools & Techniques	Outputs
Project management plan	Variance analysis	Work performance information
Requirements documentation		Change requests
Requirements traceability matrix		Project management plan updates
Organizational process assets		Organizational process assets updates
Work performance information		Project document updates