What is Validate Scope?

The process of formalizing acceptance of the completed project deliverables by the customer or sponsor.

What is scope baseline?

The approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dictionary, used as a basis for comparison and under change control.

Scope and Change Control in Predictive Projects — CAPM Mastery: Comprehensive Exam-Ready Prep for the Modern CAPM (PMI)

Q: A software module has passed internal testing. The project manager now schedules a demo with the client to walk through the features and obtain written sign-off. Which process does this demo primarily belong to?

Validate Scope. This is Validate Scope. The deliverable is already verified internally; the goal now is formal customer acceptance and sign-off. Control Quality would be the internal testing phase that happened earlier.

Scope Baseline: Your Contract With Reality

Why Scope Baseline Matters

In predictive projects, fights about "what was promised" are fights about scope. The scope baseline is the approved reference you use to end those arguments and control the project.

Scope Baseline Parts

The scope baseline in a predictive life cycle includes: 1) the project scope statement, 2) the work breakdown structure (WBS), and 3) the WBS dictionary. Once approved, all three go under change control.

Scope Statement Focus

The scope statement defines product scope, project scope, major deliverables, assumptions, constraints, and what is explicitly out of scope. If a request is not in this baseline, it is scope creep unless formally changed.

WBS Definition

A WBS is "A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables." It is deliverable-based.

Work Packages

A work package is "The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed." Activities and schedules are derived from these work packages.

WBS Dictionary Role

The WBS dictionary adds detail for each WBS element. It is your main tool to clarify work package boundaries and acceptance criteria so that later control and acceptance decisions are objective.

Scope Baseline in Control

In control and change processes, you keep asking: does this work match the approved scope baseline? If yes, protect it; if no, trigger integrated change control. The exam often expects this disciplined response.

From Deliverables to WBS: A Concrete Scenario

Scenario Overview

Imagine a predictive project: your university club needs a one-time event website. Deliverables include info pages, registration, payment, and basic analytics. We build the scope baseline from this.

Scope Statement Snapshot

Product scope: responsive website with event details, registration, payment. Project scope: gather requirements, design, build, test, deploy, and train. Out of scope: mobile app, advanced automation, multi-language.

Why Out-of-Scope Matters

If a stakeholder later asks for a mobile app, you do not just "squeeze it in". Because it is out of scope, it must go through formal change control. The exam often tests this discipline.

Sample WBS (Top Level)

1.0 Event Website Project: 1.1 Requirements and Design, 1.2 Development, 1.3 Testing, 1.4 Deployment and Training. Each is broken down further into lower-level components.

Identifying Work Packages

Items like 1.2.2 Registration form are work packages. At this lowest level you estimate cost and duration and later derive activities for your schedule network diagram.

From WBS to Activities

From 1.2.2 Registration form, you might create activities: design fields, implement form, integrate database, unit test. These activities form your schedule model and critical path.

Using the Baseline for Changes

If someone asks to "add social media login" to the form, you check the scope baseline. If it is not in the scope statement or WBS dictionary, you trigger change control, not informal acceptance.

WBS Dictionary: Drawing the Line Around Work Packages

Purpose of the WBS Dictionary

The WBS dictionary adds detailed descriptions to WBS elements, especially work packages. It turns the WBS into a precise control tool that prevents scope misunderstandings.

Typical Entry Contents

Entries usually include: WBS ID and name, work description, included deliverables, acceptance criteria, assumptions, constraints, responsible owner, and references like related requirements.

Acceptance Criteria Definition

Acceptance criteria are "A set of conditions that is required to be met before deliverables are accepted." They provide objective tests for completion and customer sign-off.

Example: Registration Form Package

For 1.2.2 Registration form, you might define scope, what is in and out (e.g., include validation, exclude social login), and specific performance and data conditions as acceptance criteria.

Clarifying Boundaries

If someone later claims promo codes were included, the WBS dictionary entry that lists them as out of scope gives you an objective basis to resolve the dispute.

Support for Validate Scope

During Validate Scope, the customer uses the acceptance criteria from the WBS dictionary as a checklist to accept or reject deliverables. This reduces subjective debates.

Support for Change Analysis

When a new request appears, the WBS dictionary shows which work packages are impacted and how, making impact analysis and change estimation faster and more accurate.

Thought Exercise: Strengthen a Weak WBS Dictionary Entry

Work through this exercise to practice sharpening a WBS dictionary entry so it supports control and acceptance.

Scenario

You see this WBS dictionary entry for work package 2.3.1 "User Training Session":

Description: "Run a training for users on the new system."
Acceptance criteria: "Users are trained and happy."

This is too vague to support Validate Scope or Control Scope.

Your task

Pause and, in your own notes, rewrite this entry to make it more useful. Aim to:

Clarify what is included and excluded.
Add measurable acceptance criteria.
Make it easier to estimate and control.

Think for 2–3 minutes, then compare with the model answer below.

---

Model improvement (for self-check)

A stronger version could be:

Description: Plan, develop materials for, and deliver a 2-hour remote training session for up to 30 end users covering login, basic navigation, data entry, and standard reports.
In scope: Slide deck, demo environment setup, one live Q&A session, recording of the session.
Out of scope: One-on-one coaching, advanced reporting, custom role-based training.
Acceptance criteria:
At least 80% of registered users attend or watch the recording within 7 days.
Post-training quiz average score is at least 75%.
Participants can complete three standard tasks in the demo environment without trainer assistance.

Reflection prompts

How did adding in-scope and out-of-scope items change the clarity of the work package?
How do the new acceptance criteria make Validate Scope easier?
On the exam, when you see vague criteria like "users are happy," what should you recommend doing before execution?

Validate Scope vs Control Quality: Two Different Gates

Control Quality Focus

Control Quality checks deliverables internally against quality standards before customers see them. It asks: are we building it right from a technical and process perspective?

Control Quality Activities

Typical Control Quality work: inspections, tests, peer reviews, defect logging, and rework. It is mainly done by the project team and quality specialists.

Validate Scope Focus

Validate Scope is about customer acceptance. It asks: did we build the right thing? It compares verified deliverables to the scope baseline and requirements.

Validate Scope Activities

Activities include demos, formal reviews, walkthroughs, and getting sign-offs from customers or sponsors. Rejected deliverables often generate change requests.

Who Is Involved

Control Quality: internal team and quality staff. Validate Scope: external stakeholders like customers or sponsors, with the project manager facilitating the acceptance process.

Exam Clues

Finding defects and rework? Think Control Quality. Formal acceptance or sign-off? Think Validate Scope. Both use the scope baseline, but for different purposes.

When They Happen

Control Quality happens continuously as work is produced. Validate Scope typically happens at the end of phases or at major milestones in predictive projects.

Quiz 1: Validate Scope vs Control Quality

Decide which process is being described.

A software module has passed internal testing. The project manager now schedules a demo with the client to walk through the features and obtain written sign-off. Which process does this demo primarily belong to?

Control Quality
Validate Scope
Control Scope
Direct and Manage Project Work

Show Answer

Answer: B) Validate Scope

This is Validate Scope. The deliverable is already verified internally; the goal now is formal customer acceptance and sign-off. Control Quality would be the internal testing phase that happened earlier.

Integrated Change Control in Predictive Projects

Why Integrated Change Control

Predictive projects protect baselines. Any change to scope, schedule, or cost should go through integrated change control, not casual agreement, to avoid uncontrolled scope creep and chaos.

When It Applies

Use integrated change control when proposed changes affect the scope baseline, schedule baseline, cost baseline, or key management plans like quality or risk.

Step 1: Identify and Request

A need for change arises (defect, new requirement, risk response). A formal change request is documented, usually via the project manager, describing what and why.

Step 2: Impact Analysis

You analyze how the change affects scope, time, cost, quality, risk, and resources using artifacts like the WBS, WBS dictionary, schedule network diagram, and requirements traceability matrix.

Step 3: Decision

A change control board or designated authority reviews the request and impact. They approve, reject, defer, or ask for more information. The PM facilitates but may not be the approver.

Step 4: Update Baselines

If approved, you update the scope, schedule, and cost baselines and related plans, then communicate the new expectations to the team and stakeholders.

Step 5: Implement and Monitor

The team implements the approved change during Direct and Manage Project Work and you monitor its impact on performance and future decisions.

Change Control Scenario: Late Scope Request

The Late Request

Your sponsor asks late in the project: "Please add a waitlist feature; it should not take long." Your schedule is tight and the scope baseline did not include this feature.

Check the Baseline

You review the scope baseline and WBS dictionary and confirm that waitlist automation is explicitly out of scope for the registration work package.

Trigger Change Control

You explain that this is a scope change and help the sponsor submit a formal change request describing the new requirement and its value.

Analyze Impacts

With the team, you estimate extra work, schedule impact (including on the critical path), additional costs, and new risks introduced by the waitlist feature.

Review and Decide

You present options to the change control board: delay go-live, trade features, or defer the change. They approve adding waitlist with a 1-week delay.

Update and Communicate

You update the scope and schedule baselines and communicate the new go-live date. The feature is then implemented and monitored as part of normal work.

Exam Takeaway

On the exam, powerful stakeholder requests still go through integrated change control. Skipping analysis and baseline updates is almost never the correct predictive answer.

Requirements Tools: Workshops and Traceability Matrices

Facilitated Workshops

Facilitated workshops gather key stakeholders to define and refine requirements. A neutral facilitator guides discussions to surface conflicts and build shared understanding quickly.

Workshop Benefits

Workshops help elicit requirements, expose conflicts early, and align expectations. Techniques include brainstorming, storyboarding, and prioritization of requirements.

When to Use Workshops

If requirements are unclear or stakeholders disagree about what they want, a facilitated workshop is a strong next step, especially before execution begins.

RTM Definition

A requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them." It connects needs to what you actually build.

RTM Contents

Typical RTM columns: requirement ID, description, source, business objective, related WBS elements or deliverables, test cases, and status across the lifecycle.

Why RTM Matters

The RTM enables end-to-end traceability, supports impact analysis when requirements change, and helps detect scope creep when work has no linked requirement.

RTM in Control

During change control and Validate Scope, the RTM shows which deliverables and tests satisfy each requirement, making acceptance and change decisions more objective.

Build a Mini Requirements Traceability Matrix

Practice constructing a small requirements traceability matrix (RTM) for the event website.

Step 1: Start with three requirements

Imagine you have these approved requirements:

R-01: Users must be able to register online for the event.
R-02: Users must be able to pay online using credit card.
R-03: The organizer must be able to export a CSV list of all registered attendees.

Step 2: Map to deliverables

Pause and, in your notes, link each requirement to a deliverable or work package from our earlier WBS example.

Then compare with this sample mapping:

R-01 → Deliverable: Registration form (WBS 1.2.2)
R-02 → Deliverable: Payment integration (WBS 1.2.3)
R-03 → Deliverable: Reporting/export function (could be WBS 1.2.4 if you add it)

Step 3: Add test cases

Now think of one test case for each requirement.

Example answers:

R-01 test: "User completes form with valid data; system stores data and shows confirmation page."
R-02 test: "User pays with valid credit card; payment gateway approves; confirmation email is sent."
R-03 test: "Organizer clicks 'Export CSV'; system downloads a file with correct columns and data."

Step 4: Reflect

Ask yourself:

If R-02 changes (e.g., add PayPal support), which WBS elements and test cases are impacted?
If someone proposes a new dashboard feature with no linked requirement ID, what does the RTM tell you?

By practicing this mapping, you are training the exact skill the CAPM tests: using the RTM for traceability and impact analysis when requirements change.

Quiz 2: Scope Baseline and Change Control

Test your understanding of how to use the scope baseline in a change scenario.

During execution, a stakeholder insists that a feature is part of the project because it was discussed informally months ago. The feature is not in the approved scope statement, WBS, or WBS dictionary. What is the BEST action for the project manager in a predictive project?

Add the feature to keep the stakeholder satisfied, then update the schedule later.
Refuse to add the feature because it is not documented anywhere.
Ask the stakeholder to submit a change request, then analyze the impact on scope, schedule, and cost.
Schedule a team meeting to see if the feature can be done without affecting cost.