Control Scope is the ongoing work of tracking project and product scope, comparing results to the scope baseline, and processing scope changes through formal change control to prevent scope creep and keep deliverables aligned with agreed requirements.

Purpose & When to Use

Control Scope keeps the project focused on the agreed deliverables. It verifies what is completed against the scope baseline and manages any requested changes through a formal process. Use it throughout the project once the scope baseline is set, and apply it regularly in both predictive and adaptive life cycles.

Mini Flow (How It’s Done)

• Review the scope baseline: scope statement, WBS, and WBS dictionary.
• Collect actuals: completed work, deliverable status, and requirement fulfillment from the requirements traceability matrix.
• Compare actuals to the baseline and analyze variances and trends.
• Identify unapproved additions (scope creep) and stop them from proceeding.
• Evaluate needed changes; submit formal change requests with impact analysis on schedule, cost, quality, risks, and benefits.
• Process changes through integrated change control; implement only approved changes.
• Update the scope baseline, WBS, RTM, and related plans and documents after approval.
• Communicate status, variances, and decisions to stakeholders; adjust backlog or release plan in adaptive approaches.

Quality & Acceptance Checklist

• Scope baseline is current, version-controlled, and accessible.
• Each deliverable has clear, measurable acceptance criteria.
• All scope changes are submitted, reviewed, and approved or rejected formally.
• Requirements traceability matrix shows status, tests, and acceptance for each requirement.
• Approved changes are reflected in the WBS, schedule, budget, and risks.
• Variance analysis (e.g., scope performance, trend) is documented with actions.
• Instances of gold plating or scope creep are recorded and corrected.
• Stakeholder communications and acceptance records are complete and archived.

Common Mistakes & Exam Traps

• Confusing Control Scope (monitor and manage changes) with Validate Scope (formal acceptance of completed deliverables).
• Allowing team or stakeholders to add features without approval (gold plating or scope creep).
• Updating schedule or cost without updating the scope baseline and WBS after a change is approved.
• Skipping impact analysis before submitting or deciding on a change request.
• Not using the requirements traceability matrix to verify each requirement’s status and tests.
• Treating defect repair as a scope change without checking if it restores the baseline deliverable.
• Assuming internal completion equals acceptance; acceptance must match stated criteria.

PMP Example Question

A stakeholder asks the team to add a minor feature. The team has started work on it to save time. What should the project manager do next?

1. Allow the team to finish since the change is small and will delight the customer.
2. Submit a formal change request and assess impacts before any additional work continues.
3. Update the WBS and schedule to include the extra work and inform stakeholders.
4. Reject the change immediately and forbid any future change requests.

Correct Answer: B — Submit a formal change request and assess impacts before any additional work continues.

Explanation: Only approved changes should be implemented. Control Scope prevents scope creep and ensures changes go through formal change control with impact analysis.