Monitor and Control Scope in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Monitor and Control Scope in PMBOK 8 — Complete Guide

Formerly known as: Control Scope (PMBOK 6)

The project was 70% through execution when the sponsor walked into the weekly status meeting and said: “I need the reporting module to also include predictive analytics.” The project manager did not flinch. She opened the scope baseline document on the shared screen, pointed to the WBS element for the reporting module with its documented acceptance criteria, noted that predictive analytics was not in the requirements documentation, and said: “That would be a scope change. I can have an impact assessment on schedule, cost, and resources on your desk by Thursday. Do you want to submit a formal change request?” The sponsor thought for a moment and said: “Actually, let’s defer it to Phase 2.” The project delivered on time and on budget.

That project manager was executing Monitor and Control Scope — Process 5 of PMBOK 8’s Scope Domain — exactly as it should be executed. She had a baseline, she knew it, and she applied it when it mattered. The conversation that could have added eight weeks and $45,000 to the project took four minutes and produced a better decision for everyone involved.

This guide covers everything you need to master Monitor and Control Scope:

• What it is — definition, PMBOK 8 position, and what changed from PMBOK 6
• Why use it — direct benefits and the cost of failing to control scope
• Full ITTO — from the official PMBOK 8 PDF
• Step-by-step application guide
• When to apply it
• Two real-world examples — Project Phoenix and Project ProjectAdm
• Templates and downloads
• Five common errors
• Tailoring — predictive, agile, and hybrid
• Process interactions
• Quick-application checklist

1. What Is Monitor and Control Scope

Monitor and Control Scope is the ongoing process of monitoring and managing changes to the project scope — and measuring the quality and value of the deliverables to fulfill quality standards. This process controls how requests for changes to the detailed project scope statement will be processed while also ensuring the deliverables meet the specified quality requirements and that the scope and quality are aligned to the scope baseline.

This process also includes the monitoring and recording of results to assess performance and determine whether the deliverables meet expectations. The primary objective of monitoring and controlling scope is to ensure the product, service, or result is relevant and delivering value to the stakeholders, as well as fulfilling the requirements specified by the stakeholders.

In PMBOK 8, Monitor and Control Scope is broader than its PMBOK 6 predecessor: it explicitly includes quality measurement and verification of deliverables against quality standards, reflecting the integration of scope and quality that is a defining characteristic of PMBOK 8’s Scope Domain.

What changed from PMBOK 6 to PMBOK 8

2. Why Use Monitor and Control Scope

Direct benefits

• Prevention of scope creep: Scope creep — the gradual, often unnoticed expansion of project scope beyond the approved baseline — is one of the most cited causes of project overruns. Monitor and Control Scope creates a systematic, ongoing defense against scope creep by continuously comparing actual work against the approved baseline and flagging any deviations.
• Early detection of scope deviations: Variance analysis applied to scope performance data identifies deviations before they compound. A 5% scope deviation detected in week 4 is a manageable adjustment. The same deviation detected in week 12 may represent unrecoverable schedule and cost overruns.
• Quality verification integrated with scope control: PMBOK 8’s integration of quality into scope monitoring means that deliverables are not just checked for completeness — they are measured against quality standards. Deliverables that meet all functional requirements but fail quality thresholds are flagged as non-conforming before they advance through the delivery pipeline.
• Maintained scope baseline integrity: Approved scope changes are incorporated into the scope baseline through formal change control. This ensures the baseline remains an accurate reflection of the current approved scope, enabling reliable performance measurement throughout the project.
• Stakeholder confidence through transparency: Regular scope performance reporting — communicating what was planned, what was delivered, and how quality measurements compare to standards — builds stakeholder confidence and prevents the surprise discoveries at delivery that trigger disputes and dissatisfaction.

The cost of failing to control scope

• Scope creep compounds into project failure: Research consistently identifies uncontrolled scope expansion as a leading cause of project budget overruns exceeding 20%. Scope creep rarely arrives as a single large addition — it accumulates through dozens of small informal additions, each of which seemed reasonable in isolation.
• Quality failures discovered at delivery: Without ongoing quality measurement integrated with scope monitoring, quality issues accumulate undetected until the formal acceptance process. Late-stage quality failures are disproportionately expensive: they require rework that cascades through completed deliverables that were built on the assumption of the failed component’s quality.
• Baseline drift renders progress measurement meaningless: When informal scope additions are not tracked against the baseline, the baseline no longer reflects what the project is actually doing. Earned value measurements become meaningless, schedule comparisons are invalid, and the project manager loses the visibility needed to make informed decisions.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO of Monitor and Control Scope as defined in PMBOK 8 (Figure 2-18, p.148):

Inputs explained

Scope management plan: Defines the change control process that governs how scope changes are evaluated and approved. Monitor and Control Scope applies this documented process to every change request. The scope management plan is the authority document that determines what constitutes a scope change, who approves it, and what impact assessment is required.

Quality management plan: Defines the quality standards that deliverables must meet, the measurement methods to be applied, and the quality roles and responsibilities. Monitor and Control Scope uses the quality management plan to execute quality measurement activities against completed or in-progress deliverables.

Performance measurement baseline: The integrated baseline (scope + schedule + cost) against which actual performance is measured. Scope variance is calculated by comparing the planned scope (from the WBS) against the actual scope delivered. Without an approved baseline, scope performance measurement is not possible.

Deliverables: Completed or in-progress deliverables are the direct subject of scope monitoring. Each deliverable is assessed against its WBS dictionary acceptance criteria and quality standards to determine whether it meets scope and quality requirements.

Quality metrics: Quantitative measures defined for each quality attribute that is being monitored (e.g., defect density, test pass rate, performance benchmark values). Quality metrics provide the objective measurement standard for quality control activities performed as part of this process.

Tools & Techniques explained

Variance analysis: Comparison of actual scope performance against the planned scope baseline. Key variance questions: Which deliverables were planned for this period and which were completed? What percentage of planned scope has been delivered? Are there scope elements that are taking significantly more or less effort than estimated? Scope variance that is consistently trending in one direction requires root cause analysis and a corrective action plan.

Trend analysis: Examination of scope performance over time to identify patterns that predict future performance. If the team has consistently delivered 80% of planned scope per period over several reporting cycles, the trend analysis reveals that the project will likely miss its scope completion target under the current trajectory — enabling proactive intervention rather than reactive crisis management.

Root cause analysis: When scope variances are identified, root cause analysis determines the underlying cause so that corrective actions address the actual problem rather than its symptoms. A recurrent pattern of scope scope additions from a single stakeholder may have its root cause in an inadequate stakeholder engagement process during requirements elicitation, not in the scope control process itself.

Audits and inspections: Formal reviews of deliverables against scope and quality requirements. Audits assess whether project processes are being followed as documented. Inspections physically or functionally examine deliverables to verify they meet acceptance criteria. In PMBOK 8, audits and inspections are explicit scope monitoring tools, not just quality tools — reflecting the integrated scope-quality perspective.

Testing/product evaluations: Systematic testing of deliverables against functional requirements and non-functional quality standards. Testing is the primary mechanism for verifying that deliverables meet the acceptance criteria documented in the requirements documentation and WBS dictionary. Test results feed directly into quality reports and verified deliverables outputs.

Outputs explained

Verified deliverables: Deliverables that have been formally tested and inspected and confirmed to meet their acceptance criteria. Verified deliverables are the input to the Validate Scope process (formal stakeholder acceptance). Only verified deliverables should be submitted for formal acceptance — submitting unverified deliverables to clients creates acceptance failures that damage trust and trigger disputes.

Quality reports: Documentation of quality monitoring results: quality control measurements performed, test results, audit findings, non-conformances identified, corrective actions taken, and quality trend analysis. Quality reports are both operational management tools (tracking quality performance) and governance artifacts (documenting that quality standards were applied and met).

Change requests: Formal change requests triggered by scope deviations, quality non-conformances, or stakeholder requests. Change requests from scope monitoring are particularly valuable because they are backed by documented variance analysis — the impact assessment is already partially complete before the formal change control process begins.

4. How to Apply the Process Step by Step

Step 1 — Establish the scope monitoring cadence

Define and communicate the frequency and format of scope monitoring activities. For most projects, weekly scope status assessment synchronized with the status reporting cycle is the minimum. High-velocity projects may require daily scope tracking. Define what data will be collected (WBS completion status, change request volumes, quality metric measurements), how it will be collected (team self-reporting, automated tracking tools, inspection records), and who is responsible for maintaining it.

Step 2 — Track WBS completion against the scope baseline

At each monitoring cycle, update the WBS completion status: which work packages are planned for the period, which are complete, which are in progress, and which are not started. Calculate scope completion percentage using the WBS work package structure as the measurement framework. Compare against the planned completion curve. Flag any work packages that are behind plan or have exceeded their planned effort.

Step 3 — Apply quality control measurements to deliverables

For each deliverable completed during the monitoring period, execute the quality verification activities defined in the quality management plan: functional testing against requirements, performance testing against non-functional standards, inspection against WBS dictionary acceptance criteria, and audit against documented quality processes. Record all measurements in quality control measurement records. Flag non-conformances for root cause analysis and corrective action.

Step 4 — Identify and evaluate scope change requests

Apply the change control process from the scope management plan to every potential scope change. For each request: document the request in the change log; assess the impact on scope, schedule, cost, quality, and risk; determine whether it meets the threshold for formal sponsor or governance approval; obtain the required approval; and communicate the decision to all affected parties. Never informally incorporate scope additions without completing this process.

Step 5 — Produce scope performance reports

Compile work performance information (scope completion status, variance against baseline, change request status) and quality reports (measurement results, non-conformances, corrective actions) into a scope performance report for stakeholder communication. The report should distinguish between what was planned, what was delivered, what the current trend projects, and what actions are underway to address any variances.

Step 6 — Update project documents and baseline as needed

Update the requirements documentation with any requirement refinements identified during monitoring. Record lessons learned about scope control effectiveness. If approved changes affect the scope baseline, update the WBS and WBS dictionary through formal change control and record the new baseline version.

5. When to Apply Monitor and Control Scope

Monitor and Control Scope is a continuous process executed throughout the Executing and Monitoring and Controlling focus areas of the project. Specific triggers include:

• Every status reporting cycle: Scope performance data must be collected and analyzed at every project status reporting cycle, without exception.
• On every completed deliverable: Quality control measurements are applied to every deliverable when it is completed, before it is submitted for formal acceptance.
• On every scope change request: Every request that could affect scope triggers the change control process defined in the scope management plan.
• When scope variance exceeds defined thresholds: Pre-defined variance thresholds (e.g., scope completion more than 10% below plan for two consecutive periods) trigger escalated monitoring and corrective action planning.
• At phase gates: Comprehensive scope monitoring reviews are conducted at phase gate decisions to assess whether the project’s scope performance supports proceeding to the next phase.

6. Two Real-World Examples

Project Phoenix — TechCorp Website Relaunch

Alex Morgan established a weekly scope monitoring rhythm for Project Phoenix from week 1 of execution. Every Monday morning, team leads submitted a WBS completion update: percentage complete for each in-progress work package and a flag for any scope change requests received during the previous week. Alex reviewed the updates, updated the scope performance tracker, calculated earned value metrics, and published a scope status report to Sarah Chen and the steering committee by end of Monday.

In week 8, the design agency submitted a request to add animated transitions to the homepage carousel — a feature not in the WBS. The request was logged as a change request, and Alex produced an impact assessment: 16 hours of frontend development effort, no schedule impact if approved within one week, $1,800 cost addition. The change request was presented to Sarah Chen, who approved it as a minor enhancement within the project’s contingency budget. The WBS was updated, the change was documented, and the feature was added to the sprint backlog.

In week 11, quality control testing of the frontend development work package revealed that the mobile layout failed accessibility standards (WCAG 2.1 AA compliance was documented as a quality requirement in the quality management plan). The quality non-conformance triggered a corrective action plan: the frontend developer was allocated 24 additional hours to remediate the accessibility issues, and the quality retest was scheduled for week 12. The issue was resolved before the deliverable was submitted for client validation — preventing a formal acceptance failure that would have delayed the launch milestone.

Project ProjectAdm — SaaS Project Management Platform

In ProjectAdm’s agile context, Monitor and Control Scope took the form of sprint reviews, burnup charts, and backlog health monitoring. Eduardo tracked three scope metrics at every sprint review: sprint completion rate (stories completed vs. stories committed); backlog growth rate (new stories added vs. stories completed per sprint); and quality metrics for completed stories (automated test coverage percentage and defect density).

In sprint 7, the burnup chart revealed a backlog growth problem: the team was completing 12–14 stories per sprint, but 10–15 new stories were being added per sprint — the backlog was growing, not shrinking. Eduardo flagged this as a scope control issue in the sprint retrospective. Root cause analysis identified that three enterprise clients were submitting feature requests directly to the development team, bypassing the product owner triage process defined in the scope management plan. The corrective action was straightforward: the product owner communicated the triage process to the enterprise clients and blocked the direct channel to the development team. In sprints 8 and 9, backlog growth normalized, and the delivery projection returned to the committed release timeline.

7. Templates & Downloads

• Scope Management Plan Template: Download — includes the change control process and scope monitoring procedures.
• Requirements Documentation Template: Download — includes the requirements traceability matrix for scope monitoring.
• Scope Baseline Template: Download — the reference document against which scope performance is measured.

8. Five Common Errors

Error 1 — Allowing informal scope additions without change control

The most damaging scope control failure is allowing scope additions to be incorporated informally — “just this once,” “it’s a small thing,” “the client asked nicely.” Every informal scope addition bypasses the impact assessment, accumulates in the project without budget or schedule adjustment, and contributes to the death-by-a-thousand-cuts pattern of scope creep. Every scope addition — regardless of size — must go through the documented change control process.

Error 2 — Not measuring quality as part of scope monitoring

In PMBOK 8, quality is an attribute of scope. A deliverable that meets all functional requirements but fails quality standards has not met its scope. Scope monitoring that tracks only functional completeness without quality measurement is monitoring 70% of the picture. Integrate quality control measurements into scope monitoring from the start.

Error 3 — Monitoring scope without a baseline

Scope monitoring requires a reference point — the scope baseline. A team that monitors scope without an approved baseline is comparing actual performance to an informal, undocumented expectation. When disagreements arise about whether scope was delivered, there is no reference to consult. The scope baseline is not optional. Without it, scope monitoring is not monitoring — it is guessing.

Error 4 — Treating the lessons learned register as a project closure activity

Lessons learned about scope control effectiveness should be recorded throughout the project, not only at closure. When a scope dispute is resolved, document what caused it and how the resolution was reached. When a quality non-conformance is identified and corrected, document the root cause and corrective action. These in-flight lessons improve scope monitoring effectiveness for the remainder of the current project and provide valuable input for future projects.

Error 5 — Not escalating scope variances promptly

Project managers sometimes absorb scope variances internally — adjusting the team’s work informally without updating the baseline or informing the sponsor — in an attempt to avoid difficult conversations. This “silent correction” behavior eliminates the sponsor’s ability to make informed decisions about the project and creates a divergence between the documented project plan and the actual project reality. Escalate scope variances that exceed defined thresholds promptly and transparently.

9. Tailoring Considerations

10. Process Interactions

Inputs from: Develop Scope Structure (scope baseline); Plan Scope Management (scope management plan and quality management plan); Elicit and Analyze Requirements (requirements documentation); project execution (actual deliverables and work performance data).

Feeds into: Validate Scope (verified deliverables); Governance Domain’s change control processes (change requests); Assess and Implement Changes (change requests trigger this governance process); lessons learned register for future projects.

Interactions with other domains: Finance Domain (scope variances have cost implications; Monitor and Control Scope triggers cost impact assessments); Schedule Domain (scope changes affect the schedule baseline; Monitor and Control Schedule coordinates with scope monitoring on integrated change impacts); Risk Domain (scope deviations may represent realized risks or create new risks that must be assessed).

11. Quick-Application Checklist

• Scope monitoring cadence defined and communicated to the team?
• WBS completion tracking active and updated each monitoring cycle?
• Quality control measurements defined and being applied to completed deliverables?
• Every scope change request being processed through the documented change control process?
• Scope variance analysis performed at each monitoring cycle?
• Trend analysis applied to scope performance data across multiple periods?
• Root cause analysis performed for any scope variance exceeding defined thresholds?
• Quality reports produced and communicated to stakeholders?
• Lessons learned being recorded throughout execution (not deferred to project closure)?
• Scope baseline updated for all approved changes through formal change control?

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.