Chapter 3: Project Scope Management: Stevbros Training & Consultancy WWW - Stevbros.edu - VN

Chapter
3:
Project Scope Management
Stevbros Training & Consultancy
www.stevbros.edu.vn
PMI, PMP and PMBOK are registered marks of the Project Management Ins9tute, Inc.
Copyright@STEVBROS Project Management Fundamentals 1

Overview
Ini%a%ng Planning process Execu%ng Monitoring & Closing
process group process controlling process
group group process group group
Project scope •  Plan Scope •  Validate

management Management Scope
•  Collect •  Control
Requirements Scope
•  Define Scope
•  Create WBS

Overview
•  In the project context, the term scope can refer to:
–  Product scope. The features and funcQons that characterize a
product, service, or result;
–  Project scope. The work performed to deliver a product, service,
or result with the specified features and funcQons. The term
project scope is someQmes viewed as including product scope.
•  The scope baseline for the project is the approved version
of the project scope statement, work breakdown structure
(WBS), and its associated WBS dicQonary. 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.

Plan scope
management
•  The process of creaQng 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 direcQon on how scope will be
managed throughout the project.
A Guide to the Project Management Body of Knowledge, FiBh Edi9on (PMBOK® Guide) ©2013 Project Management
Ins9tute, Inc. All Rights Reserved. Figure 5-‐4 Page 111.

Inputs
1.  Project Management Plan
•  Approved subsidiary plans of the project management plan are
used to create the scope management plan and influence the
approach taken for planning scope and managing project scope
2.  Project Charter
•  Output of the Develop Project Charter process
3.  Enterprise Environmental Factors
•  Include organizaQon’s culture, infrastructure, personnel
administraQon, and marketplace condiQons
4.  Organiza%onal Process Assets
•  Include policies and procedures, and historical informaQon and
lessons learned knowledge base

Tools and
techniques
1.  Expert Judgment
•  refers to input received from knowledgeable and
experienced parQes. ExperQse may be provided by
any group or person with specialized educaQon,
knowledge, skill, experience, or training in developing
scope management plans.
2.  Mee%ngs
•  a\endees at these meeQngs may include the project
manager, the project sponsor, selected project team
members, selected stakeholders, anyone with
responsibility for any of the scope management
processes, and others as needed.

Outputs
1.  Scope Management Plan: the components of a scope management plan
include:
•  Process for preparing a detailed project scope statement;
•  Process that enables the creaQon 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.
2.  Requirements Management Plan: components of the requirements
management plan can include:
•  How requirements acQviQes will be planned, tracked, and reported;
•  ConfiguraQon management acQviQes; Requirements prioriQzaQon process;
•  Product metrics that will be used and the raQonale for using them; and
•  Traceability structure to reflect which requirement a\ributes will be captured
on the traceability matrix.
Collect requirement
•  The process of defining and documenQng all
Stakeholders’ needs to meet the project objecQves.
This process is criQcal to project success.

Collect requirement
-‐ Inputs
1.  Scope Management Plan: provides clarity as to how project
teams will determine which type of requirements need to be
collected for the project.
2.  Requirements Management Plan: provides the processes to
define and document the stakeholder needs.
3.  Stakeholder Management Plan: is used to understand
stakeholder communicaQon requirements and the level of
stakeholder engagement in order to assess and adapt to the
level of stakeholder parQcipaQon in requirements acQviQes.
4.  Project Charter: is used to provide the high-‐level descripQon
of the product, service, or result of the project so that
detailed requirements can be developed.
5.  Stakeholder Register: is used to idenQfy stakeholders who
can provide informaQon on the requirements.

Collect requirement
-‐Tools and techniques
1. 
(1/2)
Interview: Project manager/ team sits down with stakeholders one-‐
on-‐one to get them to explain exactly what they need so that you can be
sure your project can meet its goals.
2.  Focus Group: Prequalified stakeholders and subject ma\er experts. A
facilitator to guide the conversaQon. InteracQve discussions.
3.  Facilitated Workshops: Bring key -‐ cross funcQonal stakeholders,
reconciling differences, build trust, improve communicaQon, increase
stakeholder consensus.
4.  Group Crea%vity Techniques: Brainstorming, Nominal Group
Technique, Mind Map, Delphi Technique, Affinity Diagram.
5.  Group Decision-‐Making techniques: Unanimity, majority,
plurality and dictatorship.
6.  Ques%onnaires and Surveys: Use a quesQonnaire and/or survey
to get requirements from a bigger group of users, customers, or
stakeholders.

Collect requirement
-‐Tools and techniques
7. 
(2/2)
Observa%ons: observes an end user performing the tasks to be
analyzed in the end user’s own environment
8.  Prototypes: are models of the product that you’re going to build that
let your stakeholders get a be\er idea to elicit requirements more
effecQvely
9.  Benchmarking: involves comparing actual or planned pracQces, such
as processes and operaQons, to those of comparable organizaQons to
idenQfy best pracQces, generate ideas for improvement, and provide a
basis for measuring performance
10.  Context Diagrams: visually depict the product scope by showing a
business system (process, equipment, computer system, etc.), and how
people and other systems (actors) interact with it
11.  Document Analysis: is used to elicit requirements by analyzing
exisQng documentaQon and idenQfying informaQon relevant to the
requirements.

Collect requirement
-‐Outputs
1.  Requirements Documenta%on: describes how individual
requirements meet the business need for the project:
–  Business requirements
–  Stakeholder requirements
–  SoluQon requirements
–  FuncQonal and nonfuncQonal requirements
–  Technology and standard compliance requirements
–  Support and training requirements
–  Quality requirements
–  Project requirements
–  TransiQon requirements
–  Requirements assumpQons, dependencies, and constraints.
2.  Requirements Traceability Matrix: shows the relaQonship
between requirements and business objecQves. A requirement
that does not map back to an objecQve is deemed as out of scope
and must be removed from the list of requirements.

Define scope
•  The process of developing a detailed descripQon 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.

Inputs
1.  Scope Management Plan
•  Output of the Plan Scope Management process
2.  Project Charter
•  Output of the Develop Project Charter process
3.  Requirements Documenta%on
•  Output of the Collect Requirement process
•  OrganizaQonal process assets can influence how scope is
defined. Examples include, but are not limited to: policies,
procedures, and templates for a project scope statement;
project files from previous projects; and lessons learned
from previous phases or projects.

Tools and
techniques
1.  Expert Judgment
•  from many sources: other units within the organizaQon; consultants;
stakeholders, including customers or sponsors; professional and
technical associaQons; industry groups; and SMEs.
2.  Product Analysis
•  for projects that have a product as a deliverable, product analysis
includes techniques such as product breakdown, systems analysis,
requirements analysis, systems engineering, value engineering, and
value analysis.
3.  Alterna%ves Genera%on
•  is a technique used to develop as many potenQal opQons as possible in
order to idenQfy different approaches to execute and perform the
work of the project
4.  Facilitated Workshops
•  The parQcipaQon of key players with a variety of expectaQons and/or
fields of experQse helps to reach a cross-‐funcQonal and common
understanding of the project objecQves and its limits.

Outputs
1.  Project Scope Statement
•  The detailed project scope statement, either
directly, or by reference to other documents,
includes the following: product scope descripQon,
acceptance criteria, deliverables, project
exclusion, constraints, assumpQons
2.  Project Documents Updates

Project cha\er vs.
project scope statement
Ins9tute, Inc. All Rights Reserved. Table 5-‐1 Page 124.

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

Inputs
1.  Scope Management Plan: output of the Plan Scope
Management process
2.  Project Scope Statement: output of the Define Scope process
3.  Requirements Documenta%on: output of the Collect
Requirement process
4.  Enterprise Environmental Factors: industry-‐specific WBS
standards, relevant to the nature of the project, may serve as
external reference sources for creaQon of the WBS. For example,
engineering projects may reference ISO/IEC 15288 on Systems
Engineering -‐ System Life Cycle Processes [6], to create a WBS for
a new project.
5.  Organiza%onal Process Assets: such as policies, procedures,
and templates for the WBS; project files from previous projects;
and lessons learned from previous projects.

Tools and
techniques
1.  Decomposi%on: is the subdivision of project deliverables into
smaller, more manageable components unQl the work and
deliverables are defined to the work package level.
•  Rolling wave planning: decomposiQon of some deliverables
can be waited unQl uncertainty is clarified.
•  Team buy-‐in: is the most valuable result of creaQng a WBS.
•  80 hour rule (rule of thumb or heurisQc): work package
should take approximately 80 hours worth of effort to
complete.
2. Expert judgment: is onen used to analyze the informaQon
needed to decompose the project deliverables down
into smaller component parts in order to create an effecQve WBS.

WBS decomposed
through work packages

WBS Organized
by Phase
WBS with
major deliverables
Outputs
1.  Scope Baseline: is the approved version of a
scope statement, work breakdown structure
(WBS), and its associated WBS dicQonary, that
can be changed only through formal change
control procedures and is used as a basis for
comparison.
2.  Project Document updates: the creaQon of
the WBS may result in necessary revisions to
certain project documents.

Validate scope
•  The process of formalizing acceptance of the completed
project deliverables. The key benefit of this process is that it
brings objecQvity to the acceptance process and increases the
chance of final product, service, or result acceptance by
validaQng each deliverable.
Inputs
•  contains the scope management plan and the scope baseline.
•  output of the Collect Requirement process.
3.  Requirements Traceability Matrix
4.  Verified Deliverables
•  are project deliverables that are completed and checked for
correctness through the Control Quality process.
5.  Work Performance Data
•  include the degree of compliance with requirements, number of
nonconformiQes, severity of the nonconformiQes, or the
number of validaQon cycles performed in a period of Qme.

Tools and
techniques
1.  Inspec%on
•  includes acQviQes such as measuring, examining, and
validaQng to determine whether work and
deliverables meet requirements and product
acceptance criteria. InspecQons are someQmes called
reviews, product reviews, audits, and walkthroughs.
2.  Group Decision-‐Making Techniques
•  are used to reach a conclusion when the validaQon is
performed by the project team and other
stakeholders. The techniques are unanimity, majority,
plurality and dictatorship.

Outputs
1.  Accepted Deliverables
•  deliverables that meet the acceptance criteria are formally
signed off and approved by the customer or sponsor.
2.  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.
3.  Work Performance Informa%on
•  includes informaQon about project progress, such as which
deliverables have started, their progress, which deliverables
have finished, or which have been accepted. This informaQon is
documented and communicated to stakeholders at the Project
CommunicaQon Management.
Deliverables vs.
Accepted Deliverable
Verified Accepted
Deliverables
deliverables deliverables
Direct and
Manage Project
Control Validate Close
ExecuQon Quality Scope Project
VerificaQon Acceptance
29
Copyright@STEVBROS STEVBROS -‐ Global PMI R.E.P
Control scope
•  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 avoid scope
creep (details of scope creep at slide 34)
Inputs
•  the following informaQon from the project management plan is used to
control scope: scope baseline; scope management plan; change management
plan; configuraQon management plan; and requirements management plan.
3.  Requirements Traceability Matrix
4.  Work Performance Data
•  include the number of change requests received, the number of requests
accepted or the number of deliverables completed, etc.
•  such as exisQng formal and informal scope, control-‐related policies,
procedures, guidelines; and monitoring and reporQng methods and templates
to be used.


Tools and
techniques
1.  Variance Analysis:
–  is a technique for determining the cause and
degree of difference between the baseline and
actual performance. Important aspects of project
scope control include determining the cause and
degree of variance relaQve to the scope baseline
and deciding whether correcQve or prevenQve
acQon is required.

Outputs
1.  Work Performance Informa%on
•  includes correlated and contextualized informaQon on how the
project scope is performing compared to the scope baseline. It
can include the categories of the changes received, the
idenQfied scope variances and their causes, how they impact
schedule or cost, and the forecast of the future scope
performance
2.  Change Requests
•  analysis of scope performance can result in a change request to
the scope baseline or other components of the project
management plan. Change requests can include prevenQve or
correcQve acQons, defect repairs, or enhancement requests
3.  Project Management Plan Updates
5.  Organiza%onal Process Assets Updates
Scope creep
•  Also called requirement creep, refers to uncontrolled changes or conQnuous
growth in a project’ scope. This phenomenon can occur when the scope of a
project is not properly defined, documented, or controlled. It is generally
considered a negaQve occurrence, and therefore should be avoided.
•  Scope creep can be a result of:
–  disingenuous customer with a determined "value for free" policy
–  poor change control
–  lack of proper iniQal idenQficaQon of what is required to bring about the project objecQves
–  Weak project manager or execuQve sponsor
–  Poor communicaQon between parQes
•  Scope creep is a risk in most projects. Most megaprojects fall vicQm to scope
creep. Scope creep onen results in cost overrun. A value for free strategy is
difficult to counteract and remains a difficult challenge for even the most
experienced project managers.

Summary
•  The relaQon among deliverables, validated
deliverables and accepted deliverables.
•  The relaQon among the following processes:
Direct and Manage Project ExecuQon, Control
Quality, Validate Scope, Close Project.
•  The difference between Requirement Document
and Scope Statement.
•  The important of Requirement Traceability
Matrix in the Validate Scope process.
•  Team buy-‐in, rule of 80 hours, scope creep

QuesQons
for review
•  You did the good job at this chapter. Please
complete quesQons for review before moving
to next chapter.

Chapter 3: Project Scope Management: Stevbros Training & Consultancy WWW - Stevbros.edu - VN

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Chapter 3: Project Scope Management: Stevbros Training & Consultancy WWW - Stevbros.edu - VN

Încărcat de

Drepturi de autor:

Formate disponibile

Chapter

Copyright@STEVBROS Project Management Fundamentals 1

Project scope • Plan Scope • Validate

Copyright@STEVBROS Project Management Fundamentals 2

Copyright@STEVBROS Project Management Fundamentals 3

Copyright@STEVBROS Project Management Fundamentals 4

Copyright@STEVBROS Project Management Fundamentals 5

Copyright@STEVBROS Project Management Fundamentals 6

Copyright@STEVBROS Project Management Fundamentals 8

Copyright@STEVBROS Project Management Fundamentals 9

Copyright@STEVBROS Project Management Fundamentals 10

Copyright@STEVBROS Project Management Fundamentals 11

Copyright@STEVBROS Project Management Fundamentals 12

Copyright@STEVBROS Project Management Fundamentals 13

Copyright@STEVBROS Project Management Fundamentals 14

Copyright@STEVBROS Project Management Fundamentals 16

Copyright@STEVBROS Project Management Fundamentals 17

Copyright@STEVBROS Project Management Fundamentals 18

Copyright@STEVBROS Project Management Fundamentals 19

Copyright@STEVBROS Project Management Fundamentals 20

Copyright@STEVBROS Project Management Fundamentals 21

Copyright@STEVBROS Project Management Fundamentals 24

Copyright@STEVBROS Project Management Fundamentals 26

Copyright@STEVBROS Project Management Fundamentals 27

Copyright@STEVBROS Project Management Fundamentals 31

Copyright@STEVBROS Project Management Fundamentals 32

Copyright@STEVBROS Project Management Fundamentals 34

Copyright@STEVBROS Project Management Fundamentals 35

Copyright@STEVBROS Project Management Fundamentals 36

S-ar putea să vă placă și

Project scope •  Plan Scope •  Validate