Defining scope turns stakeholder needs into a clear description of what a project will deliver and what lies outside its boundaries. Creating a work breakdown structure, or WBS, then decomposes those deliverables into manageable parts. These are closely related planning activities, but they answer different questions: the scope statement describes authorized outcomes and constraints, while the WBS organizes the deliverable-oriented work needed to create them.
A well-defined scope can still change when new information or an approved request justifies it. The objective is not to freeze every implementation detail. It is to make acceptance, responsibility, estimates and change decisions understandable so the project manager and stakeholders know what has been authorized.
Start from the charter and requirements
Review the business justification, charter, stakeholder needs, constraints and assumptions before drafting a scope statement. Requirements should be understandable and traceable to a business outcome. A request such as ‘make the system easy to use’ needs a measurable interpretation if it will become a delivery or acceptance criterion.
For a fictional nonprofit creating an appointment-scheduling application, the charter might authorize a service enabling approved volunteers to schedule visits. Requirements interviews reveal different users: coordinators create capacity, volunteers request slots and administrators need an audit trail. The project must identify which of those capabilities belong in the first authorized release.
Separate requirements that the product must satisfy from a chosen technical implementation. A requirement to protect personal details does not, by itself, mean the project must purchase a particular vendor product. Define the required control and evaluate feasible implementations under procurement and security constraints.
Describe included and excluded deliverables
A scope statement can identify the product’s expected capabilities, major deliverables, acceptance criteria, exclusions, dependencies, assumptions and constraints. A named exclusion protects clarity only if stakeholders understand it. An exclusion should not conceal a missing contractual or legal obligation.
In the appointment project, included deliverables might be account registration, available-slot management, booking confirmations, role-based access and an operational handover. Exclusions might include mobile native apps, payment processing and integrations with external hospital records. These boundaries can guide estimates and help review new requests.
A successful scope statement is specific enough to test but not so prescriptive that it removes legitimate implementation choices. It should identify what ‘complete’ means without requiring the team to predict every technical task before discovery begins.
Translate scope into a deliverable-oriented WBS
A WBS decomposes the total project scope into deliverable-oriented components, continuing until a level of work can be estimated and controlled appropriately. A work package represents the lowest level used for that purpose in the project plan. The 100% rule means the WBS should represent all authorized project work without including unauthorized extra scope.
A simple WBS for the scheduling service could include project management and governance, requirements and design, identity and access, scheduling capabilities, user-facing communications, testing and acceptance, deployment, and operational handover. Each branch can be decomposed into smaller deliverables or work packages.
The WBS is not merely a chronological to-do list. ‘Hold three meetings’ is an activity rather than a deliverable; ‘approved requirements baseline’ is an identifiable output. Activities and sequencing belong in schedule planning after the deliverables and work packages are understood.
Use a WBS dictionary to make work packages actionable
A WBS dictionary can record the component identifier, description, owner, dependencies, acceptance evidence, estimate assumptions and relevant constraints. The description should prevent two teams from assuming that the same work is included in different packages or omitted entirely.
For example, ‘booking confirmation’ could mean an on-screen success message, an email, or both. The dictionary might state that an email must be sent after a booking is saved and that delivery failure is logged for follow-up. That clarity improves estimation and later acceptance.
Package ownership also affects integration. A team responsible for user authentication and another for booking may need an agreed interface contract. The WBS should show the corresponding deliverables, while dependency management records the order and technical relationships required for implementation.
Apply the 100% rule without double counting
Trace every approved scope item to at least one appropriate WBS component. If data migration is within scope but appears nowhere in the decomposition, the plan is incomplete. If the same testing deliverable is counted under two branches and estimated twice, the project may overstate cost and effort.
The 100% rule does not mean creating a new work package for every small activity. Excessive decomposition can produce administrative overhead and make changes difficult to control. Choose a level where accountable teams can estimate, report progress and demonstrate completion.
Inspect cross-cutting work such as security, training and documentation. It is easy to overlook these because they serve many product components. Decide whether they are separate deliverables or included in the definition of done for other work packages, and document the choice.
Connect the scope baseline to later control
A scope baseline generally includes the approved scope statement, WBS and WBS dictionary under the applicable planning approach. New requests should be assessed against that baseline and the project’s approved change-control process. The baseline is an authorized reference, not a prohibition on justified learning.
Suppose the nonprofit asks to add payment processing after design is complete. The project manager should estimate security, cost, contractual and schedule consequences, determine who has authority to approve the request, and update affected deliverables if accepted. Simply adding a branch to the WBS would not be an authorized scope change.
The broader project scope management framework covers all scope activities from planning through acceptance. The focused scope validation and change control discussion addresses the governance after a deliverable has been defined and built.
A worked scope-to-WBS check
Ask three questions about each deliverable: Is the business outcome clear? Does the WBS include every authorized part and no unwanted addition? Is there evidence a customer can use to accept the result? For the booking service, a test may require a user to reserve one available slot, see the capacity decrease, and receive the intended confirmation.
Review the decomposition with product owners and delivery teams. A missing access-control deliverable, ambiguous handover ownership or unrecognized data retention requirement is more important than whether the diagram uses exactly four levels.
The durable skill is turning stakeholder needs into authorized, testable outcomes and organizing the work without confusing deliverables, implementation tasks and later scope changes. That makes estimates, responsibilities and eventual acceptance easier to defend.