Project Scope Management Terms Flashcards
8/80 Rule
A planning heuristic for creating the WBS. This rule states that the work package in a WBS must take no more than 80 hours of labor to create and no fewer than 8 hours of labor to create.
Active observation
The observer interacts with the worker to
ask questions and understand each step
of the work being completed. In some
instances, the observer could serve as an
assistant in doing the work.
Affinity diagrams
When stakeholders create a large
number of ideas, you can use an affinity
diagram to cluster similar ideas together
for further analysis
Alternatives generation
A scope definition process of finding alternative solutions for the project customer while considering the customer’s satisfaction, the cost of the solution, and how the customer may use the product in operations.
Autocratic
A decision method where only one
individual makes the decision for the
group.
Brainstorming
This approach encourages participants to generate as many ideas as possible about the project requirements. No idea is judged or dismissed during the brainstorming session
Change control system (CCS)
Documented in the scope management
plan, this system defines how changes to
the project scope are managed and
controlled
Change management plan
This subsidiary plan defines how
changes will be allowed and managed
within the project.
Code of accounts
A numbering system for each item in the WBS. The PMBOK is a good example of a code of accounts, as each chapter and its subheadings follow a logical numbering scheme. For example, PMBOK 5.3.3.2 identifies an exact paragraph in the PMBOK.
Configuration management plan
This subsidiary plan defines how
changes to the features and functions of
the project deliverables will be monitored
and controlled within the project.
Context diagram
These diagrams show the relationship between elements of an environment. For example, a context diagram would illustrate the networks, servers, workstations, and people that interact with the elements of the environment.
Focus groups
A moderator-led requirements collection
method to elicit requirements from
stakeholders
Functional analysis
This is the study of the functions within a
system, project, or, what’s more likely in
the project scope statement, the product
the project will be creating. Functional
analysis studies the goals of the product,
how the product will be used, and the
expectations the customer has of the
product once it leaves the project and
moves into operations. Functional
analysis may also consider the cost of
the product in operations, which is known
as life-cycle costing.
Funding limit
Most projects have a determined budget in relation to the project scope. There may be a qualifier on this budget, such as plus or minus 10 percent based on the type of cost estimate created.
Interviews
A requirements collection method used to
elicit requirements from stakeholders in a
one-on-one conversation.
Majority
A group decision method where more
than 50 percent of the group must be in
agreement
Mind mapping
This approach maps ideas to show the relationship among requirements and the differences between requirements. The map can be reviewed to identify new solutions or to rank the identified requirements.
Nominal group technique
As with brainstorming, participants are
encouraged to generate as many ideas
as possible, but the suggested ideas are
ranked by a voting process.
Passive observation
The observer records information about
the work being completed without
interrupting the process; sometimes
called the invisible observer.
Plurality
A group-decision method where the
largest part of the group makes the
decision when it’s less than 50 percent of
the total. (Consider three or four factions
within the stakeholders.)
Product acceptance criteria
This project scope statement component works with the project requirements, but focuses specifically on the product and what the conditions and processes are for formal acceptance of the product
Product breakdown
A scope definition technique that breaks
down a product into a hierarchical
structure, much like a WBS breaks down
a project scope.
Product scope description
This is a narrative description of what the
project is creating as a deliverable for the
project customer.
Product scope
Defines the product or service that will
come about as a result of completing the
project. It defines the features and
functions that characterize the product
Project assumptions
A project assumption is a factor in the
planning process that is held to be true
but not proven to be true.
Project boundaries
A project boundary clearly states what is included with the project and what’s excluded from the project. This helps to eliminate assumptions between the project management team and the project customer.
Project constraints
A constraint is anything that limits the project manager’s options. Consider a predetermined budget, deadline, resources, or materials the project manager must use within the project— these are all examples of project constraints.
Project objectives
These are the measurable goals that determine a project’s acceptability to the project customer and the overall success of the project. Objectives often include the cost, schedule, technical requirements, and quality demands.
Project requirements
These are the demands set by the customer, regulations, or the performing organization that must exist for the project deliverables to be acceptable. Requirements are often prioritized in a number of ways, from “must have” to “should have” to “would like to have
Project scope
This defines all of the work, and only the
required work, to complete the project
objectives.
Project scope management plan
This project management subsidiary plan controls how the scope will be defined, how the project scope statement will be created, how the WBS will be created, how scope validation will proceed, and how the project scope will be controlled throughout the project
Requirements documentation
This documentation of what the
stakeholders expected in the project
defines all of the requirements that must
be present for the work to be accepted by
the stakeholders.
Requirements management plan
This subsidiary plan defines how changes to the project requirements will be permitted, how requirements will be tracked, and how changes to the requirements will be approved
Requirements traceability matrix (RTM)
This is a table that maps the
requirements throughout the project all
the way to their completion.
Schedule milestones
The project customer may have specific
dates when phases of the project should
be completed. These milestones are
often treated as project constraints
Scope creep
Undocumented, unapproved changes to
the project scope.
Scope validation
The formal inspection of the project
deliverables, which leads to project
acceptance.
