Monitor and Control Scope
| Scope/Monitoring and Controlling/Monitor and Control Scope | ||
|---|---|---|
| Inputs | Tools & Techniques | Outputs |
|
||
Inputs, tools & techniques, and outputs for this process.
Ongoing oversight of project and product scope to compare actual results with agreed requirements, manage variances, and approve or reject scope changes so outcomes stay aligned with objectives.
Purpose & When to Use
- Confirm the team delivers only what was agreed and that each deliverable meets its acceptance criteria.
- Detect scope creep early and prevent unapproved work from entering the plan or backlog.
- Evaluate scope change requests, assess impacts, and apply governance for approval or rejection.
- Keep stakeholders aligned on what is in scope, what is not, and what changed since the last review.
- Use throughout the project: during iterations, at stage gates, prior to releases, and whenever variances or change requests appear.
Mini Flow (How It’s Done)
- Gather current data: completed deliverables, stories done, defects, and any requested changes.
- Compare actuals to the agreed scope baseline or the current backlog goals; analyze variances and trends.
- Inspect or demo deliverables against acceptance criteria with the customer or product owner; record acceptance or rejection.
- Update the requirements traceability or backlog to show coverage, completion, and open gaps.
- Perform impact analysis on each change request across value, time, cost, quality, risk, and resources.
- Apply governance: approve, defer, or reject the change; document the decision and rationale.
- Implement approved changes by updating scope documents or backlog items and adjusting plans and forecasts.
- Communicate decisions, impacts, and next steps to the team and stakeholders.
- Track corrective and preventive actions and monitor cumulative effect of changes over time.
Quality & Acceptance Checklist
- Acceptance criteria are clear, testable, and linked to each deliverable or story.
- Every completed deliverable is inspected or demoed, and acceptance or rework is recorded with date and approver.
- Requirements traceability shows end-to-end linkage from need to delivered outcome and test evidence.
- No change is implemented without documented approval and version control updates.
- Variance and trend reports are produced and reviewed; actions are assigned and tracked to closure.
- Known defects, technical debt, and open scope items are logged with owners and target dates.
- Stakeholders are informed of scope decisions and their impact on benefits, schedule, and cost.
- The backlog is ordered, and “Definition of Ready” and “Definition of Done” are understood by the team.
- Baselines or backlog targets are updated after approved changes, and old versions are archived.
Common Mistakes & Exam Traps
- Implementing work based on verbal requests; always analyze impact and obtain approval first.
- Mixing product acceptance with process quality checks; acceptance verifies deliverables meet agreed criteria, not whether the process was followed.
- Approving “small” changes informally; many small, untracked changes cause major scope drift.
- Not involving the customer or product owner in reviews, leading to late surprises and rework.
- Using schedule or cost data alone to judge scope performance; validate against requirements and acceptance criteria.
- Failing to update traceability, backlog ordering, and baselines after a change is approved.
- Gold plating by adding extra features without business approval, even if they seem low effort.
- Waiting until the end to verify scope; incremental reviews reduce risk and improve feedback.
- In adaptive approaches, treating scope as fixed and resisting backlog refinement; prioritize by value and capacity each iteration.
PMP Example Question
A sponsor informally asks the team to include a “quick enhancement” while they are finishing a feature. What should the project manager do next?
- Approve the enhancement to keep the sponsor satisfied.
- Ask the team to estimate effort and add it if capacity allows this iteration.
- Request a formal change, perform impact analysis, and route it through governance.
- Defer the request until the next lessons learned session.
Correct Answer: C — Request a formal change, perform impact analysis, and route it through governance.
Explanation: Changes must be evaluated and approved before implementation. Bypassing change control, even for small items, risks scope creep and misaligned outcomes.
HKSM