Área de Conocimiento 02, Gestión de Alcance

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

2. Overview
Ini%a%ng
process
group
Planning
process
group
Execu%ng
process
group
Monitoring
&
controlling
process
group
Closing
process
group
Project
scope
management
• Plan
Scope
Management
• Collect
Requirements
• Define
Scope
• Create
WBS
• Validate
Scope
• Control
Scope
Copyright@STEVBROS
Project
Management
Fundamentals
2

3. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
3

4. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
4
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.

5. 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
Copyright@STEVBROS
Project
Management
Fundamentals
5

6. 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
• aendees
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.
Copyright@STEVBROS
Project
Management
Fundamentals
6

7. 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
aributes
will
be
captured
on
the
traceability
matrix.
Copyright@STEVBROS
Project
Management
Fundamentals
7

8. Collect
requirement
• The
process
of
defining
and
documenQng
all
Stakeholders’
needs
to
meet
the
project
objecQves.
This
process
is
criQcal
to
project
success.
Copyright@STEVBROS
Project
Management
Fundamentals
8
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐2
Page
120.

9. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
9

10. Collect
requirement
-­‐Tools
and
techniques
(1/2)
1. 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
maer
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.
Copyright@STEVBROS
Project
Management
Fundamentals
10

11. Collect
requirement
-­‐Tools
and
techniques
(2/2)
7. 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
beer
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.
Copyright@STEVBROS
Project
Management
Fundamentals
11

12. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
12

13. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
13
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐7
Page
120.

14. 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
4. Organiza%onal
Process
Assets
• 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.
Copyright@STEVBROS
Project
Management
Fundamentals
14

15. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
15

16. 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
Copyright@STEVBROS
Project
Management
Fundamentals
16

17. Project
chaer
vs.
project
scope
statement
Copyright@STEVBROS
Project
Management
Fundamentals
17
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Table
5-­‐1
Page
124.

18. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
18
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐9
Page
125.

19. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
19

20. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
20

21. WBS
decomposed
through
work
packages
Copyright@STEVBROS
Project
Management
Fundamentals
21
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐11
Page
129.

22. WBS
Organized
by
Phase
Copyright@STEVBROS
Project
Management
Fundamentals
22
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐12
Page
130.

23. WBS
with
major
deliverables
Copyright@STEVBROS
Project
Management
Fundamentals
23
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐13
Page
130.

24. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
24

25. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
25
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐14
Page
133.

26. Inputs
1. Project
Management
Plan
• contains
the
scope
management
plan
and
the
scope
baseline.
2. Requirements
Documenta%on
• output
of
the
Collect
Requirement
process.
3. Requirements
Traceability
Matrix
• output
of
the
Collect
Requirement
process.
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.
Copyright@STEVBROS
Project
Management
Fundamentals
26

27. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
27

28. 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.
4. Project
Documents
Updates
Copyright@STEVBROS
Project
Management
Fundamentals
28

29. Deliverables
vs.
Accepted
Deliverable
Deliverables
Verified
deliverables
Accepted
deliverables
Copyright@STEVBROS
STEVBROS
-­‐
Global
PMI
R.E.P
29
Close
Project
Validate
Scope
Control
Quality
Direct
and
Manage
Project
ExecuQon
VerificaQon
Acceptance

30. 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)
Copyright@STEVBROS
Project
Management
Fundamentals
30
A
Guide
to
the
Project
Management
Body
of
Knowledge,
FiBh
Edi9on
(PMBOK®
Guide)
©2013
Project
Management
Ins9tute,
Inc.
All
Rights
Reserved.
Figure
5-­‐16
Page
136.

31. Inputs
1. Project
Management
Plan
• 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.
2. Requirements
Documenta%on
• output
of
the
Collect
Requirement
process.
3. Requirements
Traceability
Matrix
• output
of
the
Collect
Requirement
process.
4. Work
Performance
Data
• include
the
number
of
change
requests
received,
the
number
of
requests
accepted
or
the
number
of
deliverables
completed,
etc.
5. Organiza%onal
Process
Assets
• such
as
exisQng
formal
and
informal
scope,
control-­‐related
policies,
procedures,
guidelines;
and
monitoring
and
reporQng
methods
and
templates
to
be
used.
Copyright@STEVBROS
Project
Management
Fundamentals
31

32. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
32

33. 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
4. Project
Documents
Updates
5. Organiza%onal
Process
Assets
Updates
Copyright@STEVBROS
Project
Management
Fundamentals
33

34. 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.
Copyright@STEVBROS
Project
Management
Fundamentals
34

35. 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
Copyright@STEVBROS
Project
Management
Fundamentals
35

36. QuesQons
for
review
Copyright@STEVBROS
Project
Management
Fundamentals
36
• You
did
the
good
job
at
this
chapter.
Please
complete
quesQons
for
review
before
moving
to
next
chapter.