Work Breakdown Structure

A work breakdown structure decomposes project scope from high-level deliverables into smaller elements that can be estimated, assigned, scheduled, purchased, built, tested, and controlled. A good WBS is usually deliverable-oriented: it defines what must exist or be completed, then planning systems can attach activities, durations, resources, and dependencies.

The lowest practical level is often the work package. It should be small enough for ownership and control, but not so small that project management becomes bookkeeping. Work packages often link to cost accounts, responsibility matrices, risk registers, schedule activities, and acceptance criteria.

Engineering use

In engineering projects, a WBS can separate systems, subsystems, design packages, procurement items, test campaigns, commissioning tasks, documentation, and validation evidence. It helps reveal missing scope and prevents teams from hiding critical work inside vague summary tasks.

The WBS is not a schedule by itself. Critical path, dependency logic, resource leveling, and milestones are schedule concerns that build on the scope structure.

Control interface

The value of a WBS comes from how it connects scope to control systems. Work packages can feed cost estimates, procurement plans, earned-value tracking, document lists, interface registers, verification matrices, and change requests. When the WBS is stable and deliverable-based, teams can discuss scope growth, missing ownership, and test readiness without mixing those issues into the schedule network.

Common mistakes

A common mistake is building a WBS as a list of departments or calendar phases rather than deliverables. Another is decomposing easy technical work in detail while leaving integration, testing, documentation, approvals, and rework as vague placeholders. A strong WBS review states scope boundary, deliverable hierarchy, work-package owner, acceptance criteria, cost account, schedule interface, exclusions, assumptions, and change-control rule.