What's changed: Initial version
1.3Scope definition and the WBS
Covers requirements gathering, which elicits requirements from stakeholders; the scope statement, which puts the boundary of the deliverables into writing; the WBS (work breakdown structure), which decomposes work hierarchically, and its smallest unit, the work package; and the 100% rule a WBS must satisfy—framed as the judgment skill of preventing ambiguity and gaps in requirements.
Scope management is not a field of memorizing "what a WBS is"; it tests the ability to judge, in a situation where stakeholder requirements are ambiguous or subject to misalignment, how to put them into writing and decompose them into work without gaps. Starting a project while requirements remain ambiguous invites later disputes—"surely this is in scope," "no, it's out of scope"—that become fertile ground for scope creep. This is a field that tests the judgment skill of appropriately executing the sequence of requirements gathering -> putting them into writing via the scope statement -> decomposing the work via the WBS, depending on the situation.
1.3.1Requirements gathering and the scope statement
- Requirements gathering is the activity of clarifying stakeholder needs using techniques such as interviews, workshops, surveys, and prototyping. Expectations and priorities often differ from one stakeholder to another, and when the gathered requirements conflict with one another, reconciling that conflict is also part of requirements gathering.
- The scope statement is the document that puts into writing the boundary of the project's deliverables and work, clarifying what is included in scope and what is explicitly excluded. Rather than relying on "implicit understanding," it leaves the agreed-upon boundary as a written record, playing the role of preventing later misalignment or disputes.
1.3.2The WBS, work packages, and the 100% rule
- The WBS (work breakdown structure) is a diagram that hierarchically subdivides a project's entire scope, organized around deliverables or phases. The lowest level of decomposition is called a work package, which becomes the base unit for schedule creation, cost estimation, and work assignment. The principle is to decompose in a deliverable-oriented way, which differs from a mere list of work steps (a process chart).
- The 100% rule is the principle that at every level of the WBS, the sum of the child elements must cover 100% of the parent element's scope—no more, no less. If the sum of the child elements is less than the parent, there is a gap in the work; if it is more, it means out-of-scope work has crept in. Adhering to the 100% rule turns the WBS itself into a means of verifying the completeness of the scope.
Most-tested: the WBS decomposes in a deliverable-oriented way, with a work package as the lowest level; the 100% rule means the sum of child elements covers the parent's scope with neither gap nor excess. Watch for questions that test judging, from a WBS decomposition that conflicts with the requirements, whether it is a gap or an intrusion of out-of-scope work.
Suppose you are the PM of a project to build a new e-commerce site, and during requirements gathering, sales wants "payment to support not just credit cards but also convenience-store payment," while development insists "the first release should be credit-card only, with convenience-store payment pushed to the next phase"—the two stakeholders' requirements are in conflict. If you proceed with the project while leaving both sides' positions ambiguously juxtaposed, a later misalignment can arise—"surely convenience-store payment was in scope for the first release"—potentially escalating into a dispute over something never put into writing in the scope statement. The action the PM should take is to first draw out the underlying purpose behind each stakeholder's position (sales wants to broaden customer acquisition; development wants to strictly meet the release timeline), then present an adjustment proposal that accounts for priority and the constraint of the deadline, and build agreement. For example, phrasing it as "the first release will be credit-card only, and convenience-store payment support is recorded in the scope statement as an explicit scope item for the next phase" puts the exclusion into writing, organizing both parties' expectations along a timeline rather than rejecting either one, and preventing a later dispute. When translating the agreed scope into the WBS, if you place only a "credit card payment" work package under the parent element "payment functionality" and do not include convenience-store payment, that is, under the 100% rule, a state of "correctly covering 100% of the first release's payment-functionality scope"—not including convenience-store payment is not itself an error. Conversely, if a work package for convenience-store payment support has crept into the WBS despite never being recorded in the scope statement, that is a 100% rule violation from out-of-scope work intruding, and is a sign that correction is needed.
| Situation | Interpretation under the 100% rule | Action to take |
|---|---|---|
| The sum of child elements is less than the parent's scope | A gap in the work | Add the missing work package(s) |
| The sum of child elements exceeds the parent's scope | Intrusion of out-of-scope work | Reconcile against the scope statement and exclude or reclassify |
| The sum of child elements matches the parent's scope | A sound decomposition satisfying the 100% rule | None in particular (keep the next-phase treatment in writing) |
Trap: "When stakeholders' requirements conflict, incorporating everything both sides want resolves the scope problem" is wrong—leaving a conflict ambiguously juxtaposed tends to escalate into a later misalignment, so an adjustment that accounts for priority and constraints, along with putting exclusions into writing, is needed. Also wrong: "the lowest level of the WBS can be decomposed as finely as one likes"—a work package should be at a granularity usable for schedule creation, cost estimation, and progress tracking; excessive decomposition only raises management overhead without necessarily being beneficial.
1.3.3Section summary
- Requirements gathering surfaces conflicts among stakeholders, and the scope statement puts the in-scope boundary and exclusions into writing to prevent misalignment
- The WBS decomposes hierarchically in a deliverable-oriented way, and the lowest-level work package becomes the base unit for estimation and progress tracking
- The 100% rule verifies whether the sum of child elements covers the parent with neither gap nor excess, distinguishing between a gap and an intrusion of out-of-scope work
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. On a new e-commerce site project, sales wants convenience-store payment support in the first release, while development argues for deferring it to the next phase. What is the most appropriate PM response?
Q2. In a WBS, only a "credit card payment" work package is placed as a child element under the parent element "payment functionality," and the scope statement records convenience-store payment as an explicit exclusion deferred to the next phase. Which explanation of this state is most appropriate?
Q3. Which explanation of the 100% rule in a WBS is most appropriate?