Since you’re in the process of creating these
plans for the other knowledge areas at the same
time as this one, there’s a good chance that you
can use some of the same ideas in this plan that
you’ve uncovered in the process of creating your
Time Management plan, your Cost Management
plan, or any of the other subsidiary plans.
Project charter
The charter
already includes a
high-level
description of the
scope of the
project. So it’s a
good place to
start.
EEFs (Enterprise
environmental factors)
Your company’s culture and accepted
practices will have a big impact on
the way you manage scope on this
project too.
OPAs (Organizational
process assets)
The Plan Scope Management process is
where you lay out your approach to
figuring out what work you’ll do and
what’s out of scope.
Product Scope
Product scope means the features and functions
of the product or service that you and your
team are building.
The product scope is all about the final
product—its features, components, pieces.
Project scope
Project scope is all of the work that
needs to be done to make the
product.
Scope creep
Scope creep means
uncontrolled changes
that cause the team to
do extra work.
Expert judgment
Meetings
You might need to hold a
meeting with some of the
project’s stakeholders to
agree on an approach.
Plan Scope Management
Here’s where you write down the subsidiary plan
for the project management plan that we talked
about in the last chapter. You plan out all of the
work you’ll do to define your scope, make sure the
team is planning to do the right work, and control
it.
Requirements
Management plan
Here’s where you’ll find a description of the
approach the team will take to planning,
tracking, and reporting on requirements. You’ll
use this document to describe the prioritization
process for requirements, and how you’ll build
a traceability matrix for your requirements as
well.
Scope Management plan
Here’s where you write down the
subsidiary plan for the Project
Management plan that we talked about in
Chapter 4. You plan out all of the work
you’ll do to define your scope, with the
right work planned for the team, and
control it.
Collect Requirements
In this process, you find out all of the
stakeholders’ needs and write them down so
that you know what to build and your
requirements can be measured and tracked.
Define
Scope
Here’s where you write down a
detailed description of the work
you’ll do and what you’ll produce.
Create
WBS
The work breakdown structure (WBS)
organizes all of your team’s work into
work packages—or discrete pieces of
work that team members do—so that
you can keep the momentum of the
project going from the start.
Control
Scope
We already know how important it is to control
changes on your project. When scope changes
aren’t controlled, it leads to the most frustrating
sort of project problems. Luckily, you already know
about change control, and now you can use it to
manage your project’s scope.
Validate
Scope
Once the work is complete, you need to make sure
that what you’re delivering matches what you wrote
down in the project scope statement. That way, the
team never delivers the wrong product to the
customer.