3 scope Management

2
 The term “scope” can refer to:
 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.
 The term “project scope” is sometimes viewed as including
product scope.
❖ Project scope completion is measured against the project
management plan.
❖ product scope completion is measured against the product
requirements
Example : install 100 telecom 5G sites (this is product scope )
and we need complete site survey , draw layout , transport
materials ,….., etc. (project scope ) .
Project Scope Management

3
Project Scope Management
.
 Includes the processes required to ensure that the project includes all
the work required, and only the work required, to complete the project
successfully within schedule and cost .
 primarily concerned with defining and controlling what is and is not
included in the project
 Preventing extra work and scope creep
 The overall approach advocated here is scope first, schedule second,
and budget third.
 Any change to scope must be evaluated for its effect on time, cost,
risk, quality, resources, and customer satisfaction. Changes to scope
require an approved change request..

4
Gold Plating concept
 Meaning giving the customer more than what he
originally asked for.
 Gold plating is performing extra work that wasn't
originally agreed to.
 You should give the customer what they asked for,
no more and no less. Giving any extras is a
waste of time and adds no benefit to the project .
Scope Creep
 (requirement creep, function creep)
Refers to changes, continuous or
uncontrolled growth in a project’s scope.
 It occurs when the scope of a project is
not properly defined, documented, or
controlled.

5
5
Scope creep occurs due to the following reasons
•Interference from the client.
•An incomplete scope statement.
•A poor change control system.
•Miscommunication among the team members.
•Reasons external to organizations: e.g., market conditions, regulatory requirements, or technological
advancements.
•Not checking on project activities
Following guidelines can help you avoid scope creep:
•Never allow changes without proper review.
•Establish a communication channel between the client and you.
•Don’t let the client speak to your team members unless it is required.
•The scope statement should be thorough and well communicated to stakeholders.
•Establish a robust change control system.
•Encourage open communication within the team.
•Monitor the project’s progress closely.
any change that passes through an integrated change management process is not
scope creep. Here, you review it and adjust other project objectives to accommodate
the change: for example, updating cost or schedule baselines due to a change.
Scope creep

6
6
The following are a few causes of gold plating:
•It is done to make the client happy.
•Team members may add extra functions to prove their ability.
•A project manager may add extra functions to earn credit.
•Sometimes it is performed to divert attention from defects
gold plating
How to Avoid Gold Plating
•Never allow the team members to add any extra features to the product without approval.
•As a project manager, just avoid it.
•Establish open communication lines within the team

7
Knowledge Areas
Project Management Process Groups
Initiating Planning Executing Monitoring and Controlling Closing
Project Integration
Management
4.1 Develop
Project
Charter
4.2 Develop Project Management
Plan
4.3 Direct and Manage Project
Work
4.4 Manage Project Knowledge
4.5 Monitor and Control Project
Work
4.6 Perform Integrated Change
Control
4.7 Close
Project
Project Scope
Management
5.1 Plan Scope Management
5.2 Collect Requirements
5.3 Define Scope
5.4 Create WBS
5.5 Validate Scope
5.6 Control Scope
Project Schedule
Management
6.1 Plan Schedule
6.2 Define Activities
6.3 Sequence Activities
6.4 Estimate Activity Durations
6.5 Develop Schedule Management
6.6 Control Schedule
Project Cost
Management
7.1 Plan Cost Management
7.2 Estimate Costs
7.3 Determine Budge
7.4 Control Costs
Project Quality
Management
8.1 Plan Quality Management 8.2 Manage Quality 8.3 Control Quality
Project Resource
Management
9.1 Plan Resource Management
9.2 Estimate Activity Resources
9.4 Acquire Resources
9.5 Develop Team
9.6 Manage Team
9.7 Control Resources
Project
Communications
Management
10.1 Plan Communications
Management
10.2 Manage Communications 10.3 Monitor Communications
Project Risk
Management
11.1 Plan Risk Management
11.2 Identify Risks
11.3 Perform Qualitative Risk
Analysis
11.4 Perform Quantitative Risk
Analysis
11.5 Plan Risk Responses
11.6 Implement Risk Responses 11.7 Monitor Risks
Project Procurement
Management
12.1 Plan Procurement Management 12.2 Conduct Procurements 12.3 Control Procurements
Project Stakeholder
Management
13.1 Identify
Stakeholders
13.2 Plan Stakeholder Engagement
13.4 Manage Stakeholder
Engagement
13.5 Monitor Stakeholder
Engagement
Project Scope management = 6 process (4 process in planning +2 in monitoring and contorting )

8
8
Scope Management and life cycle :
In a predictive life cycle:-
1 The project deliverables are defined at the beginning of the project and any changes to the scope are
progressively managed.
2 Three processes (Collect Requirements, Define Scope, and Create WBS) are performed toward the
beginning of the project and updated as necessary, using the integrated change control process.
3 Validate Scope occurs with each deliverable or phase review and Control Scope is an ongoing
process.
4 The scope baseline for the project is the approved version of the project scope statement, work
breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only
through formal change control procedures and is used as a basis for comparison while performing
Validate Scope and Control Scope processes as well as other controlling processes.

9
9
In an adaptive or agile life cycle:-
1 The deliverables are developed over multiple iterations where a detailed scope is defined and approved
for each iteration when it begins.
2 Projects with adaptive life cycles are intended to respond to high levels of change and require ongoing
stakeholder
engagement.
3 The overall scope of an adaptive project will be decomposed into a set of requirements and work to be
performed, sometimes referred to as a product backlog. At the beginning of an iteration, the team will
work to determine how many of the highest-priority items on the backlog list can be delivered within the
next iteration.
4 Three processes (Collect Requirements, Define Scope, and Create WBS) are repeated for each iteration.
This is on the contrary in a predictive project.
5 In an adaptive or agile life cycle, the sponsor and customer representatives should be continuously
engaged with the project to provide feedback on deliverables as they are created and to ensure that the
product backlog reflects their current needs.
6 Two processes (Validate Scope and Control Scope) are repeated for each iteration. This is on the
contrary in a predictive project.

10
10
7 Projects with adaptive life cycles use backlogs (including product requirements and user
stories) to reflect their current needs.
8- In agile approaches, the requirements constitute the backlog.
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL

11
11
 The role of business analyst that is responsible for requirement-related activities that
in case of a business analyst is assigned to a project, where the role with responsibility
to conduct business analysis should be assigned to resources with sufficient business
analysis skills and expertise.
 The project manager role is responsible for ensuring that requirements-related work is
accounted for in the project management plan and that requirements-related activities
are performed on time and within budget and deliver value.
 The relationship between a project manager and a business analyst should be a
collaborative partnership. A project will have a higher likelihood of being successful if
project managers and business analysts fully understand each other’s roles and
responsibilities to successfully achieve project objectives.
Scope Management and Business analysis

12
The process of creating a scope management plan that documents how the project &
product scope will be defined, validated, and controlled.
1 Project charter
2 Project management plan
• Quality management plan
• Project life cycle description
• Development approach
3 Enterprise environmental factors
4 Organizational process assets
1. Expert judgment
2. Data analysis
• Alternatives
analysis
3. Meetings
1 Scope management plan
2 Requirements management
plan
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL
Inputs Tools & Techniques Outputs

13
13
- Key benefit of this process is that it provides guidance and
direction on how scope will be managed throughout the project
.
-This process is performed once or at predefined points .
- The development of the scope management plan and the
detailing of the project scope begin with the analysis of
information contained in the (project charter, latest approved
subsidiary plans of the project management plan, historical
information contained in OPA and EEF’s)

14
5.1 Plan Scope Management Input
1- PROJECT CHARTER
 High-level project description assumptions, constraints, and high-level
requirements.
2- PROJECT MANAGEMENT PLAN
 Quality management plan: The way the project will be managed is
influenced by organization quality policy, methodologies, and
standards
 Project life cycle description: determines the series of phases that a
project passes through from its inception to the end of the project.
 Development approach: The development approach defines whether
waterfall, iterative, adaptive, agile, or a hybrid development approach
will be used
3- ENTERPRISE ENVIRONMENTAL FACTORS (EEF) :
4- ORGANIZATIONAL PROCESS ASSETS(OPA) .
such as historical records and lessons learned, include requirements from past, similar projects
and help identify relevant processes and expectations.

15
5.1 Plan Scope Management Tools & Techniques
1- Expert judgment
- Previous similar projects and information in the industry, discipline and
application area
2-Data Analysis
 Alternative Analysis: Various ways of collecting requirements, create,
validate and control scope. It used to select the corrective actions or a
combination of corrective and preventive actions to implement when a
deviation occurs.
3- Meetings
 May include (Sponsor, project manager, team members and selected
stakeholder)

16
5.1 Plan Scope Management Output
1-SCOPE MANAGEMENT PLAN
 Component of the project management plan that describes how the scope will be
defined, developed, monitored, controlled, and validated
 Components includes processes that help to
1- Preparing project scope statement.
2- create WBS.
3-how the baseline will be approved and maintained .
4- how formal acceptance will be obtained
 The scope management plan can be formal or informal, broadly framed or highly
detailed

17
17
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
 It’s also referred as Business Analysis Plan according to Business analysis
 Components may include :
1-Configuration management activities,
2- Requirements prioritization,
3- Metrics,
4-Traceability structure
5- how requirements will be planned, tracked and reported.
 Traceability structure reflects the requirement attributes captured on the traceability
matrix.
 Configuration management shows how changes will be initiated, how impacts will be
analyzed, how they will be traced and reported and authorization levels to approve
changes

18
5 .2 Collect Requirements
The process of determining, documenting, and managing stakeholder needs &
requirements to meet project objectives.
1. Project charter
2. Project management plan
•Scope management plan
•Requirements management
plan
• Stakeholder engagement plan
3. Project documents
• Assumption log
• Lessons learned register
• Stakeholder register
4. Business documents
• Business case
5. Agreements
6. Enterprise environmental factors
7. Organizational process assets
1. Expert judgment
2. Data gathering
• Brainstorming
• Interviews
• Focus groups
• Questionnaires and surveys
• Benchmarking
3. Data analysis
• Document analysis
4. Decision making
• Voting
• Multicriteria decision analysis
5. Data representation
• Affinity diagrams
• Mind mapping
6. Interpersonal and team skills
• Nominal group technique
• Observation/conversation
• Facilitation
7. Context diagram
8. Prototypes
1.Requirements documentation
2.Requirements traceability
matrix
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL

19
19
 Key benefit of this process is that it provides the basis for defining the product scope
and project scope.
 This process is performed once or at predefined points .
 The project’s success is directly influenced by active stakeholder involvement in the
discovery and decomposition of needs into project and product requirements
 Requirements include conditions or capabilities that are required to be present in a
product to satisfy an agreement and business needs.
 Requirements need to be elicited, analyzed, and recorded in enough detail to be
included in the scope baseline and to be measured once project execution begins
 Requirements become the foundation of the WBS ,Cost, schedule, quality planning,
and procurement

20
5 .2 Collect Requirements Input
1- PROJECT CHARTER
Includes (Scope management plan, Requirements management plan and
Stakeholder engagement plan)
 Stakeholder engagement plan: used to understand stakeholder communication
requirements and the level of stakeholder engagement in order to assess
stakeholder requirements
3- PROJECT DOCUMENTS
Includes (Assumption Log, Lessons learned register and Stakeholder register)
 Assumption Log The assumption log documents known stakeholder assumptions related
to product and project requirements. Collect Requirements includes refining and adding
to this list of assumptions.
 Stakeholder Register: used to identify stakeholders who can provide information
on the requirements also captures requirements and expectations that stakeholders
have for the project.

21
21
4- BUSINESS DOCUMENTS
Business Case influence this process as it describes required, desired, and optional criteria for meeting
the business needs including the business case and the benefits management plan—are key inputs to the
development of the project charter. They provide critical information to the project manager and team, such
as:
• Why the project was undertaken
• A summary of the relationship between the project objectives and the strategic goals of the organization
5- AGREEMENTS If the project includes procurements, the requirements of the buyers are
documented in the contracts. Any agreed-upon requirements included in letters of agreement within
an organization are also a source of requirements.
6- EEF
7- OPA
such as historical records and lessons learned, include requirements from past, similar projects and help identify
relevant processes and expectations.

22
5 .2 Collect Requirements Tools & Techniques
1- Expert Judgment
Experts specialized in (Business analysis, Requirements elicitation, Requirements analysis
Requirements documentation, Project requirements in previous similar projects, Diagramming
techniques, Facilitation, and Conflict management)
2- Data Gathering
2-1 Brainstorming: used to generate and collect multiple ideas related to project/product
requirements .
identify a list of ideas in a short period of time.
It is conducted in a group environment and is led by a facilitator. Brainstorming comprises two parts:-
(idea generation - analysis).
Brainstorming can be used to gather data and solutions or ideas from stakeholders, subject matter
experts, and team members.
Although brainstorming by itself does not include voting or prioritization, it is often used with other
group creativity techniques that do.

23
23
1. Identify the problem, goal, or outcome for the brainstorming session.
2. All members of the group state their ideas.
3. Record all ideas.
If time allows, the ideas can be elaborated, analyzed, or prioritized.

24
24
5.2.2.1 Interviews
An interview is a formal or informal approach to elicit information from stakeholders by talking to
them directly.
It is typically performed by asking prepared and spontaneous questions and recording the
responses.
Interviewing experienced project participants, sponsors and other executives, and subject matter
experts
It can aid in identifying and defining the features and functions of the desired product
deliverables.
Interviews are often conducted ―one-on-one, but may involve multiple interviewers and/or
multiple interviewees.

25
25
5.2.2.2 Focus Groups
Focus groups bring together prequalified stakeholders and subject matter experts to learn about their
expectations and attitudes about a proposed product, service, or result.
A trained moderator guides the group through an interactive discussion,
It designed to be more conversational than a one-on-one interview.
Brainstorming = generate ideas Vs focus group = improve existing ideas

26
26
5.2.2.6 Questionnaires and Surveys
Questionnaires and surveys are written sets of questions designed to quickly accumulate information
from a large number of respondents.
Questionnaires and/or surveys are most appropriate
 With varied audiences,
 When a quick turnaround is needed,
 When respondents are geographically dispersed, and
 Where statistical analysis is appropriate.

27
27
5.2.2.9 Benchmarking
This technique involves comparing actual or planned project practices to those of comparable
projects.
To:
 identify best practices
 Generate ideas for improvement
 Provide a basis for measuring performance.
Benchmarked projects may exist within the performing organization or outside of it, or can be
within the same application area.

28
28
3- Data Analysis
 Document analysis which consists of reviewing and assessing any relevant documented information
to elicit requirements by analyzing existing documentation and identifying information relevant to the
requirements
• Examples
 Business plans,
 Marketing literature,
 Agreements,
 Requests for proposal,
 Current process flows,
 Other requirements documentation, problem/issue logs, policies, procedures, and
 Regulatory documentation such as laws, codes.

29
29
4- Decision making
 Voting: Used to classify and prioritize product requirements. (unanimity, majority and
plurality)
• Unanimity - everyone agrees on a single course of action
• Majority - More than 50% of the members agree
• Plurality. - Largest block in a group decides.
 Autocratic decision making: one individual takes responsibility for making the decision
 Multicriteria decision analysis: decision matrix to provide a systematic analytical
approach for establishing criteria, such as risk levels, uncertainty, and valuation, to
evaluate and rank many ideas

30
30
5- Data Presentation
• Affinity diagrams: allow large numbers of ideas to be classified into groups for review and
analysis.
Affinity is generate + organize +classify

31
• Mind mapping: consolidates ideas created through individual brainstorming sessions into a
single map to reflect commonality and differences in understanding and to generate new
ideas.
- A mind map is a technique that starts with an idea (or project) in the center. Then you branch out
from the project and identify the main themes or deliverables associated with the idea. Each
theme or deliverable has further details. The “branching out” continues until you have a
completed mind map that provides an overview of the entire project or elements of a project
under analysis.
-Mind mapping is generate and organize ideas .

32
32
6- Interpersonal and Team Skills
 Nominal group technique: Enhances brainstorming with a voting process used to rank the most useful
ideas for further brainstorming or for prioritization. It includes four steps
 Question is posed to the group. Each person silently generates and writes down their ideas
 Moderator writes down the ideas on a flip chart until all ideas are recorded
 Each recorded idea is discussed until all group members have a clear understanding
 Individuals vote privately to prioritize the ideas. (Voting may take place in many rounds)
Nominal group technique is generate + ranking + voting

33
33
 Observation and conversation (Job Shadowing): Direct way of viewing
individuals in their environment and how they perform their jobs.
Usually used when people have difficulty or reluctant to articulate their
requirements.
Usually it’s done externally by an observer viewing business expert performing
the job.
Also can be done by a participant observer who actually performs a process to
experience how it’s done and uncover hidden requirements

34
34
 Facilitation: 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.
This may increase stakeholder consensus and issues can be discovered earlier and resolved more
quickly than in individual sessions. Examples
 Joint application design/development (JAD) used in software development industry
 Quality function deployment (QFD): using in manufacturing industry. It collects customer needs
known as Voice of the Customer (VOC)
 User stories: short, textual descriptions of required functionality developed during workshops
Because of their interactive group nature, well-facilitated sessions CAN
 Build trust,
 Foster relationships, and
 Improve communication among the participants,

35
 Context diagrams (an example of a
scope model) visually depict the
product scope by showing a
business system (process,
equipment, computer system, etc.),
and how people & other systems
(actors) interact with it.
 Context diagrams show inputs to the
business system, the actor(s)
providing the input, the outputs
from the business system, and the
actor(s) receiving the output.
 Example : IT systems

36
36
8 Prototypes
 Prototyping is a method of obtaining early feedback on requirements by providing a working
model of the expected product before actually building it.
 Since a prototype is tangible, it allows stakeholders to experiment with a model of the final
product rather than being limited to discussing abstract representations of their
requirements.
 Prototypes support the concept of progressive elaboration in iterative cycles of mock-up
creation, user experimentation, feedback generation, and prototype revision.

37
5 .2 Collect Requirements Output
1- REQUIREMENTS DOCUMENTATION
Document describes how individual requirements meet the business need for the project.
requirements need to be unambiguous (measurable and testable), traceable, complete,
consistent, and acceptable to key stakeholders.
> Business requirements. describe the higher-level needs of the organization as a
whole.
> Stakeholder requirements. describe needs of a stakeholder or stakeholder group.
> Solution requirements. describe features, functions, and characteristics of the
product, service, or result that will meet the business and stakeholder requirements.
Functional Ex: actions, processes, data, and interactions that the product
should execute
Nonfunctional Ex: reliability, security, performance, safety, level of service,
supportability, retention.
> Transition and readiness requirements like training , software needed .
> Project requirements
> Quality requirements. Ex: include tests, certifications, validations, etc.

38
5 .2 Collect Requirements Output
2- Requirements Traceability Matrix
 Grid that links product requirements from their origin to the deliverables that satisfy them
 Ensure that each requirement adds business value by linking it to the business/project
objectives
 Provides a means to track requirements throughout the project life cycle
 Helping to ensure that requirements approved in the requirements documentation are delivered
at the end of the project
 Provides a structure for managing changes to the product scope
 Attributes associated with each requirement can be recorded in the requirements traceability
matrix
 Matrix include unique identifier, a textual description of the requirement, the rationale for
inclusion, owner source, priority, version, current status and status date
 Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may
include stability, complexity, and acceptance

39
5 .3 Define Scope
The process of developing a details description of the project & product
1 Project charter
• Scope management plan
3 Project documents
• Assumption log
• Requirements documentation
• Risk register
4 Enterprise environmental factors
5 Organizational process assets
1. Expert judgment
2. Data analysis
• Alternatives analysis
3. Decision making
• Multicriteria decision analysis
4. Interpersonal and team skills
• Facilitation
5. Product analysis
1 Project scope statement
2 Project documents updates
•Assumption log
•Requirements traceability
matrix
• Stakeholder register
5.3 Define Scope
5.3 Define Scope
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL

40
40
key benefit of this process is that it describes the product, service, or result boundaries
and acceptance criteria
Since all the requirements identified in Collect Requirements may not be included in the
project, the Define Scope process selects the final project requirements from the
requirements documentation developed during the Collect Requirements process
Develops a detailed description of the project and product, service, or result.
The preparation of a detailed project scope statement builds upon the major deliverables,
assumptions, and constraints that are documented during project initiation.
Define Scope process can be highly iterative
In iterative life cycle projects, a high-level vision will be developed for the overall project, but
the detailed scope is determined one iteration at a time
Poor Define Scope results in :
•Higher final project costs
•Changes that disrupt the project rhythm
•Rework, Lower productivity and Increase in project time.
•Carte blanche for customer to request changes, regardless of impact to the schedule, budget,
or people on the project.

41
5 .3 Define Scope Input
1- PROJECT CHARTER
How the project scope will be defined, validated and controlled
3- PROJECT DOCUMENTS :
• Assumption log: identifies assumptions and constraints about the product,
project, environment, stakeholders, and other factors that can influence the
project
• Requirements documentation.
• Risk register.
4- ENTERPRISE ENVIRONMENTAL FACTORS
5- ORGANIZATIONAL PROCESS ASSETS

42
5 .3 Define Scope Tools & Techniques
1- EXPERT JUDGMENT
2- DATA ANALYSIS
Alternatives analysis can be used to evaluate ways to meet the requirements and
the objectives identified in the charter
3- DECISION MAKING : Multicriteria decision analysis
4- INTERPERSONAL AND TEAM SKILLS
5- PRODUCT ANALYSIS
• Used to define products and services. It includes asking questions about a product
or service
• Requirements are captured at a high level and decomposed to the level of detail
needed to design the final product
• Examples include (Product breakdown, Requirements analysis, Systems analysis
and engineering and value analysis and engineering)

43
5 .3 Define Scope Output
1- PROJECT SCOPE STATEMENT
 Description of the project scope, major deliverables, assumptions, and constraints.
 Project scope statement documents the entire scope, including project and product
scope .
 Provides a common understanding of the project scope among project stakeholders
 Project charter contains high level information while project scope statement
includes detailed description of the scope components. They are progressively
elaborated throughout the project .
Project Scope Statement include (Product scope description, deliverables, acceptance
criteria and project exclusions)
2- Project Document Updates
 Includes (Assumption log, Requirements documentation, Requirements traceability
matrix and Stakeholder register)
.

44
44
Project Scope Statement include
 Product scope description. characteristics of the product, service, or result
 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.
 Project exclusion. Generally identifies what is excluded from the project.

45
5.4 Create WBS
The process of subdividing project deliverables and project work into smaller, more manageable
components .
117
5.4 Create WBS
• Project scope statement
3. Enterprise environmental factors
1. Expert judgment
2. Decomposition
1. Scope Baseline
2. Project documents updates
• Assomption log
5.4 Create WBS
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL

46
46
Key benefit of this process is that it provides a framework of
what has to be delivered .
This process is performed once or at predefined points .
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 (top-
down approach)
WBS organizes and defines the total scope of the project
and represents the work specified in the current approved
project scope statement
Planned work is contained within the lowest level of WBS
components, which called Work Packages
Work Package can be used to group the activities where
work is scheduled and estimated, monitored, and controlled
5.4 Create WBS
You need a WBS to create a Gantt chart, do critical path
analysis, and to use earned value analysis

48
Sample of WBS in IT Projects
1.0 Concept
1.1 Evaluate current systems
1.2 Define Requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support
OUTLINE VIEW

49
49
TABULAR VIEW
Level 1 Level 2 Level 3
1Widget
Management
System
1.1 Initiation 1.1.1 Evaluation & Recommendations
1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed/Approved
1.2 Planning 1.2.1 Create Preliminary Scope Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff Meeting
1.2.4 Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan Approval
1.3 Execution 1.3.1 Project Kickoff Meeting
1.3.2 Verify & Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development System
1.3.6 Testing Phase
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
1.4 Control 1.4.1 Project Management
1.4.2 Project Status Meetings
1.4.3 Risk Management
1.4.4 Update Project Management Plan

50
5.4 Create WBS Input
 Scope Management Plan
2- PROJECT DOCUMENTS
• Project scope statement.
• Requirements documentation.
3- ENTERPRISE ENVIRONMENTAL FACTORS (EEF)
4- ORGANIZATIONAL PROCESS ASSETS (OPA)

51
5.4 Create WBS Tools & Techniques
1- EXPERT JUDGMENT
2- DECOMPOSITION is a technique used for dividing and subdividing the project scope
and project deliverables into smaller, more manageable parts.
• The work package is the work defined at the lowest level of the WBS for which cost and
duration can be estimated and managed.
■ The lowest level of the WBS with a unique identifier. And part of a control account.
■ These identifiers provide a structure for hierarchical summation of
costs, schedule, and resource information and form a code of accounts.
■ control account is a management control point where scope, budget, and schedule are
integrated and compared to the earned value for performance measurement. control
account has two or more work packages, though each work package is associated with a
single control account.

52
52
 PLANNING PACKAGE: A work breakdown structure component below the control
account with known work content but without detailed schedule activities.
 CODE OF ACCOUNTS: A numbering system used to uniquely identify each
component of the work breakdown structure (WBS). 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, provide a structure for
hierarchical summation of costs, schedule, and resource information.
.

56
56
When is decomposition enough?
Ask 2 questions:
 Are your work packages small enough to be estimated for time and cost?
 Are the project manager and the project team satisfied that the current level of
detail provides enough information to proceed with subsequent project activities?
•If you can answer "YES" to those two questions, your work packages are probably
decomposed far enough.
•Every level is the detailed explanation of the level above it.
•As the work is decomposed to greater levels of detail, the ability to plan, manage,
and control the work is enhanced.
•EXCESSIVE decomposition can lead to nonproductive management effort, inefficient
use of resources, decreased efficiency in performing the work, and difficulty
aggregating data over different levels of the WBS.
 Recommended decomposition is three level high , mid ( called control account) and
low (called work package ) .

57
57
WBS Form
•The WBS structure can be represented in a number of forms, such as:
1.Using phases of the project life cycle as the SECOND LEVEL of decomposition, with the
product and project deliverables inserted at the third level;
2.Using major deliverables as the SECOND LEVEL of decomposition.
3.Incorporating subcomponents which may be developed by organizations outside the
project team such as contracted work .
 If an agile approach is used, works can be decomposed into user stories.

58
58
project life cycle as the SECOND LEVEL
major deliverables as the SECOND LEVEL

59
59
Rolling wave planning:- Decomposition may not be possible for a deliverable or subcomponent
that will be accomplished far into the future then the project management team usually waits until
the deliverable or subcomponent is agreed on, so the details of the WBS can be developed. This
technique is sometimes referred to as rolling wave planning.
100 percent rule:- The WBS represents all product and project work, including the project
management work. The aim of this rule is to achieve the effective creation of the WBS and to
assess its disintegration , 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. This is called the 100 percent
rule.

60
5.4 Create WBS Output
1- 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.
.

61
61
 Project scope statement: description of the project scope, major deliverables and
constraint.
 WBS: 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.
 Work package: The lowest level of the WBS is work package with a unique identifier. Each
work package is part of a control account which is a management control point where
scope, budget, and schedule are integrated and compared to the earned value for
performance measurement. Each control account has two or more work packages. But work
package is associated with a single control account
 Planning package: Include one or more planning packages. A planning package is a WBS
component below the control account and above the work package with known work
content but without detailed schedule activities

62
62
 WBS dictionary: document that provides detailed deliverable, activity, and scheduling
information about each component in the WBS. It’s a document that support the WBS
because you can’t include all the information in the WBS. It contains (Codes, work description,
assumption, milestones, associated activities, resources, cost, quality requirement,
references)
2- PROJECT DOCUMENTS UPDATES
• Assumption log.

63
5 .5 Validate Scope
The process of formalizing acceptance of the completed project deliverables .
• Requirements management plan
• Scope baseline
• Quality reports
• Requirements traceability matrix
3. Verified deliverables
4. Work performance data
1. Inspection
2. Decision making
• Voting
1. Accepted deliverables
2. Work performance information
3. Change requests
4. Project document updates
•Lessons learned register
matrix
5.5 Validate Scope
5.5 Validate Scope
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL

64
64
Example of the Control Quality Process and Validate Scope
 You get a project to build a 200 km road. You start the work and appoint a quality control
engineer. He will check the deliverables at each stage: e.g., f raw materials, level of the
road, the slope on the turn, alignment of the footpaths, etc. If he finds any variations in the
process or product he will take necessary corrective actions.(Control Quality )
 You have completed 50 km out of 200 km of the road. You invite the client to inspect and
accept it so you can receive payment.
They come and check whether the width of the road is correct, if the footpath is properly
aligned, and if the length is right. After inspecting these parameters, they check the strength of
the road.
Once they are satisfied, they sign the acceptance letter and you get paid for the completed
work. (Validate Scope )
The validate scope process is not always performed at the end of the project. You can perform
it during the project execution along with the control quality process

65
Knowledge Areas
Project Integration
Management
4.1 Develop
Project
Charter
Plan
Work
Work
Control
4.7 Close
Project
Project Scope
Management
5.3 Define Scope
5.4 Create WBS
5.5 Validate Scope
5.6 Control Scope
Project Schedule
Management
6.1 Plan Schedule
Project Cost
Management
7.2 Estimate Costs
7.3 Determine Budge
7.4 Control Costs
Project Quality
Management
Project Resource
Management
9.5 Develop Team
9.6 Manage Team
Project
Communications
Management
Management
Project Risk
Management
11.2 Identify Risks
Analysis
Analysis
Project Procurement
Management
Project Stakeholder
Management
13.1 Identify
Stakeholders
Engagement
Engagement

66
66
Key benefit of this process is that it brings objectivity to the acceptance process and
increases the probability of final product, service, or result acceptance by validating each
deliverable
This process is performed periodically throughout the project as needed
The verified deliverables obtained from the Control Quality process
The verified deliverables are approved through this process by the customer or sponsor
to get the accepted deliverables
Validate Scope concerned with acceptance of the deliverables
Control Quality concerned with correctness of the deliverables

67
67
Similarities Between Control Quality and Validate Scope
The following are a few similarities between the control quality and validate scope processes:
•Both processes belong to the monitor and control process group.
•Both processes involve the inspection and review of deliverables.
Differences Between Control Quality and Validate Scope
The following are a few differences between the control quality and validate scope processes:
•Control quality is an internal process, while validate scope is an external process.
•Control quality checks if the product was developed in the right way, and validate scope is concerned
with building the right product.
•The control quality process ensures that the product is ready for delivery while the validate scope
process gets the formal acceptance from the client.
•Control quality is performed during the project execution, and validate scope is usually performed at
the end of the phase or project.

69
69
1. First deliverables of the project are completed during direct and manage project work process.
2. After the deliverables are ready, Perform Quality Control inspection step takes place. This is done
generally by the quality control department of the company. For instance, let’s consider that your project
team completed a module of a software in a project. Test department will check before the customer
whether the completed module works as per requirements.
3. After the customer checks they can request changes or the defects might be fixed by the project team to
meet the requirements.
4. After defects are fixed, deliverable is now ready for the demonstration. Perform Quality Control
Inspection is repeated but this time, customer checks the deliverables. After the customer makes his
tests, verifications, and validations, project team meets with the customer.
5. After customer checks the deliverables there are 2 possible outcomes:
1. If the deliverable meets the requirements and the customer accepts the deliverables.
2. If changes are requested or if there are defects, these are reported to the project team for fixing.
Note that, change requests will be evaluated by the change control board and only approved
change requests will be implemented in the project.
Steps of Validate Scope

70
5 .5 Validate Scope Input
1- Project Management Plan
Includes (Scope management plan, Requirements management plan and Scope baseline)
2- Project Documents
Includes (Lessons learned register, Quality reports, Requirements documentation and
Requirements traceability matrix)
3- Verified deliverables
Project deliverables that are completed and checked for correctness through Control
Quality.
4- Work Performance Data
include the degree of compliance with requirements, number of nonconformities severity
of the nonconformities, or the number of validation cycles performed in a period of time

71
5 .5 Validate Scope Tools & Techniques
1-INSPECTION
• includes activities such as measuring, examining, and validating to
determine whether work and deliverables meet requirements and product
acceptance criteria.
• Inspections are sometimes called reviews, product reviews, and
walkthroughs.
2- DECISION MAKING
Voting is used to reach a conclusion when the validation is performed by the
project team and other stakeholders.

72
5 .5 Validate Scope Output
1- Accepted Deliverables
• Deliverables that meet the acceptance criteria are formally signed and approved by
customer/sponsor .
• Formal documentation received from the customer or sponsor acknowledging
formal stakeholder acceptance of the project’s deliverables is forwarded to the
Close Project or Phase process
2- Work Performance Information
 includes information about project progress, such as which deliverables have been
accepted and which have not been accepted and the reasons
3- Change Requests
 The completed deliverables that have not been formally accepted are documented,
along with the reasons for non-acceptance of those deliverables Those deliverables
may require a change request for defect repair.
Includes (Lessons learned register, Quality reports, Requirements documentation and
Requirements traceability matrix).

73
5 .6 Control Scope
The process of monitoring the status of the project & product scope and managing changes
to the scope baseline.
•Requirements management
plan
• Change management plan
•Configuration management
plan
• Scope baseline
•Performance measurement
baseline
• Requirements traceability matrix
3. Work performance data
1. Data analysis
• Variance analysis
• Trend analysis
1.Work performance information
2. Change requests
3.Project management plan
updates
• Scope baseline
• Schedule baseline
• Cost baseline
•Performance measurement
baseline
4. Project documents updates
•Lessons learned register
matrix
5.6 Control Scope
5.6 Control Scope
PLAN COLLECT DEFINE
Create
WBS
VALIDATE CONTROL

74
Knowledge Areas
Project Integration
Management
4.1 Develop
Project
Charter
Plan
Work
Work
Control
4.7 Close
Project
Project Scope
Management
5.3 Define Scope
5.4 Create WBS
5.5 Validate Scope
5.6 Control Scope
Project Schedule
Management
6.1 Plan Schedule
Project Cost
Management
7.2 Estimate Costs
7.3 Determine Budge
7.4 Control Costs
Project Quality
Management
Project Resource
Management
9.5 Develop Team
9.6 Manage Team
Project
Communications
Management
Management
Project Risk
Management
11.2 Identify Risks
Analysis
Analysis
Project Procurement
Management
Project Stakeholder
Management
13.1 Identify
Stakeholders
Engagement
Engagement

75
75
Key benefit of this process is that the scope baseline is maintained throughout the project.
This process is performed throughout the project
Controlling the project scope ensures all requested changes and recommended corrective
or preventive actions are processed through the Perform Integrated Change
Manage the actual changes when they occur and is integrated with the other control
processes
The uncontrolled expansion to product or project scope without adjustments to time, cost,
and resources is referred to as scope creep
Change is inevitable; therefore, some type of change control
process is mandatory for every project.
keep an eye on scope

76
5 .6 Control Scope Input
1- Project Management Plan
 Includes (Scope management plan, Requirements management plan, Change
management plan, Configuration management plan, Scope baseline and
Performance measurement baseline)
 Performance measurement baseline 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
2- Project Documents
 Includes (Lessons learned register, Quality reports, Requirements documentation
and Requirements traceability matrix)
3- Work Performance Data
 Work performance data can include the number of change requests received, the
number of requests accepted, and the number of deliverables verified, validated,
and completed
4- Organizational Process Assets

77
5 .6 Control Scope Tools & Techniques
1- DATA ANALYSIS
> Variance analysis.
is used to compare the baseline to the actual results and determine if the
variance is within the threshold amount or if corrective or preventive action is
appropriate.
A technique for determining the cause and degree of difference between the
baseline and actual performance.
Project performance measurements are used to assess the magnitude of
variation from the original scope baseline.
Important aspects of project scope control include determining the cause and
degree of variance relative to the scope baseline and deciding whether corrective
or preventive action is required.
> Trend analysis.
examines project performance over time to determine if performance is
improving or deteriorating.

78
5 .6 Control Scope Output
1- Work Performance Information
 correlated and contextualized information on how the project and product scope are
performing compared to the scope baseline.
 include the categories of the changes received, the identified scope variances and their
causes, how they impact schedule or cost, and the forecast of the future scope
performance
2- Change Requests
 Analysis of project performance may result in a change request to the scope and
schedule baselines
 Change requests are processed for review and disposition through the Perform
Integrated Change Control process
3- Project Management Plan Updates
 Includes (Scope management plan, Scope baseline, Schedule baseline, Cost baseline and
Performance measurement baseline)
 Includes (Lessons learned register, Quality reports, Requirements documentation and
Requirements traceability matrix)

3 scope Management

More Related Content

What's hot (20)

Similar to 3 scope Management (20)

Recently uploaded (20)

3 scope Management