Project Scope and Work Breakdown
Scope definition
Scope is defined by the scope statement: product scope (features of what is delivered) and project scope (the work to deliver it). It sets inclusions and exclusions - explicit exclusions prevent later disputes. Scope creep is uncontrolled addition without change control; gold plating is the team adding unrequested features. Both erode the baseline.
Building the WBS
A work breakdown structure is a hierarchical decomposition of the total scope into deliverables, not activities. Each level is more detailed; the lowest level is a work package, sized so it can be estimated, assigned and controlled - commonly the "8/80 rule" (between 8 and 80 hours). The 100% rule states the WBS captures all scope and no more: children sum exactly to the parent. A WBS dictionary records each package's description, acceptance criteria, owner and estimate.
Traps in questions
- WBS organised by org chart or by phase-only when deliverables are required; either may be valid, but the question usually tests the deliverable orientation and the 100% rule.
- Activities placed directly in the WBS without a work package parent.
- Confusing a deliverable (noun, a thing) with a task (verb, work).
- Forgetting that scope verification uses formal acceptance of deliverables against criteria.
Rule of thumb
Decompose until a package can be estimated within roughly ±10% and owned by one person. If two people own it, split it.
Worked example: A website project's WBS level 2 includes Design, Build, Content, Launch. Build decomposes to Front-end and Back-end work packages. "Write homepage copy" sits under Content, not at level 2, and the sum of all packages equals the full scope with nothing outside the tree.