Domain: Scope

Scope is the performance domain where a project decides what it will deliver and how everyone will know it was delivered. In the PMBOK® Guide, Eighth Edition, from PMI®, the Scope domain holds six processes, and two of them carry new names that change how you think about the work. On an owner's construction project, scope is spread across a program, drawings, specifications, a contract and several separate contracts. This lesson shows how the six processes pull those pieces into one baseline, using the Northgate case.

Learning outcomes

• Name the six processes of the Scope performance domain in PMBOK Guide 8 and the focus area where each one mainly sits.
• Explain how requirements, the scope statement and the scope structure (usually a work breakdown structure) combine into a scope baseline.
• Tell Validate Scope apart from Monitor and Control Scope, and say who does each on a CCDC 2-2020 project.
• Draw Northgate's scope boundary between Halvorsen's Contract Price, the Consultant's services and the owner's separate work.

The lesson

What the Scope domain covers

PMI lists seven performance domains in the 8th edition: Governance, Scope, Schedule, Finance, Stakeholders, Resources and Risk. Lesson 3 showed how the domains cross the five focus areas, and lesson 17 covered Governance, which owns the change process that Scope relies on. The Scope domain answers two questions: what are we delivering, and to what standard? Commentators summarize it as the project's boundaries plus its quality expectations, and that pairing is useful. A scope that says "warehouse" without saying how high, how flat or how fire-protected is not yet a scope.

The six processes

Figure 1 shows the six processes in the order a predictive project usually meets them. Four sit mainly in the Planning focus area and two in Monitoring and Controlling. The 8th edition treats processes as non-prescriptive, so you choose how much of each to use when you tailor (see lesson 5).

Plan Scope Management sets the rules: who writes requirements, what form the scope statement takes, which breakdown structure the project uses, how deliverables are accepted and how scope changes are handled. On a building project much of this is decided by the delivery method and contract, so the plan often reads as a short list of decisions rather than a long document.

Elicit and Analyze Requirements replaces the 6th edition's Collect Requirements. The new verbs are deliberate. Requirements are rarely lying around waiting to be collected; they have to be drawn out of people who know the operation, then tested for conflicts, ranked and traced. A requirement is a condition the finished product must meet, such as a clear height or a dock count.

Define Scope turns the analyzed requirements into a scope statement: the deliverables, what is excluded, the acceptance criteria, and the assumptions and constraints behind them. Exclusions matter as much as inclusions. Most owner-side scope fights start with something nobody wrote down as out.

Develop Scope Structure replaces Create WBS. The new name allows for a backlog or other structure on adaptive work, but a predictive building project still uses a work breakdown structure: a hierarchy of deliverables in which each level holds all of the work of the level above, and nothing more. That is the 100% rule. The lowest level is the work package, where cost and duration are estimated and managed. A WBS dictionary describes each element so its boundary is not left to the title.

Together, the approved scope statement, the scope structure and its dictionary form the scope baseline. It changes only through the approved change process.

Validate versus control

The two Monitoring and Controlling processes are often confused. Validate Scope is the owner formally accepting finished deliverables against the acceptance criteria. Monitor and Control Scope is the ongoing check that the work being done matches the baseline, with any difference raised as a change request and decided through Governance. Validation is about acceptance; control is about drift. Neither is the same as quality control, which checks that a deliverable is built correctly before it is offered for acceptance.

Predictive, adaptive and in between

The building shell at a distribution centre is predictive work: the scope is fixed before tender and changes are priced. Some owner work around it is not. Warehouse management software, security systems and office layouts often settle late, and a ranked backlog with a fixed budget can suit them better than a frozen WBS. Lesson 4 covers how to choose per work package. The Scope domain works for both; only the structure and the timing of acceptance change.

Northgate worked example

Northgate Distribution Centre (fictional) is a 12,000 m² tilt-up warehouse in Vaughan, Ontario, for Northgate Logistics Inc. (fictional), with a 9.75 m clear height, ESFR sprinklers, a 900 m² two-level office mezzanine, 14 docks and 2 drive-in doors on a 2.6 ha site. It is design-bid-build: Ridgeline Architects Inc. (fictional) designs under an OAA 600 agreement, and Halvorsen Builders Ltd. (fictional) builds under CCDC 2-2020 for a Contract Price of $34,950,000. See the Northgate fact sheet.

Where the scope boundary sits

The owner's scope baseline is bigger than Halvorsen's contract. Figure 2 shows the three main containers. The racking installation that starts at M10 on Monday January 17, 2028 is under a separate owner contract, so it is in the project's scope but outside the Contract Price. The scope statement has to say so, and the interfaces between containers need their own acceptance criteria.

Tracing one requirement

Take the 9.75 m clear height. It is a requirement, not a design choice: it comes from how high Northgate Logistics wants to stack pallets, and it drives the panel height, the joist depth, the sprinkler design and the racking layout. Figure 3 traces it from need to acceptance. Each row is something the owner's team can point to and check.

If any row is missing, the requirement can be lost. A drawing that shows 9.75 m with no acceptance test leaves Ridgeline and Halvorsen to argue about where to measure from. A scope statement that does not mention the racking interface leaves the owner's racking contractor to discover a sprinkler main in the way in January 2028.

Validating in stages

Validate Scope does not have to wait for the end. On Northgate, the owner can accept deliverables at the milestones that already exist: the slab at M4 (Friday May 14, 2027, with a flatness check before racking anchors are designed), the erected panels at M5, the weathertight building at M6, and the full Work at Ready-for-Takeover, M9, on Friday January 14, 2028. Each acceptance uses the criteria written in Define Scope. Under CCDC 2-2020 the Consultant reviews the Work and the owner decides; the scope domain simply asks that the criteria exist before the review.

Owner's move

• Write requirements in operating terms first. Pallet heights, truck counts and shift patterns come before drawings. Give Ridgeline the requirements, not a sketch of the answer.
• Put exclusions in the scope statement. List every owner's separate contract and what each one excludes, starting with racking.
• Keep the owner's WBS and map to it. The fact sheet's ten level 2 elements are the owner's structure. Ask Halvorsen to map the P6 WBS to them so cost, schedule and scope report on the same codes.
• Attach an acceptance test to each key requirement. Clear height, slab flatness, dock count and sprinkler acceptance each need a measurable test and a named reviewer.
• Route every scope change through Governance. Site instructions, RFI answers and "small" requests all go through the change process in lesson 17.

Common mistakes

1. Treating the drawings as the requirements. Drawings are one answer to the requirements. Without the requirements, nobody can test whether the answer is right.
2. Building the WBS by trade or by activity. A trade list leaves owner work, interfaces and commissioning in the gaps. Decompose by deliverable and apply the 100% rule.
3. Confusing validation with quality control. The contractor's inspections check the work is built right; validation is the owner accepting it.
4. Letting scope creep through RFIs. An RFI answer that adds work is a change, whatever it is called.
5. Leaving separate contracts out of the baseline. If racking is not in the owner's scope baseline, its interfaces are not in anyone's.

Quick quiz

1. Which 8th edition process replaced Create WBS?

   1. Define Scope
   2. Develop Scope Structure
   3. Plan Scope Management
   4. Validate Scope

2. "The warehouse must have 9.75 m clear height" is best described as:

   1. A work package
   2. A requirement
   3. A change request
   4. A WBS dictionary entry

3. Northgate's owner formally accepts the slab at M4 against written flatness criteria. Which process is this?

   1. Validate Scope
   2. Monitor and Control Scope
   3. Define Scope
   4. Elicit and Analyze Requirements

4. Under the 100% rule, the child elements of a WBS element must:

   1. Each cost the same
   2. Add up to all of the parent's work and nothing more
   3. Match the contractor's trades
   4. Be scheduled in sequence

5. The racking installation at Northgate is:

   1. Inside Halvorsen's Contract Price
   2. Outside the project scope
   3. In the project scope but under a separate owner contract
   4. Part of Ridgeline's services

Show answers and explanations

1. B. Develop Scope Structure replaced Create WBS, and allows a backlog or other structure where a WBS does not fit.
2. B. It is a condition the finished product must meet. The WBS elements and work packages deliver it.
3. A. Validate Scope is formal acceptance of a completed deliverable against its acceptance criteria.
4. B. Each level holds all of the work of the level above, with no gaps and no extra work.
5. C. Racking is an owner's separate contract starting at M10. It belongs in the owner's scope baseline, not in the Contract Price.

Key terms

Scope performance domain

The PMBOK Guide 8 domain covering what the project delivers and the standard it must meet, through six processes.

Requirement

A condition or capability the finished product must meet, drawn out of stakeholders and traced to a deliverable and a test.

Scope statement

The description of deliverables, exclusions, acceptance criteria, assumptions and constraints.

Scope structure

The breakdown of all the project's work. On predictive work it is a work breakdown structure; on adaptive work it may be a backlog.

Work package

The lowest level of a WBS, where cost and duration are estimated and managed.

Scope baseline

The approved scope statement, scope structure and WBS dictionary, changed only through the change process.

Scope creep

Work added without an approved change, often through instructions or RFI answers.

References

1. Project Management Institute, PMBOK® Guide, Eighth Edition (product page: principles, seven performance domains, November 2025 publication).
2. PMExams, The full PMBOK 8 process map in reader order (process names by domain).
3. Elizabeth Harrin, Rebel's Guide to Project Management, Project performance domains explained (updated for PMBOK 8) (2026).
4. 4PMTI, What is the PMBOK 8th edition? Principles, domains, focus areas, and what changed.
5. Ricardo Vargas, PMBOK Guide 8th edition processes flow (40 processes; 19 in Planning).
6. Wikipedia, Work breakdown structure (100% rule, work packages, WBS dictionary).
7. BRC Academy, Northgate fact sheet (fictional case study).

Verified on November 6, 2026.

Next lesson in this trackDomain: Schedule