Work Breakdown Structure (WBS)

The work breakdown structure decomposes a project scope into smaller, deliverable-based components. It is not a schedule, but a scope map that clarifies what must be produced and who will own each part. A good WBS provides the foundation for estimating effort, assigning responsibility, and controlling scope changes.

It defines what is in scope by listing deliverables and work packages. It improves estimation accuracy by breaking work into measurable pieces. It supports assignment and accountability across teams and vendors.

• It defines what is in scope by listing deliverables and work packages.
• It improves estimation accuracy by breaking work into measurable pieces.
• It supports assignment and accountability across teams and vendors.

• Build the WBS around deliverables, not activities or departments.
• Use consistent decomposition levels so estimates are comparable.
• Link each work package to an owner and acceptance criteria.
• Use the WBS to evaluate change requests objectively.
• Keep the WBS updated as scope is refined.

A website redesign project creates a WBS with deliverables such as information architecture, visual design, content migration, and QA. Each deliverable is broken into work packages with clear acceptance criteria. Estimates are produced at the package level and rolled up to a total budget. When a stakeholder requests a new microsite, the team evaluates where it fits in the WBS and updates scope before approving.

• A WBS is not the schedule; it is the scope structure.
• A WBS is not an org chart and should not mirror reporting lines.
• Listing tasks without deliverables reduces its value for control.