Scope creep là kẻ thù số một của project delivery. PM phải kiểm soát phạm vi chặt chẽ nhưng vẫn linh hoạt đủ để accommodate legitimate change. "Change is inevitable — uncontrolled change is fatal."
📖 Scope Management Core Concepts
🇺🇸 English
Product Scope: The features and functions that characterize a product or service. Project Scope: The work performed to deliver the product, service, or result.
Scope baseline: Approved scope statement + WBS + WBS dictionary. Any changes must go through change control.
Scope creep: Uncontrolled expansion of project scope without corresponding adjustment to time, cost, or resources. Common causes: unclear requirements, informal change requests, weak change control.
Scope validation: Formal acceptance of completed deliverables by customer/sponsor. Different from Quality Control (QC = correct, Validate Scope = accepted).
Product Scope: Các tính năng và chức năng đặc trưng cho sản phẩm. Project Scope: Công việc được thực hiện để deliver sản phẩm.
Scope baseline: Scope statement + WBS + WBS dictionary đã được phê duyệt. Bất kỳ thay đổi nào phải qua change control.
Scope creep: Mở rộng phạm vi dự án không kiểm soát mà không điều chỉnh tương ứng về thời gian, chi phí hoặc nguồn lực.
Scope validation: Chấp thuận chính thức các deliverables đã hoàn thành bởi khách hàng/sponsor.
📋 Scope in Predictive vs Agile
Aspect
Predictive
Agile
Hybrid
Scope definition
Fully defined upfront in scope statement + WBS
High-level epics/features; detailed just-in-time
Core features defined; enhancements flexible
Change process
Formal CCB (Change Control Board)
Product Backlog reprioritization by Product Owner
CCB for major changes; PO for sprint-level
Scope validation
End of phase/project formal sign-off
Sprint Review every sprint
Phase gates + sprint reviews
Scope document
Project Scope Statement, WBS
Product Backlog, User Stories
Requirements traceability + backlog
Scope creep defense
Baseline + change control
Backlog grooming + velocity transparency
Both mechanisms applied contextually
🔧 Requirements Management
🇺🇸 English
Requirements Traceability Matrix (RTM): Links requirements from origin to deliverables. Ensures every requirement is addressed and no unauthorized work is done.
Requirement types:
Business requirements: Higher-level needs of the organization (what and why)
Stakeholder requirements: Needs of a specific stakeholder group
Solution requirements: Functional (what system does) + Non-functional (how well it does it)
Transition requirements: Temporary capabilities needed to move from current to future state
Compliance/quality requirements: Conditions the project must meet
🇻🇳 Tiếng Việt
Requirements Traceability Matrix (RTM): Liên kết requirements từ nguồn gốc đến deliverables. Đảm bảo mọi requirement đều được đáp ứng.
Loại requirements:
Business requirements: Nhu cầu cấp cao của tổ chức
Stakeholder requirements: Nhu cầu của nhóm stakeholder cụ thể
ID | Business Need | Requirement | Story | Status | Test CaseBR-01 | Loan processing | Credit score API call | US-12 | Done | TC-045
BR-02 | Regulatory compliance| PII encryption at rest | US-18 | In Dev | TC-067, TC-068
BR-03 | Partner integration | Bank A API OAuth 2.0 | US-21 | Testing | TC-082
BR-04 | Performance | API <500ms p95 | US-25 | Open | TC-090
BR-05 | Audit trail | All decisions logged | US-30 | Open | TBD
── RTM PURPOSE ───────────────────────────────────────────
• Ensures no requirement is missed (100% coverage)
• Provides traceability from business need → story → test
• Helps PM defend against scope creep (if it's not in RTM, it's a change request)
🎯
Exam Tips — Scope Management
Validate Scope = customer acceptance. Quality Control = product correctness. Both can happen, scope validation is LAST.
Scope creep = uncontrolled change. Gold-plating = PM/team adds features. Both are wrong.
In Agile, scope is flexible but sprint commitment is fixed — new work goes to backlog, not current sprint
If customer requests change during predictive project → go through change control, never just add it
WBS 100% rule: WBS must include 100% of project scope — if it's not in WBS, it's out of scope
RTM is the key tool for requirements management and scope validation
💼 Thực chiến / Scenario
🏢
FinTech Company X — Scope Creep Under Pressure
Situation: Sprint 8 của Project Alpha. Bank Partner A's Product Manager calls PM directly and requests adding a "real-time SMS notification" feature. "Just a small addition, shouldn't take long." The PM checks: this feature is NOT in the approved scope or backlog.
PM's response: "I understand this is important for your team. Let me document this as a formal change request so we can assess the impact on scope, budget, and timeline. I'll get back to you with an impact analysis within 48 hours."
Impact analysis: SMS feature requires: 3rd party SMS provider integration (8 SP), message templates (3 SP), compliance review for PII in SMS (2 SP), testing (3 SP). Total = 16 SP = ~1 sprint. Timeline impact: +2 weeks if absorbed, or scope trade-off needed.
Change Control Board decision: Feature is approved but deferred to Phase 2 (after go-live). Phase 1 stays on schedule. Partner PM accepts — they understand the business priority.
PMP lesson: Saying "no" to scope creep is easier when you say "not now, through change control." The PM protected the project while respecting the partner. Change control isn't bureaucracy — it's professional integrity.
✏️ Practice Questions
Question 1
A stakeholder requests a small additional feature "that won't take more than a day." The feature is not in the approved scope. What should the PM do FIRST?
A. Add it to the current sprint since it's so small
B. Refuse the request because it's not in scope
C. Submit it as a formal change request and perform impact analysis
D. Ask the developer to build it in their spare time
✅ Answer: C — Any work not in the approved scope, regardless of size, must go through the change control process. "Small" changes are the most common way scope creep enters a project. The PM must assess the real impact (it's never "just a day") and get proper authorization. Options A and D bypass process. Option B is too rigid — the request may be valid, it just needs proper evaluation.
Question 2
The customer has signed off on the final deliverable, confirming it meets their needs. Which process has just been completed?
A. Quality Control
B. Quality Assurance
C. Validate Scope
D. Control Scope
✅ Answer: C — Validate Scope is the process of obtaining formal customer acceptance of completed deliverables. Quality Control (A) verifies the work meets quality standards (done before validate scope). Quality Assurance (B) audits processes. Control Scope (D) monitors scope performance and manages changes. The sequence is: QC (internal check) → Validate Scope (customer acceptance).
Question 3
A development team adds a 'helpful' error logging feature that wasn't in the approved scope because they thought it would be useful. The PM discovers this during a code review. This is:
A. Good initiative that should be praised
B. Gold-plating — unauthorized scope addition that should go through change control even if beneficial
C. A quality improvement that is always acceptable
D. Acceptable since it's a technical implementation detail
✅ Answer: B — Gold-plating is adding features or enhancements beyond the approved scope, even if well-intentioned. It consumes unplanned resources, may introduce unintended side effects, and bypasses the change control process that exists to evaluate impact and obtain authorization. All scope changes — beneficial or not — must go through change control. The feature may ultimately be approved, but the team should not self-authorize scope additions.
🤖 AI Tools for PMs
🤖
How AI Augments This Process
AI helps PMs analyze scope change requests, generate impact assessments, create Requirements Traceability Matrices, and draft change control documentation efficiently.
Sample Claude Prompts
Change request impact analysis
I received a scope change request. Help me do a full impact analysis.
Change request: [description of what is being requested]
Requestor: [who asked — stakeholder role]
Justification given: [their reason for the change]
Project context:
Current phase: [planning / sprint X / UAT / near go-live]
Budget status: [on track / tight / buffer available]
Schedule status: [on track / ahead / behind]
Team capacity: [available / fully loaded / overloaded]
Analyze the impact across:
1. Scope: What changes? What's added/removed? Any dependencies affected?
2. Schedule: How many days/sprints does this add? Which milestone is affected?
3. Cost: Estimated effort in person-days × rate. Any vendor/tool costs?
4. Quality: Does this introduce any risk to existing deliverables?
5. Risk: New risks introduced by this change?
6. Stakeholder: Who benefits? Who is negatively impacted?
Output: Impact Analysis Report for CCB submission (1 page).
Requirements Traceability Matrix (RTM) creation
Help me build a Requirements Traceability Matrix for my project.
Business requirements (list):
BR-01: [requirement description]
BR-02: [requirement description]
[add more]
Solution requirements / user stories (list):
US-01: [story title]
US-02: [story title]
[add more]
Test cases (list):
TC-01: [test description]
[add more]
Create an RTM that maps: Business Requirement → User Story → Test Case → Status
Also:
1. Identify any business requirements without a corresponding story (coverage gap)
2. Identify any stories not linked to a business requirement (potential gold-plating)
3. Identify any test cases not linked to a story (orphaned tests)
4. Generate a coverage summary: % of BRs covered by stories, % with test cases
Scope creep detection and response
I'm concerned my project is experiencing scope creep. Help me diagnose and respond.
Signs I'm observing: [list — e.g., sprint velocity declining, more than X stories added mid-sprint, informal verbal requests from stakeholders, team working late]
Project type: [Agile / Waterfall / Hybrid]
Key stakeholders involved: [who is making informal requests]
What's been approved in the scope baseline: [summary]
What seems to be happening outside that: [what I think is creep]
Help me:
1. Classify each item: is it genuine scope creep / legitimate change request / gold-plating / in-scope clarification?
2. Calculate the impact of all uncontrolled additions (if I can estimate it)
3. Draft a conversation with the stakeholder requesting the changes
4. Strengthen my scope control approach (process steps to prevent recurrence)
5. Draft a scope status update for my sponsor
Jira / Confluence Template
Jira — Change Request Issue
── JIRA: CHANGE REQUEST TEMPLATE ────────────────────────Issue Type: Change Request
Summary: [CR-###] [Feature/Module] — [short description]
Priority: [Critical / High / Medium / Low]
Labels: change-request | cr-status:[pending/approved/rejected/deferred]
── CHANGE DESCRIPTION ────────────────────────────────────Requested by: [Name / Role / Date]
Change description: [What is being requested — clear, specific]
Business justification: [Why this change is needed — business value or risk]
Change type: [ ] Scope [ ] Schedule [ ] Budget [ ] Quality [ ] Regulatory
── IMPACT ANALYSIS ───────────────────────────────────────Scope impact: [Adds/removes/modifies what]
Schedule impact: +[X] days | Affects milestone: [name]
Cost impact: +$[amount] | Effort: [person-days]
Risk introduced: [new risks]
Dependencies: [other work items affected]
── CCB DECISION ──────────────────────────────────────────Decision: [ ] Approved [ ] Rejected [ ] Deferred [ ] More info needed
CCB date: [YYYY-MM-DD] | Decision maker: [name/role]
Conditions: [any approval conditions]