A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work required to complete a project. Starting from the top-level deliverable (the product), the WBS decomposes work into progressively smaller, more manageable work packages until each element represents a task that can be assigned, estimated, and tracked. The WBS is the foundation of project planning: it defines scope, informs schedule, drives cost estimation, and provides the structure for progress tracking.
A hardware project WBS typically has 3-5 levels. Level 1 is the product itself. Level 2 comprises major deliverables: System Engineering, Electronics, Mechanical, Software/Firmware, Testing, Manufacturing Preparation, Project Management. Level 3 breaks each deliverable into sub-deliverables: Electronics → Schematic Capture, PCB Layout, BOM Finalization, Prototyping, Bring-up Testing. Level 4 and below represent individual tasks and work packages.
The 100% rule is the fundamental WBS principle: the sum of all child elements must represent 100% of the parent work — no more, no less. Work outside the WBS is out of scope; work in the WBS that is not delivered is a scope gap. PMI's PMBOK® Guide treats the WBS as the foundation of scope management, noting that projects without a WBS struggle to control scope creep because there is no baseline to compare actual scope against.
Practical Example
WBS Level 2 for an IoT gateway product: 1.1 Systems Engineering, 1.2 Hardware — Electronics, 1.3 Hardware — Mechanical, 1.4 Embedded Firmware, 1.5 Cloud Backend, 1.6 Verification and Validation, 1.7 Manufacturing Preparation, 1.8 Regulatory Certification (FCC/CE), 1.9 Project Management.
How SpecZero handles this
SpecZero's plan sections function as a WBS: each section represents a work area with its own tasks, BOM items, notes, and files. The structured separation of requirements, concepts, decisions, and execution phases mirrors the natural WBS hierarchy of a hardware development project.
Related terms
Design Specification
A document that describes how a system will be designed to meet its requirements — the 'how' to the SRS's 'what.'
Design Decision Log
A structured record of key engineering decisions, capturing the objective, alternatives, analysis, and rationale.
Preliminary Design Review(PDR)
A design gate review that verifies the design approach is feasible and requirements are allocated before detailed design begins.
Critical Design Review(CDR)
The design gate before production build authorization — confirming the detailed design meets all requirements and is ready for manufacturing.