Work Breakdown Structure Examples (6 Real Templates)

The fastest way to learn a work breakdown structure is to look at one. Theory tells you a WBS is a “deliverable-oriented hierarchical decomposition of scope,” but that phrase becomes obvious the moment you see a house construction WBS split into site, foundation, and framing — and then watch the framing split into wall panels, trusses, and inspections. Real examples also expose the two design choices that shape every WBS: deliverable-based versus phase-based, and how deep to go.

This article shows six complete work breakdown structure examples across construction, software, marketing, events, and office moves — each with levels, codes, and work packages — plus the templates you can adapt, the tools to build them in, and the mistakes that turn a good structure into a bad one.

Quick Answer: What Is a Good Work Breakdown Structure Example?

A good work breakdown structure example shows the project’s final deliverable at the top, splits it into Level 1 elements that together equal 100% of the scope, breaks each into sub-deliverables, and ends in work packages that one owner can estimate, build, and track. For a website redesign, that means: Website Redesign (Level 0) → Brand, Content, Design, Photography, Build (Level 1) → mockups, copy, QA (work packages) — with every level using nouns that describe outputs, not verbs that describe actions.

The nuance is that no single example is universal. The same project can produce a deliverable-based or a phase-based WBS depending on how you organize Level 1 — and both are correct as long as they respect the 100% rule and serve the team that will use them.

What Every Work Breakdown Structure Example Has in Common

Before the examples, recognize the anatomy they all share. Understanding this structure makes any template instantly readable:

• Level 0 — the project objective. The project itself, usually the final deliverable (“Launch new mobile app”).
• Level 1 — the major deliverables or phases. The first split. In deliverable-based WBS, these are product areas; in phase-based WBS, they are lifecycle stages.
• Level 2 — sub-deliverables. Decomposition of each Level 1 element into pieces that will become work packages.
• Level 3+ — work packages. The lowest level, where cost and duration are estimated and managed. Each package has one owner, one measurable deliverable, and typically 8 to 80 hours of effort (the 8/80 rule).

Codes like `1.3.2` are not decoration; they let schedules, invoices, and reports reference exactly one element. Element numbering also exposes the depth of a structure at a glance.

Example 1: Home Construction (Deliverable-Based)

The house construction example is the classic — it appears in PMI material and in the DoD’s original WBS standards because it maps cleanly onto physical parts of a building.

• Level 0: 1.0 House Construction
• Level 1:
• 1.1 Site & Foundation
• 1.2 Structure
• 1.3 Interior
• 1.4 Plumbing & Electrical
• 1.5 Finishes
• 1.6 Project Management
• Level 2 and work packages (sample):
• 1.2 Structure
• 1.2.1 Framing
• 1.2.2 Roof trusses
• 1.2.3 Structural inspections
• 1.3 Interior
• 1.3.1 Drywall installation
• 1.3.2 Flooring
• 1.3.3 Cabinetry
• 1.6 Project Management
• 1.6.1 Permits
• 1.6.2 Inspections and sign-offs
• 1.6.3 Reporting

Note two deliberate choices. First, “Project Management” appears as a Level 1 element — management is real scope and real cost, and omitting it breaks the 100% rule. Second, “Permits” lives under Project Management, not under Site, so there is exactly one place for regulatory work and no double-counting.

Example 2: Website Redesign (Deliverable-Based)

The website redesign example is the most widely copied in software and marketing teams because it translates directly into a digital product.

• Level 0: 2.0 Website Redesign
• Level 1: 2.1 Brand, 2.2 Content & Messaging, 2.3 Visual Design, 2.4 Photography, 2.5 Build & Launch
• Work packages (sample):
• 2.3 Visual Design
• 2.3.1 Homepage mockup
• 2.3.2 Template designs (8 templates)
• 2.3.3 Mobile review and QA
• 2.5 Build & Launch
• 2.5.1 Development
• 2.5.2 QA and bug fixes
• 2.5.3 Launch and rollback plan

A good test for this example: if the team agreed on a $50,000 budget and 1,000 hours, each work package should have its own estimate — 150 hours for the homepage mockup, 100 hours for content writing, and so on. When estimates roll up to the phase and match the budget, the WBS is working as the spine of cost control.

Example 3: Mobile App Development (Deliverable-Based)

Software development is where the WBS discipline pays off hardest, because the “integration and testing” trap is most common here.

• Level 0: 3.0 Mobile App (iOS + Android)
• Level 1: 3.1 Product Definition, 3.2 Design, 3.3 Development, 3.4 QA & Testing, 3.5 Release, 3.6 Project Management
• Work packages (sample):
• 3.3 Development
• 3.3.1 Authentication module
• 3.3.2 Core screens (12 screens)
• 3.3.3 Push notifications
• 3.3.4 Payment integration
• 3.4 QA & Testing
• 3.4.1 Test plan
• 3.4.2 Automated test suite
• 3.4.3 Beta program and feedback triage

The trap this example avoids: teams often forget that building a feature is only part of the work — testing, deployment pipelines, and app-store submission are deliverables too. If your WBS ends at “development,” the release is already under-planned by 15–25%.

Example 4: Product Launch or Marketing Campaign (Phase-Based)

Marketing and product-launch projects usually follow a fixed sequence, which makes them natural phase-based WBS examples.

• Level 0: 4.0 Product Launch
• Level 1 (phases): 4.1 Planning, 4.2 Creative Production, 4.3 Campaign Setup, 4.4 Launch, 4.5 Post-Launch
• Work packages (sample):
• 4.2 Creative Production
• 4.2.1 Brand assets (logo, guidelines)
• 4.2.2 Landing page copy
• 4.2.3 Video assets (2 spots)
• 4.4 Launch
• 4.4.1 Announcement email
• 4.4.2 Press kit distribution
• 4.4.3 Paid social schedule

Phases are also a natural place for planning packages. If the campaign plan is approved but the post-launch webinar content is not yet detailed, list “4.5.1 Webinar program (planning package)” so the 100% rule still holds — you have captured the work even if you have not decomposed it yet.

Example 5: Moving an Office (Phase-Based)

An office move is the everyday project every operations manager recognizes, and it shows how a phase-based WBS handles a fixed sequence of stages.

• Level 0: 5.0 Office Relocation
• Level 1 (phases): 5.1 Pre-Move Planning, 5.2 Packing, 5.3 Physical Move, 5.4 Setup & Fit-Out, 5.5 Handover & Closure
• Work packages (sample):
• 5.2 Packing
• 5.2.1 Inventory of assets
• 5.2.2 Labeling system
• 5.2.3 Packing of non-critical areas
• 5.4 Setup & Fit-Out
• 5.4.1 IT network and phones
• 5.4.2 Furniture assembly
• 5.4.3 Cleaning and final inspection

A phase-based office-move WBS makes the milestone structure obvious: permit/lease signed, packing complete, trucks delivered, desks usable. Each phase ends with a deliverable that acts as an exit gate — which is exactly what makes phase-based structures attractive to managers who need stage-gate control.

Example 6: Event or Trade Show (Deliverable-Based)

Event management is a favorite WBS example because it combines hard deliverables (booth, printed materials) with soft ones (registration, staffing) that teams forget.

• Level 0: 6.0 Industry Trade Show (3-day booth)
• Level 1: 6.1 Booth Design & Build, 6.2 Content & Collateral, 6.3 Registration & Leads, 6.4 Staffing, 6.5 Logistics
• Work packages (sample):
• 6.2 Content & Collateral
• 6.2.1 Brochure design and print
• 6.2.2 Presentation deck
• 6.2.3 Demo script and walkthrough
• 6.4 Staffing
• 6.4.1 Booth schedule (12 shifts)
• 6.4.2 Staff training session
• 6.4.3 Lead-handoff process

The reason events deserve their own example: lead handling is usually a forgotten deliverable. “Collect 400 qualified leads” is only half the story — the follow-up email, CRM entry, and sales handoff are deliverables that belong in the WBS or they quietly never happen.

How the Examples Compare: Choosing the Right Structure

The aircraft system row is a deliberate nod to history: MIL-STD-881, the 1968 DoD standard, defines WBS for aircraft, ships, missiles, and other defense systems, with mandated common elements such as systems engineering, program management, training, and data. If your organization works in regulated domains, check whether a standard already dictates your Level 1 structure before inventing your own.

How to Turn These Examples Into a Template

You do not need to start from a blank page. Adapt the closest example in three steps:

1. Swap the Level 1 elements to match your project’s deliverables or phases. Keep the count between three and eight so the structure stays readable.
2. Reuse the recurring work packages that appear in almost every example: project management, QA and inspections, approvals, and launch or handover. These are the elements people forget most often.
3. Calibrate the depth with the 8/80 rule: keep decomposing a deliverable until each piece is roughly 8 to 80 hours of effort and fits inside one reporting period — then stop.

A quick sanity check on any adapted template: add up your Level 1 elements and confirm they equal 100% of the scope; then verify no work package appears under two parents.

A Worked Template: Corporate Website Relaunch in Numbers

Suppose you reuse the website redesign example for a corporate relaunch with a 10-week timeline and a $60,000 budget. Allocate effort across the adapted Level 1 elements: Brand updates 250 hours, Content 300 hours, Design 550 hours, Photography 150 hours, Build & Launch 350 hours — total 1,600 hours. At an average $37.50/hour blended rate, that is exactly $60,000.

Now test the 100% rule on one parent. “Design, 550 hours” must equal its children: homepage mockup 150 + 8 template designs 300 + mobile QA 100 = 550. If a designer later says “the templates need a 10th layout,” that is a scope change to element 2.3.2 — visible, costed, and requiring approval, instead of silent hours leaking into the phase. That single behavior is why the WBS earns its keep.

A second worked example: the 100-unit bicycle project

A classic illustration of the 100% rule in action comes from PMI’s practice material: a project to design and build a custom bicycle, defined as 100 units of total work (allocated by effort or cost — not duration). At Level 1 the 100 units split into seven elements; the three largest are further decomposed at Level 2. The two largest Level 3 elements each represent 17 units — 17% of the whole project.

The point of the numbers is the discipline they force. Because the WBS assigns units at every level, any proposed addition is a measurable decision: adding “custom frame painting” is moving X units from another element, or it is scope growth beyond the 100. A WBS without such numbers is a drawing; a WBS with them is a baseline you can defend.

Common Mistakes When Using a Work Breakdown Structure Example

• Copying a template without checking the 100% rule. Templates fit some projects better than others; a missing element in the template becomes a missing element in your plan.
• Mixing deliverables and activities in the same structure. Keep nouns in the WBS. The moment “write copy” appears next to “copy,” you have a task list wearing a WBS costume.
• Two parents for one work package. “Testing” under both Development and QA means double-counted effort and unclear ownership.
• Uniform depth everywhere. Real examples vary in depth by risk; a 5-level WBS for the risky payment integration and 3 levels for content is fine and preferable.
• Forgetting project management and handover work. Management, training, data, and support are legitimate deliverables in every serious example.
• Letting the example replace planning. A WBS is the scope skeleton; you still need the schedule, budget, and risk plan built on top of it.

Know This Before You Choose

• A deliverable-based example is usually safer for repeatable, product-like projects; a phase-based one is clearer when your organization runs stage gates or regulatory reviews.
• Examples from your own industry save the most time, but the anatomy — levels, codes, work packages, dictionary — transfers to any project.
• One good WBS example, properly built, typically takes half a day to adapt. Do not expect to skip the 100% rule check; that is where the value actually lives.
• Your tooling should let the structure stay connected to the schedule. If you have to maintain the hierarchy by hand in a spreadsheet, the WBS will drift out of date within weeks.
• If your domain has a standard (construction, aerospace, government), adopt its required WBS elements rather than inventing parallel ones.

Tools for Building Work Breakdown Structure Examples

• Microsoft Project — strong outline/WBS codes and direct scheduling. Pros: deep scheduling, WBS codes, industry acceptance. Cons: learning curve, per-user licensing.
• Asana or Monday.com — subtask hierarchies in list/board views. Pros: collaborative, low barrier, templates. Cons: limited WBS roll-up and coding compared to scheduling tools.
• MindView (Matchware) — mind mapping built for WBS, with export to MS Project, Word, and Excel. Pros: fast idea-to-chart, example gallery. Cons: planning focus only, separate from execution.
• Excel or Google Sheets — universal. Pros: free, portable. Cons: no dependency or cost roll-up automation.
• A unified project management platform — keeps the WBS hierarchy as the live task structure that schedules, budgets, and reports all reference. For teams that want the example to stay accurate through execution, this is the practical option. To be transparent: Doitify is our product, which is why we know its capabilities from the inside — but for a single planning exercise, a spreadsheet or mind map is perfectly adequate.

Conclusion

Work breakdown structure examples work as both instruction and template. The six structures here — construction, website redesign, mobile app, product launch, office move, and trade show — show the two design choices (deliverable versus phase) and the universal anatomy (objective, Level 1, sub-deliverables, work packages) that make every WBS useful. Copy the closest one, swap in your deliverables, and run the 100% rule.

Then let the structure do its real job: feed the schedule, the budget, and the day-to-day tracking. If you want the WBS you designed to stay the same structure your team actually executes in — with multi-level tasks, checklists, and progress reports built on it — a unified project management platform like Doitify turns that example into a living plan.