Validate Scope vs Control Scope: What’s the Difference?
Two of the scope processes sound close enough that teams run one and believe they have run both. Validating scope concerns what has been produced: somebody with the authority to do it accepts a completed deliverable against criteria agreed beforehand. Controlling scope concerns what is being produced: noticing when work is drifting or being added, and deciding what happens about it.
The two meet at handover, which is where a team that has done only one of them finds out.
Two different questions
Validation asks whether this is acceptable. It faces the customer, it produces a decision, and the decision belongs to somebody named. It differs from quality control, which asks whether the thing is correct and is an internal check. A deliverable can pass every internal test and still be rejected by a customer who wanted something else, and both of those facts are useful information about different problems.
Control asks whether what is being built is still what was agreed. It runs continuously, produces no artefact of its own in most weeks, and its output is either confirmation that nothing has moved or the identification of something that has. On predictive work the reference is the scope baseline. On adaptive work it is the ordered backlog and the outcome statement. Either way, something has to exist for the comparison to be made against.
A team running acceptance without control learns about drift when a deliverable is rejected, by which point the work is done and paid for. A team running change control without acceptance reaches the end with no signed confirmation that anybody was satisfied, and discovers it when the final invoice is queried.
What each one needs to work
Section 2.2.2 of the PMBOK® Guide Eighth Edition carries both of them as named processes within the scope work, and what each needs is different enough to be worth stating separately.
Acceptance needs three things. Criteria agreed before the thing was built, because criteria written afterwards are a negotiation and not a test. A named accepting authority who can say yes, which is not the same as somebody who will take the document away to somebody who can. And a record, because acceptance is the evidence that a commitment was met, and a deliverable accepted in a corridor conversation has been accepted by nobody as far as a contract is concerned.
Control needs two. A boundary somebody can point at, whether that is a baseline or an outcome statement with an exclusion list beside it. And a trigger, some routine moment at which the comparison actually happens, because drift does not announce itself. Nobody submits a change request for work that was never recognised as a change.
The cabinet nobody asked for
A gas distribution business was replacing pressure reduction stations across a region, eleven of them across two years, each handed over to the operations team as a discrete deliverable. The contract was clear, the configuration was standard, and acceptance was a joint inspection at handover with a signed certificate.
At station seven the site engineer asked the contractor's supervisor, in good faith and on site, whether a telemetry cabinet could be added while the kiosk was open, because the existing arrangement left him blind to a valve he cared about. The supervisor agreed, the cabinet went in, and the cost was small enough that nobody raised it commercially.
The handover inspection accepted station seven as complete. It checked that everything worked and that the installation matched the drawings issued for construction, and those drawings had been marked up to show the cabinet, so nothing looked out of order. What nobody compared it against was the authorised configuration.
The consequences turned up across the following year. The cabinet came from a different manufacturer from the standard, so it sat outside the maintenance contract and outside the spares holding. Two further stations acquired one, because a supervisor who had done it once saw no reason not to. The operations team finished up maintaining three non-standard installations on a regional asset base built around a single configuration, and unpicking that cost a great deal more than three cabinets.
The repair was one line added to the acceptance check: the handover inspection compares the installation against the authorised configuration, and not only against the drawings issued to site. Validation and control met at the same table, which is where they belong.
For a PMP® candidate, the distinction is worth carrying because situations are frequently built on it. A customer refusing to accept a deliverable that meets its specification has an acceptance-criteria problem, and it points back to what was agreed before build. Work appearing in a deliverable that nobody authorised is a control problem, and acceptance is where it surfaces rather than where it was caused. The thing to establish is which of the two questions a situation is really asking: is this acceptable, or is this what we agreed to build? Practising on situations that could plausibly be either is what a structured PMP exam preparation course uses to sharpen the distinction.
Put the comparison into the acceptance meeting. Whoever accepts a deliverable should have the authorised scope in front of them alongside the specification, and should be asked a second question after the first: is everything here supposed to be here? On most projects the answer is yes. On the ones where it is not, handover is the last cheap chance to find out.
Interested in going further?
Acceptance is where uncontrolled scope becomes permanent, because after a signature it stops being a change and becomes an asset somebody has to maintain for fifteen years. Omega's PMP® Exam Preparation works through situations where the two scope questions have to be answered separately.
Validation and control of scope are both described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A103: Requirements vs Scope: Why the Difference Matters
A104: Acceptance Criteria: The Small Detail That Prevents Big Arguments
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
