PMI PMP: Scope, Requirements & Change Control — Study Guide

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Part of the PMP — Study Guide. Practice with verified answers in the PMI exam hub, or take timed practice tests on ExamRoll.io.

Requirements Elicitation, Traceability, and the RTM

Scope integrity begins long before the first work package is estimated — it begins with disciplined requirements elicitation. Elicitation is not a single workshop; it is a layered activity combining interviews, facilitated workshops (JAD sessions, design sprints), document analysis, observation (“job shadowing”), prototyping, questionnaires, and context diagrams. Each technique surfaces a different requirement type: business requirements (the why), stakeholder requirements (the who wants what), solution requirements (functional and non-functional), transition requirements, project requirements, and quality requirements. Missing any layer produces predictable failure — for instance, capturing functional requirements without non-functional ones leads to a system that “works” but cannot scale.

Once captured, requirements must be traceable. The Requirements Traceability Matrix (RTM) links each requirement bidirectionally to (a) the business objective or benefit that justifies it, (b) the WBS deliverable that will produce it, (c) the design element or user story that implements it, (d) the test case that verifies it, and (e) the stakeholder who owns acceptance. A mature RTM also carries priority, status, source, and change-request ID. The RTM is the single most powerful weapon against scope creep and gold-plating: any proposed change that cannot be traced to an approved business objective is a candidate for rejection, and any objective without a test case represents an unverifiable claim of completion.

A typical RTM row structure:

• R-042
  • Description: System supports SSO
  • Business Objective: Reduce login support tickets 30%
  • WBS Ref: 1.3.2
  • Priority: Must
  • Test Case: TC-118
  • Acceptance Criteria: SAML 2.0 login <2 sec
  • Owner: CIO
  • Status: Approved

Scope Baseline, WBS, and Acceptance Criteria

The scope baseline is a formally approved trio: the scope statement, the WBS, and the WBS dictionary. It is not a wish list; it is the contractually referenced description of what “done” means. The WBS decomposes deliverables (never activities) down to the work-package level, respecting the 100% rule — the sum of child elements equals the parent, no more, no less. Each terminal work package earns a WBS dictionary entry describing scope of work, acceptance criteria, assumptions, responsible resource, code of accounts identifier, milestone dates, and quality requirements. This is what makes estimating defensible and control possible; you cannot earn value on work you have not defined.

Acceptance criteria must be specific, measurable, and negotiated before work begins. “User-friendly interface” is not a criterion; “task completion in ≤3 clicks with <2% error rate in usability testing” is. Every deliverable requires stakeholder sign-off against these criteria via a formal validation activity — typically the Validate Scope process, which produces accepted deliverables and change requests for those that fail. The lesson embedded in scenarios where a stakeholder refuses approval near closeout is unambiguous: acceptance criteria and interim validation should have been executed throughout execution, not deferred to the end. When a deliverable is rejected at closeout, the correct move is to log the gap, raise a change request to remediate, reassess the schedule and cost impact, and drive it through change control — not to argue that the work “met the spec.”

Backlog Prioritization and MVP

In adaptive and hybrid environments, scope is expressed as a prioritized product backlog rather than a frozen baseline. Prioritization techniques include MoSCoW (Must, Should, Could, Won’t), WSJF (Weighted Shortest Job First), Kano analysis (basic, performance, delight features), and simple value/effort matrices. The purpose is always the same: sequence work so that the highest business value is delivered first, and so that if the project is cut short, the released increment still solves a real problem.

The Minimum Viable Product (MVP) is the smallest slice of functionality that delivers measurable value and allows validated learning. It is not “phase one of a fixed plan”; it is a hypothesis-testing tool. Delivering MVP early exposes assumptions to real users, generates feedback for backlog refinement, and protects against the classic failure pattern where teams deliver features nobody uses. When stakeholders complain that “delivered functionality is not what the business needed,” the root cause is nearly always upstream: prioritization was not tied to validated business objectives, and no early increment was released to test the assumptions. The corrective discipline is to run backlog refinement with the business, weight items by benefit, release incrementally, and re-prioritize after each demo.

Change Requests, the CCB, and Integrated Change Control

Once baselines exist, every alteration — including “small” ones — flows through Perform Integrated Change Control. The workflow is: (1) submit a change request documenting what, why, and expected benefit; (2) log it in the change log; (3) perform impact analysis across scope, schedule, cost, quality, resources, risk, and procurement (the seven-way squeeze); (4) route to the Change Control Board (CCB) for approval, deferral, or rejection; (5) if approved, update the affected baselines, the RTM, the WBS, the risk register, the assumption log, and communicate to all impacted stakeholders; (6) if rejected or deferred, retain the record for audit and lessons learned.

The CCB composition should match authority thresholds — sponsor, business owner, technical lead, PM, and often finance and quality. Small changes are not exempt; they are handled through pre-defined delegated authority (e.g., PM may approve changes under $5,000 and 2 days impact) but still logged. The assumption that a “minor” change has zero baseline effect is where projects quietly bleed: fifteen minor changes each costing “just half a day” consume a three-week buffer without anyone noticing.

Impact Assessment and Assumption/Issue Discipline

A proper impact assessment is not a paragraph in an email. It quantifies the delta on the schedule (via network analysis and float consumption), on cost (labor, materials, contingency draw), on quality (defect risk, test coverage), on risk (new threats introduced or existing ones amplified), and on stakeholder engagement. If a change consumes contingency, the reserve analysis must be updated. If it invalidates an assumption — say, that a third-party API would remain stable — the assumption log is updated and any dependent requirements are re-verified. New problems arising from the change go to the issue log with an owner and due date.

Why the Common Traps Fail

Consider the four recurring wrong-answer patterns:

• Delivering low-value functionality fails because effort was expended without traceability to business benefit. The RTM and MVP discipline exist precisely to prevent this; skipping them means the team is optimizing for output, not outcome.
• Accepting late scope additions informally fails because it bypasses impact analysis. The addition may consume float that other work needs, or may introduce a risk that invalidates the test strategy. Without CCB visibility, no one is accountable when the schedule slips.
• Implementing changes without a change request fails because it corrupts the baseline — future variance analysis becomes meaningless, and earned value calculations drift from reality. It also erodes governance: once one channel bypass is tolerated, all discipline collapses.
• Assuming small changes have no impact fails because impact is cumulative and often non-linear. A one-line code change can trigger regression testing across dozens of modules; a “minor” spec tweak can require re-approval from a regulator. The rule is: assess first, categorize second, never assume.

When a customer requests scope changes weekly, the correct response is threefold: route every request through the formal change control process, perform and share impact analysis so the customer sees the true cost of each change, and re-engage the sponsor and CCB to reset expectations and, where appropriate, replan or re-baseline. Silence, informal acceptance, or unilateral rejection are all failures of the same discipline.

Practical Problem: Use-Case Scenario

Scenario: Meridian Health is midway through an 18-month, $4.2M implementation of a new patient intake platform intended to reduce ER admission time by 30%. Priya, the PM, leads a hybrid team of 22 people across clinical, IT, and vendor staff. During Sprint 9 review, the Chief Nursing Officer requests that the system also capture social-determinants-of-health data — a request the clinical lead calls “essential” but which was never in the original scope statement or product backlog.

Challenge: Priya must decide how to handle the CNO’s request without derailing the release schedule, inflating cost, or dismissing a senior stakeholder whose adoption support is critical to project success.

Recommended Approach:

1. Log the request as a formal change request in the change control system rather than accepting it verbally in the sprint review, and thank the CNO for surfacing it.
2. Trace the request through the Requirements Traceability Matrix: identify whether it maps to an existing business objective (reduced admission time) or introduces a new benefit stream, and flag any downstream WBS, design, and test-case impacts.
3. Convene the business analyst and clinical lead within 48 hours to perform impact analysis — estimating effort, cost delta, schedule impact, and dependencies on the vendor’s data model, plus non-functional impacts like HIPAA and reporting load.
4. Present the analysis to the Change Control Board with three options: defer to Phase 2, absorb via re-prioritization by dropping a lower-value backlog item of equivalent size, or approve with a formal budget and schedule baseline update.
5. Update the RTM, scope baseline, and communications log to reflect the CCB decision, and brief the CNO personally on the outcome and reasoning.
6. Add a retrospective action to review why social-determinants data was missed during initial elicitation — likely an incomplete stakeholder analysis of nursing leadership.

Why This Works: Routing the request through documented change control protects the baseline while still honoring the stakeholder — the request is neither refused nor silently absorbed, both of which are classic scope-management failures. Tracing through the RTM ensures the decision is grounded in business value rather than stakeholder seniority, and the retrospective step strengthens future elicitation. This avoids the twin pitfalls of scope creep (uncontrolled expansion) and stakeholder alienation (rigid refusal).

← Agile · All domains · Risk →

Practice these questions → · Timed practice on ExamRoll.io →