In this blog, we are going to work through the process called Monitor and Control Scope. Think of this process as the ongoing discipline of checking what is actually being built against what was agreed, and then correcting course when something drifts.
I want to start with the main outputs, because they make the purpose of this process very concrete.
One key output is verified deliverables. These are the deliverables that have been checked against requirements, acceptance criteria, and quality expectations, and confirmed to be correct. The value of verified deliverables is that they give us confidence that the scope we planned has really been implemented as intended. Only after deliverables are verified here do they move on to Validate Scope for formal customer acceptance. Without this verification step, we risk passing incomplete or incorrect work to our stakeholders, which erodes trust and leads to late rework.
To produce verified deliverables, we rely heavily on our scope baseline and our requirements documentation. The scope baseline, which includes the scope statement, WBS, and WBS dictionary, tells us exactly what the project committed to deliver. Requirements documentation elaborates what each deliverable must do or contain. These two together give us the reference to say, “Is this deliverable complete, and is it within the agreed boundaries?” We then use tools like testing and product evaluations, audits, inspections, and performance reviews to check deliverables. Tests and product evaluations compare the product’s behavior or characteristics to the requirements and acceptance criteria. Audits and inspections look more broadly at whether what has been built and how it has been built line up with scope and quality standards. Performance reviews pull together evidence from these activities and compare actual performance against what was planned. The combined value of these techniques is that they provide objective, evidence‑based confirmation that each deliverable matches the defined scope before we declare it done.
Another important output is work performance information related to scope. This is what we get after we take raw data such as test results, inspection findings, defect counts, and progress updates, and analyze them in context. Work performance information tells us which deliverables are verified, which requirements are satisfied, where we have scope variances, and how those variances are trending. The value here is decision‑ready insight. Rather than just knowing “we have ten defects,” we understand whether those defects indicate scope being missed, scope being added without approval, or quality problems that threaten the agreed scope.
The main inputs that support this output are work performance data, the scope baseline, the performance measurement baseline, and quality‑related documents like test and evaluation records and quality metrics. Work performance data gives us the raw facts: what tests passed, what failed, how many defects were logged, how many requirements are implemented. The scope baseline defines what we should be delivering, and the performance measurement baseline links that scope to schedule and cost targets so we can see whether scope issues are also impacting time and budget. Quality test and evaluation documents, combined with quality metrics, describe how we measured performance and what thresholds define success or failure. We then apply data analysis techniques such as variance analysis and trend analysis. Variance analysis compares actual results to the baseline to show where we are over‑delivering or under‑delivering scope. Trend analysis looks at how these variances change over time, so we can spot whether scope problems are getting better or worse. The value of these tools is that they convert scattered observations into a clear picture of scope health over the life of the project.
A third major output of Monitor and Control Scope is change requests. Whenever this process reveals that actual work does not match the approved scope, or that new needs have emerged, we should not silently adjust. Instead, we raise a change request. This might be to correct under‑delivery, to remove unnecessary features, or to add legitimately new scope that stakeholders now require. The value of change requests is that they keep scope changes formal and controlled, rather than allowing informal scope creep.
Inputs that feed into this output include the scope baseline, requirements documentation, approved change requests already in the system, and the work performance information we just talked about. The baseline and requirements show us the official reference; work performance information shows us the reality; and any previously approved change requests show us which modifications are already authorized but perhaps not fully implemented. When we detect gaps, overlaps, or misalignments, we then use root cause analysis to understand why. Are we seeing new requirements that were never captured? Are team members implementing unauthorized “nice‑to‑have” features? Are there misunderstandings in the requirements? Root cause analysis helps us propose the right type of change: correcting defects, clarifying requirements, adjusting scope boundaries, or improving the way we manage scope. The value of this approach is that change requests are not just reactions; they are targeted, addressing the underlying drivers of scope issues.
From these change requests and insights, we often need to update parts of the project management plan, especially the scope management plan and the quality management plan. Updates to the scope management plan capture improvements in how we will monitor, validate, and control scope going forward. For example, if we keep discovering unauthorized features late in the project, we might strengthen our change control steps or clarify decision‑making authority. Updates to the quality management plan may adjust how we will test and evaluate deliverables, or refine acceptance criteria, to better align quality checks with the true scope expectations of stakeholders. The value of these plan updates is that we are not just fixing today’s issues; we are improving the system so similar issues are less likely to occur tomorrow.
Now, let’s step back and cover the key inputs and tools we have not yet highlighted explicitly.
A central input is the scope baseline. It is indispensable because it defines, in concrete terms, what is in scope and what is not, and how that scope is structured. Without a agreed baseline, we have nothing solid to compare against; every conversation about scope becomes subjective. The scope baseline is what allows us to say, “This work package exists in the WBS, therefore it is in scope,” or, “This requested feature is not anywhere in the WBS, therefore it is new scope.”
The scope management plan, as a component of the project management plan, is another critical input. It explains how scope will be monitored and controlled, who approves changes, what variance thresholds are acceptable, and how we will confirm scope at different stages. Its value is consistency and governance. It ensures that scope decisions follow a known process instead of being handled ad hoc.
The quality management plan is also an important plan component here. It ties together the link between product scope and quality expectations. It describes the quality standards that deliverables must meet and the quality control methods we will use. Its value in Monitor and Control Scope is that it helps us interpret test and inspection results in terms of scope: whether what we built actually meets the required level of quality for the agreed scope.
Among project documents, requirements documentation is the foundation for scope checking. It spells out what the solution must deliver, often with acceptance criteria. It gives concrete meaning to the items in the WBS and the statements in the scope baseline, making it possible to trace each deliverable back to stakeholder needs. Quality test and evaluation documents, such as test plans, test scripts, and evaluation checklists, are used to verify those requirements against real deliverables. They provide structured ways to test whether scope has been fully implemented. Quality metrics define how we will measure success, for example, maximum number of defects, response times, or error rates. These metrics tell us what “good enough” looks like when we inspect scope. Approved change requests, in turn, tell us which deviations from the original baseline are legitimate. If we see a deliverable that looks out of scope, the first question is: is there an approved change that authorizes it? This prevents us from treating authorized changes as mistakes.
Deliverables themselves are, of course, a critical input. They are the tangible results of project work that we monitor and control. Without deliverables to examine, scope control is purely theoretical. By comparing deliverables to the scope baseline and requirements, we can confirm completeness, detect gold plating, and identify missing scope.
On the tools and techniques side, we have already talked about the core data analysis methods: variance analysis, trend analysis, and root cause analysis. In addition to those, performance reviews serve as structured checkpoints where we look at deliverables, test results, and scope metrics together and assess whether we are on track. These reviews are a practical way to bring the right people together to interpret the data and decide on actions.
Audits and inspections provide a more formal or sometimes independent perspective on how scope is being managed and whether deliverables comply with scope and quality standards. Their value lies in uncovering issues that may not be visible in day‑to‑day monitoring and in reinforcing adherence to agreed processes. Testing and product evaluations focus on the behavior and characteristics of the product itself, confirming that the implemented scope really meets the documented requirements.
Data representations, such as traceability matrices, charts, or visual status dashboards, help communicate scope status and change impacts clearly to stakeholders. They make it easier to see which requirements are satisfied, which are at risk, and how changes in one area affect others. Finally, process automations, such as requirements management tools, workflow systems for change control, and automated reporting, support this entire process by reducing manual effort and error. They can automatically update traceability links, enforce approval steps, and generate scope reports, making scope monitoring more efficient and more reliable.
By using these inputs and tools in a disciplined way, Monitor and Control Scope ensures that what the team is building remains tightly aligned with what was agreed, that changes are handled formally, and that scope problems are caught early. The outputs—verified deliverables, clear work performance information, well‑justified change requests, updated plans, and documented learning—are what allow the project to deliver the right product, to the right level of completeness and quality, without uncontrolled scope creep.
