Develop and manage project scope

PMP ECO · Process (41%) · Task Pr2. Define exactly what the project will and won't deliver, decompose it into manageable work, and guard the boundary as you go.

What it is

Scope work runs: collect requirements → define scope → create the WBS → validate scope → control scope. The Work Breakdown Structure (WBS) decomposes the deliverables into work packages following the 100% rule (the children fully define the parent, no more, no less). The scope baseline = the scope statement + WBS + WBS dictionary. Validate Scope is the customer's formal acceptance of deliverables; Control Scope guards against creep.

Why it matters

• A clear WBS is the foundation everything else estimates against — schedule, cost, resources, and risk all decompose along it.
• The scope boundary is what turns "can you just add…" into a change request instead of silent scope creep.

Where you do it in VanillaPM

Build the WBS tree (decompose deliverables to work packages), write the scope statement, and record deliverable acceptance as work is validated. The WBS is the spine the budget, schedule, and EVM all attach to.

Walked example — Coral Ridge Resort

Coral Ridge's 44-node WBS decomposes the hotel into: design → substructure (piling to −22 m, raft & basement) → superstructure (RCC frame floors 1–5, 6–10, cores/stairs/lifts) → envelope (sea-facing curtain wall & glazing) → MEP → fit-out (guest-room sea-view stack) → commissioning (testing, snagging). Each work package rolls up cleanly to its parent (the 100% rule). Validate Scope happens per floor — the client formally accepts each completed level before fit-out proceeds.

The artefact

• WBS (+ dictionary) and scope statement — the scope baseline.
• Deliverable acceptance records — the output of Validate Scope.

Best practices & pitfalls

• Do decompose to work packages you can estimate and assign — not so fine you drown in detail, not so coarse you can't control.
• Do distinguish Validate Scope (customer accepts) from Control Quality (team checks correctness) — acceptance is the customer's, correctness is the team's.
• Pitfall: gold-plating — adding "nice" scope the customer didn't ask for. It's creep, even when well-intentioned.

On the PMP exam

Know the WBS 100% rule, work package, and the scope baseline contents. The classic trap is confusing Validate Scope (formal acceptance, a customer act) with Control Quality (inspection, a team act) — and remembering that unapproved scope changes, however small, go through change control.