live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Learn how to define, control, and protect project scope in predictive environments.
🎥 Watch PMP Exam Prep video series: https://www.youtube.com/playlist?list=PLaZjaTadwi1sDBAXtUd6JI5_FUsIJjpAT
How do you ensure your project includes all the work required — and only the work required — to deliver success? In this video, we’ll explore Waterfall Project Scope Management, covering how scope is defined, baselined, validated, and controlled throughout a predictive project.
This is the third video in our 15-part Waterfall Review & Question series. You’ll learn how requirements are collected, how the Scope Statement and Work Breakdown Structure (WBS) are developed, and how to manage scope creep and gold plating. Then, test your knowledge with 10 scenario-based practice questions (Questions 21–30) and detailed explanations.
✅ You’ll learn how to:
• Define scope through requirements gathering and stakeholder alignment
• Develop the Scope Statement, WBS, and Scope Baseline
• Control scope changes using the Integrated Change Control process
• Recognize and prevent scope creep and gold plating
• Validate deliverables through the formal acceptance process
By mastering these topics, you’ll strengthen your understanding of predictive scope management — a core area of the PMP® exam and real-world project delivery.
Chapters:
0:00 Project Scope Management Overview
2:52 Question 21
4:55 Question 22
Show More Show Less View Video Transcript
0:00
The topic we'll cover is scope
0:02
management. The processes that ensure
0:04
the project includes all the work
0:06
required and only the work required to
0:09
complete the project successfully. In
0:12
waterfall, scope is defined upfront,
0:14
baselined, and tightly controlled
0:16
throughout the project. This makes scope
0:18
management one of the most critical
0:20
areas because once scope is locked in,
0:22
changes are difficult and costly. Scope
0:25
management begins with collecting
0:27
requirements in waterfall. often
0:29
involves extensive stakeholder
0:31
interviews, workshops, surveys, and
0:33
analysis to capture detailed
0:35
requirements early in the project. The
0:38
exam may test your understanding that
0:40
requirements must be complete,
0:41
measurable, and traceable. From here,
0:44
you'll create the scope statement, which
0:45
clearly defines what is in scope and
0:47
what is out of scope. This document
0:49
becomes the foundation for
0:50
decision-making later when scope
0:52
conflicts or change requests arise. The
0:55
work breakdown structure or WBS is
0:58
another key artifact. The WBS decomposes
1:02
the project scope into smaller, more
1:04
manageable components called work
1:05
packages. On the exam, remember that the
1:08
WBS represents 100% of the project
1:11
scope. Nothing more, nothing less. Each
1:14
work package can then be scheduled,
1:17
costed, and tracked. Once requirements,
1:20
the scope statement and the WBS are
1:22
approved, they form the scope baseline.
1:25
This baseline is part of the overall
1:27
project management plan and it is what
1:29
the PM monitors against during
1:31
execution. Managing scope and waterfall
1:34
is about strict change control. Any
1:36
request to add, modify or remove scope
1:39
must go through the integrated change
1:41
control process and be reviewed by the
1:43
change control board. This prevents
1:45
scope creep which is one of the biggest
1:47
risk in waterfall projects. Also beware
1:50
of gold plating when the team delivers
1:53
more than what's required on the exam.
1:55
Both scope creep and gold plating are
1:58
incorrect practices. Verification of
2:01
scope happens during validate scope
2:03
where deliverables are formally accepted
2:05
by stakeholders against the defined
2:07
requirements. Controlling scope happens
2:09
continuously through control scope where
2:11
the PM monitors work performance,
2:14
compares it against the baseline, and
2:15
addresses variances. For the PMP exam,
2:19
remember that waterfall scope management
2:21
is about precision, documentation, and
2:23
control. You'll need to know how
2:25
requirements are collected, how the WBS
2:28
is created, how the scope baseline is
2:30
protected, and how scope verification
2:33
and control are managed. Now, we'll go
2:36
through 10 practice questions that test
2:38
your knowledge of requirements
2:40
gathering, scope statements, the WBS,
2:43
scope creep, and how scope is validated
2:46
and controlled in waterfall projects.
2:49
Let's get into the first question in
2:51
this topic. Question 21. A predictive IT
2:55
project is in the initiation phase. The
2:58
project manager is developing the scope
2:59
management plan as part of the overall
3:01
project management plan. A senior
3:04
analyst asks if this plan should already
3:06
include a detailed list of deliverables
3:09
and WBS elements for tracking. How
3:12
should the project manager respond? A.
3:15
Yes, because defining detailed scope
3:17
elements early reduces ambiguity during
3:20
execution. B. No. The scope management
3:23
plan defines how scope will be managed,
3:26
not the scope itself. C. Yes, because
3:30
scope must be baseline during initiation
3:32
to ensure traceability. D. No, but the
3:36
WBS dictionary should still be created
3:39
alongside the scope management plan. You
3:41
can pause the video here if you need
3:42
more time to work on the question. The
3:45
correct answer is B. This question tests
3:48
your understanding of scope planning in
3:50
predictive projects, specifically the
3:52
purpose and timing of the scope
3:54
management plan. It's important to
3:56
distinguish between planning how scope
3:58
will be defined, validated, and
4:00
controlled versus actually defining
4:03
scope itself. Choice B is the best
4:05
option because the scope management plan
4:07
outlines how scope will be handled
4:09
throughout the project, including the
4:11
processes for collecting requirements,
4:13
defining scope, validating deliverables,
4:15
and controlling changes. It does not
4:18
contain the actual scope details. Choice
4:20
A is incorrect. While reducing ambiguity
4:23
is important, detailed deliverables and
4:26
WBS elements come later during define
4:29
scope and create WBS, not during scope
4:32
management plan development. Choice C is
4:35
incorrect. The scope baseline is created
4:38
during planning, not initiation and only
4:41
after requirements have been collected
4:42
and scope defined. Choice D is
4:45
incorrect. The WBS dictionary is part of
4:48
the scope baseline. It is not developed
4:50
during scope management plan creation.
4:53
Let's move on to the next question if
4:54
you're ready. Question 22. In a
4:58
predictive project to design a new
4:59
national ID registration platform, the
5:02
project team is preparing to collect
5:04
stakeholder requirements. Several
5:06
stakeholders are unavailable for
5:08
workshops and a few have conflicting
5:10
expectations. A senior systems analyst
5:13
suggests finalizing scope based on
5:15
previous project templates and technical
5:17
specs instead of collecting new inputs.
5:20
What should the project manager do? A.
5:23
Proceed using historical documents to
5:25
define scope since stakeholder input is
5:27
limited. B. Escalate to the sponsor to
5:30
force stakeholder availability for scope
5:32
discussions. C. Use available
5:35
stakeholders and supplement with
5:36
document analysis, surveys, or
5:38
interviews. D. Delay planning until all
5:41
stakeholders are available to ensure
5:43
requirements are fully captured. You can
5:46
pause the video here if you need more
5:48
time to work on the question. The
5:51
correct answer is C. This question tests
5:54
your knowledge of how to collect
5:55
requirements in predictive projects,
5:58
especially when not all stakeholders are
6:00
available. It focuses on using multiple
6:02
data gathering techniques and continuing
6:05
progress without delay while still
6:07
capturing quality inputs.
6:10
Choice C is the best option because PMI
6:13
recommends using techniques such as
6:14
document analysis, surveys, interviews,
6:17
and engaging available stakeholders.
6:19
These methods help bridge gaps in
6:21
availability and still yield quality
6:23
requirements without stalling the
6:25
planning process. Choice A is incorrect.
6:28
Relying only on historical documents and
6:30
technical specs limit stakeholder
6:32
engagement and risks misalignment with
6:34
current project needs. Choice B is
6:37
incorrect. Escalating to the sponsor too
6:39
early is unnecessary. The PM has tools
6:42
to manage the situation proactively
6:44
without invoking hierarchy. Choice D is
6:47
incorrect. Delaying the project for
6:49
perfect stakeholder attendance is
6:51
inefficient. Predictive methods
6:53
encourage progress using structured data
6:55
collection tools. Let's move on to the
6:58
next question if you're ready. Question
7:00
23. While defining scope for a
7:03
predictive public health program, the
7:05
project manager consolidates approved
7:07
requirements and creates a draft project
7:09
scope statement. A government
7:10
stakeholder insists that her
7:12
department's needs were only partially
7:14
addressed and demands that the PM
7:16
incorporate the remaining items
7:17
immediately. What should the project
7:19
manager do? A include the stakeholder's
7:22
remaining needs in the scope statement
7:24
and baseline the full scope. B. Ask the
7:28
stakeholder to submit a change request
7:30
for the additional requirements. C.
7:33
Document the concern, finalize the scope
7:35
statement, and log the new items for
7:37
future projects. D. Facilitate a review
7:40
of the approved requirements to confirm
7:42
alignment and consider next steps. You
7:45
can pause the video here if you need
7:47
more time to work on the question. The
7:49
correct answer is D. This question tests
7:52
your knowledge of the defined scope
7:54
process where the project manager
7:55
translates approved requirements into a
7:57
formal scope statement. It also
7:59
evaluates your ability to handle
8:01
lastminute input while maintaining
8:03
stakeholder engagement in alignment with
8:05
what was already approved. Choice D is
8:08
the best option because it keeps the
8:09
process on track while giving the
8:11
stakeholder a voice. Reviewing the
8:12
approved requirements together helps
8:14
clarify whether there was a
8:15
misunderstanding or misalignment and
8:17
avoids rushing into unauthorized scope
8:19
expansion. Choice A is incorrect,
8:22
including unapproved items at this stage
8:24
risks scope creep and undermines the
8:27
formal process used to build the scope
8:29
baseline. Choice B is incorrect. Jumping
8:32
directly to change control without
8:34
reviewing what's already approved may
8:36
escalate tension and doesn't foster
8:38
collaboration. Choice C is incorrect.
8:40
Finalizing the scope and logging
8:42
concerns without review might dismiss a
8:44
legitimate gap and damage stakeholder
8:46
trust. Let's move on to the next
8:48
question if you're ready. Question 24. A
8:52
predictive project to implement a
8:53
national payroll system is in the
8:55
planning phase. During WBS development,
8:57
a new team member asks if resources and
9:00
timelines should be assigned to each
9:01
work package to support schedule
9:03
creation. What should the project
9:05
manager do? A. Confirm that resources
9:08
and duration estimates must be included
9:10
in the WBS to ensure bottom-up
9:12
scheduling. B. Explain that the WBS
9:16
defines deliverables and resource
9:18
planning is a separate process. C. Defer
9:22
the question until the project schedule
9:24
is developed where these details will be
9:26
captured. D. Add only highlevel duration
9:29
estimates to the WBS to guide resource
9:32
allocation decisions. You can pause the
9:34
video here if you need more time to work
9:36
on the question. The correct answer is
9:39
B. This question tests your
9:41
understanding of the work breakdown
9:43
structure WBS and how it fits into
9:46
predictive planning. The WBS defines
9:48
what needs to be delivered. It is not
9:50
the place to assign resources or
9:52
estimate time. Choice B is the best
9:55
option because the WBS focuses on
9:57
decomposing project deliverables into
9:59
manageable work packages. Resource
10:01
assignments and durations are addressed
10:03
in separate processes during schedule
10:06
and resource planning. Choice A is
10:08
incorrect, including resources and
10:10
durations in the WBS mixes planning
10:13
processes and violates PMI's structured
10:17
approach to decomposition. Choice C is
10:20
incorrect. Deferring the conversation
10:22
misses an opportunity to clarify the
10:24
team's understanding of planning tools.
10:27
Choice D is incorrect. Even high-level
10:30
durations don't belong in the WBS. It
10:32
should remain focused on scope, not time
10:35
or cost estimates. Let's move on to the
10:38
next question if you're ready. Question
10:40
25. In a predictive infrastructure
10:43
project nearing the end of a major
10:45
phase, the project team submits
10:47
completed deliverables to stakeholders.
10:49
One department head refuses to sign off,
10:52
citing minor visual discrepancies that
10:54
do not affect functionality or
10:56
contractual requirements. The project
10:59
manager confirms that all quality
11:01
standards have been met. What should the
11:03
project manager do next? A revise the
11:07
deliverables to satisfy the department
11:08
head and ensure buyin. B. Meet with the
11:12
department head to discuss the concerns
11:14
and try to resolve the issue. C. Proceed
11:17
with validate scope to formally document
11:19
stakeholder acceptance or rejection. D.
11:22
Request a change order to address the
11:24
discrepancies before continuing the
11:26
process. You can pause the video here if
11:29
you need more time to work on the
11:30
question. The correct answer is C. This
11:34
question tests your understanding of the
11:36
validate scope process in a predictive
11:38
environment. Once deliverables are
11:40
completed and quality verified, the
11:42
project manager must seek formal
11:44
acceptance from stakeholders even if
11:47
minor disagreements remain. Toy C is the
11:50
best option because it follows the
11:51
prescribed process. Conduct validate
11:54
scope to formally capture whether
11:56
deliverables are accepted or rejected.
11:58
This ensures transparency, traceability,
12:01
and project governance. Choice A is
12:04
incorrect. Making unapproved changes to
12:06
satisfy individual preferences,
12:08
especially when the deliverable meets
12:10
scope and quality criteria can lead to
12:12
scope creep and set a poor precedent.
12:15
Choice B is incorrect. While discussion
12:18
is important, it should happen within
12:21
the validate scope process to ensure
12:23
proper documentation and formal closure.
12:27
Choice D is incorrect. Initiating a
12:29
change order for cosmetic concerns not
12:32
tied to baseline requirements is
12:34
unnecessary and adds administrative
12:36
burden without value. Let's move on to
12:39
the next question if you're ready.
12:41
Question 26. During a predictive project
12:44
to build a regional operations center,
12:46
the client casually asks the project
12:48
manager to add soundproofing panels to
12:50
the server room, an item not included in
12:53
the original requirements. The PM
12:55
agrees, thinking it's a minor change
12:57
that improves quality and won't affect
12:59
the budget or timeline. What is the most
13:02
appropriate course of action? A. Decline
13:05
the request unless it's submitted
13:06
through the formal change control
13:08
process.
13:09
B. Proceed with the change as it
13:11
enhances quality and has no impact on
13:13
cost or schedule. C. Document the
13:16
client's verbal request and add it to
13:18
the punch list for implementation. B.
13:21
Instruct the team to install the panels
13:23
and update the requirements
13:25
documentation afterward. You can pause
13:28
the video here if you need more time to
13:30
work on the question. The correct answer
13:32
is A. This question tests your
13:35
understanding of how to control scope in
13:37
predictive projects. Even small changes
13:40
if not approved through formal processes
13:42
result in scope creep which threatens
13:44
the integrity of the baseline. Choice A
13:47
is the best option because in waterfall
13:49
environments any change to scope
13:51
regardless of size or intent must go
13:53
through integrated change control. This
13:55
preserves traceability, transparency and
13:57
sponsor alignment. Choice B is
14:00
incorrect. Even if a change seems
14:02
harmless, making it without approval
14:04
violates the change management process
14:06
and opens the door for uncontrolled
14:08
scope growth. Choice C is incorrect. A
14:12
verbal request does not substitute for a
14:14
formal change request. Adding items
14:16
informally to a punch list undermines
14:18
governance. Choice D is incorrect.
14:21
Updating documents after work is done
14:23
does not prevent scope creep. It enables
14:26
it and bypasses control procedures.
14:28
Let's move on to the next question if
14:30
you're ready. Question 27. During a
14:34
predictive project to implement a
14:36
national emergency alert system, a
14:38
senior tester asks for a copy of the
14:40
requirements traceability matrix. The
14:43
project manager is surprised, noting
14:45
that testing hasn't started yet and the
14:47
RTM is still under internal review. What
14:50
is the most appropriate response from
14:52
the project manager? A. Postpone sharing
14:56
the RTM until execution begins to avoid
14:59
confusion. B. Share the current RTM to
15:02
support early test planning and
15:04
validation. C. Direct the tester to wait
15:08
until formal test cases are approved. D.
15:11
Explain that the RTM is used for
15:13
stakeholder signoff, not for team level
15:16
activities like testing. You can pause
15:18
the video here if you need more time to
15:20
work on the question. The correct answer
15:22
is B. This question tests your
15:25
understanding of the requirements
15:26
traceability matrix RTM in predictive
15:29
projects. The RTM is a valuable planning
15:32
tool not just for requirement validation
15:34
but also for early alignment between
15:37
deliverables and test criteria. Choice B
15:40
is the best option because sharing the
15:41
RTM early allows the testing team to
15:44
prepare, align test plans with
15:46
requirements, and ensure full
15:48
traceability. This promotes proactive
15:50
quality assurance and helps reduce risk
15:53
later. Choice A is incorrect.
15:56
Withholding the RTM delays critical
15:58
planning and may lead to misrequirements
16:00
or late defect discovery. Choice C is
16:04
incorrect. Waiting for test case
16:06
approval is too late in predictive
16:08
projects. Early traceability is key to
16:11
effective scope validation and quality
16:13
planning. Choice D is incorrect. The RTM
16:16
is not only for stakeholder signoff.
16:18
It's also used internally by teams to
16:21
validate, test, and trace requirements
16:23
to deliverables. Let's move on to the
16:25
next question if you're ready. Question
16:28
28. A predictive project is developing a
16:31
high security access control system. A
16:33
key stakeholder requests that facial
16:35
recognition be added to the devices
16:37
authentication features. The project
16:39
manager confirms that the new feature
16:40
aligns with market trends, but would
16:42
require additional design, hardware, and
16:45
testing work. What does this request
16:47
represent? A a change to project scope
16:51
as it alters the work required to
16:53
deliver the product. B a change to
16:56
product scope since it modifies system
16:58
features and user functionality. C a
17:01
riskto scope baseline requiring
17:03
contingency planning and issue tracking.
17:06
D a stakeholder communication gap as the
17:10
feature should have been discussed
17:11
earlier. You can pause the video here if
17:14
you need more time to work on the
17:16
question. The correct answer is B. This
17:20
question tests your understanding of the
17:22
difference between product scope and
17:23
project scope. In predictive
17:25
environments, it's critical to identify
17:27
whether a requested change affects what
17:30
is being delivered versus how it's being
17:32
delivered. Choice B is the best option
17:35
because the stakeholders request
17:36
directly changes the features of the
17:38
product, specifically the functionality
17:41
of the access system. This is a textbook
17:44
example of a change to product scope.
17:46
Choice A is incorrect. While the change
17:49
may eventually impact project scope, the
17:51
initial change request is focused on
17:54
product features, not the project
17:56
activities themselves. Choice C is
17:58
incorrect. This is not a risk or an
18:01
issue to be tracked. It's a proposed
18:04
scope change that should go through
18:07
formal evaluation. Choice D is
18:10
incorrect. The fact that it wasn't
18:11
discussed earlier doesn't change how it
18:13
should be categorized. It's still a
18:15
change to product scope, not a
18:18
communication gap. Let's move on to the
18:20
next question if you're ready. Question
18:23
29. In a predictive project to develop
18:26
an air traffic management tool, early
18:28
planning defines major deliverables and
18:30
interfaces. As technical teams begin
18:32
detailed design, new dependencies emerge
18:35
between modules. The project manager
18:37
decides to update several work package
18:39
definitions and refine certain estimates
18:41
to reflect the additional clarity
18:43
without modifying the scope baseline.
18:45
How should this approach be described?
18:48
A. Gold plating as the PM is enhancing
18:51
deliverables beyond the original
18:52
agreement. B. Scope creep because
18:55
changes are being introduced during
18:57
design. C progressive elaboration since
18:59
detail increases as planning evolves. D.
19:02
Integrated change control because
19:04
estimates are being modified. You can
19:06
pause the video here if you need more
19:08
time to work on the question. The
19:10
correct answer is C. This question tests
19:13
your understanding of progressive
19:15
elaboration in predictive project
19:16
management. Even in plan-driven
19:19
environments, some level of detail
19:21
emerges over time as teams break down
19:23
deliverables and refine planning
19:25
outputs. Choice C is the best option
19:28
because progressive elaboration is the
19:31
process of adding detail to the plan as
19:33
more information becomes available. The
19:36
key is that this does not change the
19:38
scope baseline. It simply enhances
19:40
clarity within approved boundaries.
19:42
Choice A is incorrect. Gold plating
19:45
refers to adding extra features or
19:48
enhancements not approved. That's not
19:50
the case here. Choice B is incorrect.
19:54
Scope creep means adding unauthorized
19:56
work. In this scenario, the scope
19:59
baseline remains unchanged. Choice D is
20:02
incorrect. Integrated change control
20:04
applies to formal changes to baselines
20:06
which isn't happening here. The PM is
20:08
refining details, not initiating a
20:11
change. Let's move on to the next
20:14
question. If you're ready. Question 30.
20:17
A predictive project to deliver a
20:19
regulatory reporting platform is nearing
20:21
completion. During final testing, a
20:23
senior developer adds a customizable
20:25
dashboard feature that was not in the
20:28
original requirements, but believes it
20:30
will improve user satisfaction. The
20:32
client is pleased and asks for similar
20:34
enhancements in future phases. How
20:37
should the project manager address this
20:39
situation? A. Thank the developer and
20:42
log the client's positive response as a
20:45
success. B. Accept the future since it
20:48
adds value and did not impact the
20:50
schedule. T. Initiate a change request
20:53
to update the baseline before project
20:55
closure. D. Treat it as goldplating and
20:58
reinforce adherence to defined
21:00
requirements. You can pause the video
21:03
here if you need more time to work on
21:05
the question. The correct answer is D.
21:08
This question tests your ability to
21:10
recognize gold plating, the addition of
21:13
extra features not approved or requested
21:16
and understand why it's discouraged in
21:19
predictive project management even
21:21
though it may be acceptable at your
21:23
workplace. Choice D is the best option
21:26
because the developer introduced
21:27
functionality that was not part of the
21:29
baseline. Even though it was
21:31
well-intentioned and the client liked
21:32
it, the addition violates scope
21:35
discipline. PMI considers goldplating
21:37
risky because it can lead to stakeholder
21:39
confusion, inconsistent delivery, and
21:42
increased risk. Choice A is incorrect.
21:45
Positive feedback does not justify
21:48
bypassing scope controls. This sets a
21:50
bad precedent. Choice B is incorrect.
21:54
Adding features without approval, even
21:56
if there's no impact to time or cost,
21:58
undermines project governance. Choice C
22:02
is incorrect. The change has already
22:04
been implemented. A change request
22:06
should have been submitted before the
22:08
work was performed. Congratulations on
22:10
reaching the end of scope management in
22:12
waterfall projects. You're now 30
22:14
questions into your PMP journey. A
22:17
fantastic milestone on the road to exam
22:19
readiness. Let's keep the momentum going
22:21
and I will see you in the next video.