Validating and Controlling Scope

Delivered Is Not the Same as Accepted

You can build something exactly to specification, on time and on budget, and still have the client refuse it. Not because the work was wrong, but because nobody formally confirmed what "done" meant before delivery. This gap, between completing work and getting that work officially accepted, is where a surprising number of projects stumble in their final weeks. Two processes exist specifically to close it. Scope validation ensures that completed deliverables are formally accepted by the client or sponsor. Scope control ensures the project scope doesn't quietly expand beyond what was agreed in the first place. One protects the close. The other protects the whole project lifecycle. Both depend on the same starting point: agreement on what the scope actually is before work begins.

Scope Validation: Getting Formal Acceptance

Scope validation is the process of getting formal acceptance of completed deliverables from the client or sponsor. The word "formal" is carrying significant weight there. An informal "looks good" in a meeting is not scope validation. A nod of approval during a demo is not scope validation. A signed acceptance document, produced after the client has reviewed the deliverable against the agreed scope statement, requirements, and acceptance criteria, and confirmed that the work meets what was agreed, that is scope validation. The output is a record of accepted deliverables, a formal confirmation that the client acknowledged the work as complete and conforming. Without that record, the project does not have documented evidence of what was accepted, when, or by whom.

The core activity in scope validation is inspection. The client, sponsor, or their designated representative reviews the deliverable against the agreed criteria and makes a determination: this meets what was specified, or it doesn't. When the answer is yes, the acceptance is documented. When the answer is no, the gap is identified, and the project works to close it. This is different from quality control, which verifies that deliverables conform to quality standards. Scope validation verifies that the right things were built, that the deliverable is what was agreed, not just that it was built well. A deliverable can pass quality control and still fail scope validation if the client's understanding of what was promised and the team's understanding of what was built never fully aligned.

The acceptance record does not need to be elaborate, but it needs to exist. At minimum it should capture:

The Definition of Done

Scope validation is only clean when everyone agreed on what "done" looks like before the work started. That is where the Definition of Done comes in. The Definition of Done is a set of criteria that must be met for a deliverable to be considered complete. It is not a wish list, and it is not a general description of quality. It is a precise, shared standard: these specific conditions must all be true before this deliverable is declared finished. For a software feature, done might mean the code is written, tested, deployed to staging, and signed off by the business analyst. For a physical deliverable, done might mean installed, tested, and inspected. For a document, done might mean authored, reviewed, approved, and distributed. Whatever the criteria are, they need to be agreed by the team, the PM, and the client before the work begins, not after it is delivered for review.

When this definition is shared from the start, scope validation becomes a confirmation rather than a negotiation. The client reviews the deliverable against the same criteria that guided the team. Either the criteria are met or they are not. There is a clear answer and a clear path forward in either direction. Projects that skip this step often discover the problem at the worst possible moment: the client's first detailed look at the deliverable, when the team believes the work is complete and the project is in its final days. Defining "done" in advance costs almost nothing. Defining it in a dispute costs considerably more.

Acceptance Criteria: One Level Deeper

Acceptance criteria are related to the Definition of Done but more specific. Where the Definition of Done describes general completion standards for a type of deliverable, acceptance criteria define exactly what conditions a particular deliverable must meet before the client will sign off on it. They are deliverable-specific, testable, and agreed in writing before the work begins. For a customer portal module, the acceptance criteria might specify maximum page load time, successful completion of defined user scenarios, accessibility compliance to a particular standard, and zero open critical defects. Each criterion is binary: met or not met. That precision is what makes acceptance conversations productive rather than subjective.

Setting acceptance criteria after delivery is the root of most scope disputes. Both sides thought they agreed. They did not, or they agreed to different things at different levels of detail. The client had a more specific picture than what was captured in the requirements. The team built what the requirements said and expected acceptance. The gap between those two positions is not resolved by either party being unreasonable. It is caused by a planning step that was not completed. The fix is to define criteria explicitly, in writing, with the client's sign-off, as part of scope planning. Then validate against those criteria at delivery. The conversation at acceptance should be about confirming that documented criteria were met, not discovering what the criteria should have been.

Scope Control: The Ongoing Protection

Scope control is different from scope validation. Validation is about confirming what was built. Scope control is about protecting the scope from growing beyond what was agreed, throughout the entire project lifecycle, from planning through close. You are monitoring the project for signs of scope creep: work being done or requested that falls outside the agreed scope boundary. The tools here include variance analysis, comparing what is actually in scope against what is being delivered or requested. When something falls outside the boundary, the response is not to absorb it. A change request goes in, the impact is analyzed, and a decision is made by the right person with authority to make it. That is the connection between scope control and integrated change control.

Scope creep almost never comes from bad actors. It comes from good intentions. A developer adds a feature the client would probably want. A team member fixes something they noticed while working on something related. A stakeholder mentions a need in a passing conversation and someone on the team interprets it as direction. None of those people meant harm. Each addition consumed time and budget allocated to the approved scope. Something that was planned may not get done as a result, or the project may arrive at its deadline with a cost overrun that nobody can attribute to a single decision because the decisions were never made formally. Controlling scope means catching these additions before they accumulate, not after they have already cost the project a measurable amount.

The following signals are worth checking at every weekly review:

• Team members are doing work that cannot be traced to a requirement or work package.
• A stakeholder makes a request framed as "while you are there" or "it's just a small thing."
• A vendor is delivering something that substitutes for, or adds to, the agreed deliverable.
• Repeated small fixes are being made outside the agreed acceptance criteria.
• An undocumented assumption has quietly become a work item.
• A team member says "I just did it because it seemed faster" to explain unplanned work.

Validation and Control Working Together

Scope validation and scope control reinforce each other throughout the project lifecycle. If scope has been controlled tightly throughout execution, scope validation becomes straightforward. The deliverable matches the agreed scope because nothing was added without a formal decision. If acceptance criteria were defined clearly from the start, validation becomes a check rather than a debate. The projects that end in disputes over what was delivered almost always skipped one or both of these. The scope grew without formal approval, or the acceptance criteria were unclear, or both. The projects that close cleanly almost always did both well.

The investment in both processes is front-loaded. Defining acceptance criteria takes time in planning. Maintaining scope control discipline through execution requires attention at every status cycle. But the cost of that investment is fixed, and the cost of skipping it is variable in the worst way, highest at the most inconvenient moment, concentrated at the end of the project when budget and schedule are already under pressure and the client's patience for surprises has run out.

What's Next

The next chapter, Controlling the Schedule and Cost, moves into the two baselines that most sponsors watch most closely. How schedule variances get diagnosed, what recovery tools are available and what they each cost, and how cost control works as an ongoing discipline rather than a monthly reporting exercise.

Reflect

• On your most recent project, were acceptance criteria for each major deliverable defined in writing before the work began? Where they were not, how did that affect the acceptance conversation at delivery?
• Think about a deliverable that required more rework than expected at acceptance. Was the gap caused by quality (the work was built poorly) or scope (what "done" meant wasn't fully agreed)? How would you distinguish between the two in future projects?
• Where does scope creep tend to enter your projects? Is it usually through stakeholder requests, team member initiative, or unclear boundaries in the original requirements? What monitoring approach would catch it earlier?
• Have you worked on a project where scope was tightly controlled throughout execution? What did the acceptance process feel like compared to a project where scope grew informally?