Project Scope Management

ICT3205-Information Technology Project Management-17/18 Batch

By Prabhashani Perera
28th Jan 2022

1
 ICT 3205 | Project Initiation by Prabhashani Perera 2

https://www.youtube.com/watch?v=kmJ59yyYza4

2
 Planning Scope Management

 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.
 Input :
 Project Management Plan, Project Charter, Enterprise Environment Factors and
Organizational Process Assets
 Tools and Techniques :
 Expert Judgment and Meetings
 Outputs :
 Scope Management Plan and Requirements Management Plan

ICT 3205 | Project Initiation by Prabhashani Perera 3

Completion of the project scope is measured against the project management plan.
Completion of the product scope is measured against the product requirements.

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

3
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 phase-to-phase relationship, strongly influences how requirements are 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

3
 Collect and Define Requirements

 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.
 Requirements Documentation
 Business requirements
 Stakeholder requirements
 Solution requirements
 Project requirements
 Requirements Traceability Matrix
 Project Scope Statement

ICT 3205 | Project Initiation by Prabhashani Perera 4

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, which describe the higher-level needs of the organization,
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:
Functional requirements describe the behaviors of the product.
Examples include processes, data, and interactions with the product.
Nonfunctional requirements supplement functional requirements and
describe the environmental conditions or qualities required for the product to be

4
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

4
 Work Breakdown Structure
 This include subdividing project deliverables and project work into smaller,
more manageable components
 A WBS structure may be created through various approaches
 Top-Down approach
 Bottom-Up approach
 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.
 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.
ICT 3205 | Project Initiation by Prabhashani Perera 5

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.

top-down approach, start with the largest items of the project and break them into
subordinate items. This process involves refining the work into greater and greater
levels of detail

bottom-up approach, team members first identify as many specific tasks related to
the project as possible. They then aggregate the specific tasks and organize them into
summary activities, or higher levels in the WBS

5
ICT 3205 | Project Initiation by Prabhashani Perera 6

6
Validating and Controlling 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 chance of final product, service, or result
acceptance by validating each deliverable
 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 uncontrolled expansion to product or project scope without adjustments
to time, cost, and resources is referred to as scope creep

ICT 3205 | Project Initiation by Prabhashani Perera 7