about 4.1% of the exam content - about 90 minutes - 14 practice questions
0:00 / --:--
Reading
Scope is the single biggest source of project failure in our line of work. A homeowner thought the roof was
included. A grant officer thought the ramp came with a handrail on both sides. A crew lead "just fixed" a rotted
sill plate nobody budgeted for. Every one of those is a scope problem, and every one of them is preventable with
the practices in this task: collect requirements properly, define scope explicitly, decompose it into work you
can assign and estimate, trace it, and validate it with the customer before you call it done.
A work breakdown structure decomposes the project by deliverable, not by who does the work or by
chronological steps. The 100% rule keeps every child summing exactly to its parent; the 8/80 heuristic keeps
the bottom-level work packages small enough to estimate and assign reliably.
Product scope vs project scope
Two different things, and PMI tests the difference. Product scope is the features and
functions of the thing being delivered: a 36-inch doorway, a zero-threshold shower, a 1:12 ramp slope.
Project scope is the work required to deliver it: permitting, demolition, inspection,
homeowner coordination, closeout documentation. Product scope is measured against requirements; project scope is
measured against the plan. Project scope usually includes work that is not part of the product.
Collecting requirements
Requirements come from stakeholders, and getting them wrong early is the most expensive mistake available.
Techniques you should recognize:
Interviews: one on one, best for sensitive or detailed information (a homeowner's actual mobility limitations)
Focus groups: moderated discussion among a stakeholder class
Facilitated workshops: cross-functional sessions that resolve differences fast; JAD sessions and QFD are examples
Questionnaires and surveys: many respondents, geographically dispersed
Observation (job shadowing): watching real use; catches what people cannot articulate, such as how someone actually transfers from a wheelchair
Prototypes and mock-ups: a taped-out bathroom floor plan, a cardboard grab bar mock-up; produce feedback far better than a drawing
Requirements get recorded in requirements documentation and classified: business requirements,
stakeholder requirements, solution requirements (functional and non-functional), transition and readiness requirements, project
requirements, and quality requirements. A good requirement is unambiguous, testable, traceable, consistent, and
accepted by stakeholders. "The bathroom should be accessible" fails that test. "Clear floor space of at least 30
by 48 inches at the lavatory, per TAS" passes it.
Key points
The requirements traceability matrix links each requirement forward to design, build, test, and acceptance, and backward to the business need it satisfies
Traceability is how you prove a requirement was delivered, and how you spot requirements nobody asked for
Unresolved competing requirements are decided by prioritization with stakeholders, not by the PM picking a favorite
Defining scope and the scope baseline
The project scope statement describes the deliverables, acceptance criteria, exclusions,
assumptions, and constraints. Exclusions matter as much as inclusions. Writing "roof replacement is
excluded; roof is assumed watertight at start" prevents a fight three weeks in.
The work breakdown structure (WBS) decomposes the total scope into a hierarchy of
deliverables. The lowest level is a work package: small enough to estimate and assign
reliably. Two rules to remember. The 100% rule: the WBS contains all the work of the project and
nothing more; child elements roll up to exactly their parent. The 8/80 heuristic: work packages
typically land between 8 and 80 hours, though this is guidance, not law. A WBS is decomposed by deliverable, not
by who does the work and not by chronological steps; an organization chart is not a WBS.
The WBS dictionary gives each element its detail: description, responsible party, acceptance
criteria, resources, cost estimate. Together, scope statement + WBS + WBS dictionary = the scope
baseline, a component of the project management plan changed only through change control.
Hierarchical decomposition of scope down to work packages
Yes
WBS dictionary
Detail for each WBS element: owner, criteria, estimates
Yes
Requirements documentation
All collected and classified requirements
No, project document
Traceability matrix
Links requirements to deliverables and tests
No, project document
Product backlog
Ordered list of features and stories (adaptive)
No, adaptive artifact
Scope in adaptive work: backlog, stories, DoR and DoD
Adaptive projects hold scope in a product backlog owned and ordered by the product
owner. Items are usually written as user stories ("As a case manager, I want to flag a
home as storm-damaged so that repair crews can be dispatched first") with acceptance criteria
that say specifically what must be true for that story to be accepted.
Backlog refinement (grooming) is the ongoing activity where the team and product owner clarify,
split, estimate, and reorder items, an ongoing activity that takes a steady share of team capacity. Items are estimated
relatively, in story points, often using planning poker; relative sizing is faster and more
reliable than absolute hour estimates for uncertain work.
Two definitions get confused constantly and are prime exam material:
Definition of ready (DoR): the team's agreed checklist for whether a backlog item is
well enough understood to be pulled into an iteration. It is a common team working agreement, not a Scrum
Guide element.
Definition of done (DoD): the team's standard, applying to every item, for what
complete means: coded, tested, documented, integrated, inspected.
Acceptance criteria: specific to one item, describing what that particular story
or deliverable must do to be accepted.
So: DoD is universal and team-owned; acceptance criteria are item-specific and typically product-owner or
customer-owned. A story can meet its acceptance criteria and still not be done if the team's DoD requires
documentation nobody wrote.
Scope creep vs gold plating
Scope creep is uncontrolled expansion driven by outside requests that were never approved; the homeowner keeps adding "one more thing" and nobody logs it. Gold plating is the team
adding unrequested extras on its own initiative; the crew installs a nicer faucet than specified because they
had one on the truck. Both are uncontrolled scope change. The distinction on the exam is the source:
creep comes from outside the team, gold plating comes from inside. Both are prevented the same way: a clear
baseline plus disciplined change control, and both are wrong even when well intentioned.
Prioritization and MoSCoW
When there is more want than budget, prioritize explicitly with stakeholders rather than deciding silently.
MoSCoW is a common technique.
Category
Meaning
GCHS accessibility retrofit example
Must have
Non-negotiable; without it the delivery fails
Code-compliant ramp slope and landing
Should have
Important but not vital; painful to omit
Second handrail; lever door hardware
Could have
Desirable if time and money allow
Covered porch roof over the landing
Won't have (this time)
Explicitly out of scope for this release
Kitchen counter lowering, deferred to a later grant
Other prioritization tools worth knowing: Kano analysis (basic, performance, delighter
features), weighted shortest job first (WSJF), paired comparison, and simple 100-point
allocation. The point of all of them is the same: make the trade-off visible and shared.
Validating and controlling scope
Two processes people mix up. Validate scope is the customer or sponsor formally
accepting deliverables; its output is accepted deliverables and, where rejected, change requests.
Control quality is the internal check that the deliverable meets requirements; its output is
verified deliverables. Quality control normally comes first: you verify internally, then take it to the customer
for acceptance. Handing an uninspected deliverable to a homeowner for sign-off is the sequence error PMI likes to
test.
Control scope is monitoring status and managing changes to the baseline, using variance
analysis to see where actual scope diverges from approved scope. In adaptive work the equivalent is the iteration
review or demo, where the product owner accepts or rejects completed items and unfinished work returns to the
backlog rather than being carried as partial credit.
Common trap
A crew finds unforeseen termite damage behind a wall during an accessibility retrofit. The tempting answers
are "fix it, it is the right thing to do" or "stop the whole job." The PMI answer is: it is new work not in the
baseline, so document the finding, assess impact on scope, cost, schedule and safety, and submit a change
request. If it creates an immediate safety hazard you make the area safe first (protecting people never waits for a CCB), but the repair itself still goes through change control.
Practice Questions
1. Which of the following BEST describes the difference between product scope and project scope?
Product scope applies only to adaptive projects, and project scope applies only to predictive projects
Product scope is the work performed; project scope is the features delivered
Product scope is the features and functions; project scope is the work to deliver them
They are the same thing described from different perspectives
Answer: c. Product scope is the features and functions of the deliverable, measured against requirements; project scope is all the work required to deliver it, measured against the plan. The tempting distractor simply reverses the two definitions, calling the work product scope and the features project scope.
2. The scope baseline consists of which three items?
Charter, scope statement, and requirements documentation
WBS, schedule, and cost estimate
Requirements documentation, WBS, and traceability matrix
Project scope statement, WBS, and WBS dictionary
Answer: d. Scope statement, WBS and WBS dictionary form the approved scope baseline. Requirements documentation and the traceability matrix are project documents that feed the baseline but are not part of it.
3. A crew installs a higher-grade faucet than specified because they believe the homeowner will appreciate it. This is an example of:
Gold plating
Value engineering
Progressive elaboration
Scope creep
Answer: a. Gold plating is the team adding unrequested extras on its own initiative; the source is inside the project. Scope creep comes from outside the team through unapproved external requests; both are uncontrolled scope change and both are unacceptable.
4. A homeowner repeatedly asks the crew for small additions and the crew accommodates them without documentation. This is:
Acceptable customer service
Progressive elaboration
Gold plating
Scope creep
Answer: d. Uncontrolled expansion driven by unapproved external requests is scope creep. Gold plating would be the team volunteering extras; progressive elaboration is the legitimate refinement of detail within approved scope.
5. The 100% rule of the WBS states that:
The WBS includes all project work and nothing else, with children summing to their parent
Each work package must be 100 hours or less
The WBS must be 100% complete before execution begins
100% of the team members and sponsors must formally sign off on the WBS before it is baselined
Answer: a. The 100% rule means the WBS captures all of the project scope and nothing beyond it, with child elements summing to their parent. The 8/80 heuristic covers work package sizing, and no rule requires team-wide unanimity.
6. Which of the following is NOT a valid way to decompose a WBS?
By major deliverable
By project phase
By subproject
By the organizational chart of who reports to whom
Answer: d. A WBS is deliverable-oriented and may be organized by deliverable, phase, or subproject. An organization chart shows reporting relationships; that is an OBS, and confusing the two is a classic error.
7. Two funders request conflicting requirements for a rehab program's reporting format. What should the project manager do?
Ignore both requests and use the standard GCHS reporting format for every funder and program
Ask the board to decide immediately without stakeholder input
Pick whichever funder's requirement seems more important
Facilitate prioritization among the stakeholders rather than deciding alone
Answer: d. Unresolved competing requirements are decided through stakeholder prioritization, not by the PM picking a favorite. Ignoring the conflict or handing it to the board without the stakeholders involved skips that discipline.
8. A project manager wants to see how a wheelchair user actually transfers onto a shower bench, catching details the homeowner could not describe in words. Which requirements collection technique is this?
Interview
Focus group
Observation (job shadowing)
Questionnaire
Answer: c. Observation catches physical, hard-to-articulate needs by watching real use, which interviews and questionnaires rely on people to put into words. A focus group is a moderated group discussion, not direct observation of behavior.
9. A user story meets its acceptance criteria, but the team's definition of done requires documentation that was never written. What is the status of the story?
Not done, since the definition of done applies to every item
Done, since documentation is optional
The story should be removed from the backlog entirely
Done, since every acceptance criterion written for the story was met in testing
Answer: a. Definition of done is universal and team-owned, so an item is not done until it is satisfied, even if item-specific acceptance criteria were met. Treating documentation as optional or removing the story confuses two distinct, non-interchangeable standards.
10. A crew completes a ramp and wants to schedule the homeowner's formal acceptance walkthrough. What should happen FIRST?
Ask the homeowner to inspect it herself for defects and report them before the formal walkthrough
Schedule the homeowner walkthrough immediately
Perform internal quality control checks before taking it to the homeowner
Skip inspection since the crew is experienced
Answer: c. Control quality verifies the deliverable internally before validate scope brings it to the customer for formal acceptance; reversing that order is the sequence error PMI likes to test. Skipping inspection or handing an unverified deliverable to the homeowner both risk a rejected acceptance.
11. A GCHS accessibility retrofit has more homeowner requests than budget allows. Using MoSCoW, a covered porch roof over the ramp landing, desirable but not essential, would be classified as:
Should have
Could have
Won't have
Must have
Answer: b. Could have items are desirable if time and money allow, which fits a nice-to-have porch roof exactly. Must and should describe non-negotiable or painful-to-omit items, and won't have means explicitly excluded this round, neither of which fits a nice extra.
12. During demolition, a crew discovers active termite damage that does not create an immediate safety hazard. What should the project manager do?
Stop the entire project until a full structural inspection of the house is complete
Document the finding, assess its impact, and submit a change request
Repair it immediately since it is clearly necessary
Ignore it since it was not in the original scope
Answer: b. New work discovered outside the baseline still goes through change control, assessed for its full impact, even when it is clearly the right thing to eventually do. Fixing it unilaterally or ignoring it both bypass that assessment, and a full project stop is not warranted absent an immediate hazard.
13. A caseworker adds an unrequested feature to the intake software because she believes users will like it, without telling the product owner. This is:
A validated requirement
Gold plating
Scope creep
Value engineering
Answer: b. The addition comes from inside the team on its own initiative, which is gold plating, not scope creep from an outside request. It was never validated against requirements, so it is not a validated requirement, and value engineering is a deliberate, approved cost-value trade-off, not a unilateral add.
14. Which document links each requirement forward to design, build, test, and acceptance, and backward to the business need it satisfies?
Requirements traceability matrix
Project scope statement
Product backlog
WBS dictionary
Answer: a. The traceability matrix is specifically built to link requirements both forward through delivery and backward to the need that justified them. The WBS dictionary details work packages, the scope statement describes deliverables and exclusions, and neither performs that two-way linking.
Glossary
Product scope vs project scope
Product scope is the features and functions of the deliverable; project scope is all the work required to produce it.
Requirements traceability matrix
A document linking each requirement forward to design, build, test, and acceptance, and backward to the business need it satisfies.
Work breakdown structure (WBS)
A hierarchical decomposition of total project scope into deliverables and work packages, organized by deliverable, not by team or chronology.
Work package
The lowest level of the WBS, small enough to estimate and assign reliably; typically 8 to 80 hours under the 8/80 heuristic.
Scope baseline
The project scope statement, WBS, and WBS dictionary together, approved and changed only through change control.
Definition of ready / definition of done
DoR is the team's checklist for whether a backlog item is understood enough to start; DoD is the team's universal standard for what complete means for every item.
Scope creep vs gold plating
Scope creep is uncontrolled expansion from outside requests; gold plating is unrequested extras the team adds on its own initiative.
MoSCoW
A prioritization technique sorting items into Must have, Should have, Could have, and Won't have (this time).