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?

  1. Approve the enhancement to keep the sponsor satisfied.
  2. Ask the team to estimate effort and add it if capacity allows this iteration.
  3. Request a formal change, perform impact analysis, and route it through governance.
  4. 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.

ICS/OT Cybersecurity Fundamentals — Security Built for Industrial Systems

Industrial control systems cannot be secured like ordinary IT. A forced reboot, aggressive scan, or incompatible patch can interrupt production and create real safety consequences. Effective OT security begins with understanding the systems, constraints, and risks unique to industrial environments.

This course gives IT professionals, engineers, operators, and security practitioners a practical foundation in ICS threats, zone and conduit design, risk assessment, passive asset visibility, and vendor evaluation. You will learn how IEC 62443, NIST CSF, and MITRE ATT&CK for ICS apply where availability and safety come first.

Eight reconstructed incidents—including Stuxnet, Triton, Ukraine 2015, Colonial Pipeline, and PIPEDREAM—show how attackers move through OT environments, what they target, and which defenses could have changed the outcome.

Watch the course preview, then build the vocabulary, frameworks, and judgment needed to take credible first steps in ICS/OT cybersecurity.

Explore the Course


ICS/OT Cybersecurity Fundamentals course preview

Lead with clarity, influence, and outcomes.

HK School of Management and Technology offers a practical Leadership for Project Managers course for real projects, tight deadlines, and cross-functional teams. Learn to set direction, align stakeholders, and drive commitment without relying on title. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More