Work Breakdown Structures on Hardware vs Other Project Types: A Side-by-Side for Delivery Leads
Hardware WBSs decompose differently from software, campaign, or services WBSs. A heavy side-by-side for delivery managers running their first hardware build at a startup, with corrective patterns when the imported template fails.
A hardware WBS imported from software practice will miss half the work
The first hardware WBS at a software-trained startup is usually a software WBS with concrete poured on top.
Delivery managers at startups frequently encounter their first hardware project after years of software work. Cloud-native habits run deep, and the WBS habits do too. The first instinct — apply the same decomposition logic that worked on software — produces a WBS that's missing entire branches of work.
The expansion pattern on hardware projects is most often driven by these missing branches surfacing during execution. Each missing branch becomes a change order, a delay, or a budget conversation that nobody planned for. This comparison is for the delivery manager who's just been handed a hardware build and wants to avoid importing the wrong template.
The four columns below cover the project types most commonly compared. Read column 'Hardware/Construction' first; the others are present so you can see exactly where your software or campaign instincts will mislead you.
| WBS branch | Hardware/Construction | Software | Campaign | Services/Implementation |
|---|---|---|---|---|
| Procurement and supply chain | Major top-level branch — components, equipment, materials, with lead times | Minor — cloud accounts, vendor contracts | Minor — talent, venues, paid media slots | Moderate — consultant time, system access |
| Site or environment preparation | Major top-level branch — demolition, utilities, access, foundations | Not applicable | Minor — venue setup | Minor — system access setup |
| Permits, inspections, regulatory | Major top-level branch — multiple stages, named authorities | Minor — security review, compliance | Minor — legal review, regional approval | Moderate — compliance, audit |
| Build/production work | Branch — physical assembly, with safety constraints | Largest branch — code, infrastructure, integration | Largest branch — creative production | Branch — system configuration |
| Testing and commissioning | Major top-level branch — load testing, safety certification, sign-off | Branch — automated tests, manual QA | Branch — review cycles, A/B testing | Branch — UAT, defect resolution |
| Training and adoption | Branch — operator training, safety briefings | Branch — user enablement, documentation | Branch — sales enablement, internal comms | Major top-level branch — change management |
| Handover and operations | Major top-level branch — defect liability, spares, maintenance contracts | Branch — runbooks, on-call setup | Branch — handoff to BAU marketing | Major top-level branch — operational ownership |
| Decommissioning of existing | Branch — when applicable, for replacement projects | Branch — sunset of legacy systems | Not applicable | Branch — legacy process retirement |
Reading the table
The table is structured to expose where the work actually lives in each project type. The cells use 'major top-level branch,' 'branch,' 'minor,' or 'not applicable' to indicate scale. A major top-level branch is something that should appear at level 1 of the WBS — sibling to 'build' and 'launch.' A branch is something that should appear at level 2. Anything called 'minor' is a line item or two; 'not applicable' means it doesn't exist in that project type.
Reading down column 'Hardware/Construction,' the procurement, site preparation, permits, testing/commissioning, and handover branches are all top-level. That's five top-level branches that don't exist as such in any other column. A delivery manager importing a software WBS will collapse all five into one or two lines, and the project will quietly absorb the work — usually until it's too late.
The corrective is structural: when starting a hardware project, write the WBS from the hardware column, not from your previous template. Use the table as a checklist for what should be a top-level branch.
When this matters most
The comparison matters most in the first hardware project at a software-trained startup. The team's instincts are wrong in specific, expensive ways, and the easiest corrective is to make the differences explicit before they become cost overruns. A 30-minute conversation walking through the table can save weeks of late-stage rework.
- Pre-WBSWalk the table with the team30 minutes. Identify which branches your team's existing template covers and which it doesn't.
- WBS draftBuild top-level structure from the hardware columnThe major top-level branches in the hardware column become the top-level branches of your WBS. Don't import a software template's top-level structure.
- Week 4Compare actual work to WBSAre people doing work that doesn't appear in the WBS? Where? That's where your team's habits are still importing the wrong template.
- Week 8Re-baseline if neededIf significant work has surfaced that wasn't in the original WBS, re-baseline now rather than at the end. Use the comparison table as evidence in the sponsor conversation.
The deeper asymmetry
The four project types differ on a single underlying axis: how much of the work happens in the physical world vs the conceptual world. Hardware sits almost entirely in the physical world; software sits almost entirely in the conceptual world. The branches that exist in hardware WBSs and not software WBSs are the branches that translate physical-world work into project-manageable scope: procurement, site, permits, commissioning, handover.
None of these are optional on hardware projects. They can't be 'figured out as we go,' the way certain software work sometimes can. A late integration discovery on software costs days; a late discovery that you don't have a permit costs weeks or months and may stop the project entirely.
This is why the WBS for hardware is heavier than the WBS for software, even when the projects are nominally similar in budget or duration. The heaviness isn't ceremony; it's calibrated to the asymmetric cost of late discovery.
The reverse case
If you're a hardware-trained PM moving to your first software project, the reverse adjustments apply. Procurement and site work disappear; testing and commissioning shrinks; integration and operations grow. The mistake to avoid is over-engineering — applying hardware-grade discipline to software work where it's not needed.
The symmetry is real. Each direction has its own adaptations to make. The mistake is assuming the WBS structure transfers without translation. It doesn't. For the executive software WBS template that this comparison is partly written against, see the executive software WBS template; for adjacent retrospective work on implementation projects, see twelve WBS mistakes on implementation projects; for the upstream scope statement work on startup hardware, see five scope statement mistakes on startup hardware builds.