A work breakdown structure is a simple way to turn a big, fuzzy project into a set of pieces small enough to estimate, assign and finish. Instead of starting with a long to-do list, you start with what the project has to deliver and break it down level by level. This guide shows small teams how to build one in a single working session, with a template and a worked example.

Who this guide is for

This guide is for small business owners, studio founders and small-team leads who take on projects that feel too large to plan in one go, such as a website rebuild, a brand refresh or a new service launch. You do not need formal project management training. If you can sketch an outline, you can build a work breakdown structure.

What a work breakdown structure is

Atlassian’s guide to the work breakdown structure describes it as a way to hierarchically break a project into smaller, manageable components or deliverables. In practice, it looks like a tree or an indented outline. The whole project sits at the top. Below it are the main deliverables, and below those are smaller pieces of work.

A paper presented at a PMI Global Congress, summarising the PMI practice standard for work breakdown structures, defines it as a deliverable-oriented hierarchical decomposition of the work the team needs to do. The key word is deliverable. The structure describes what will be produced, not when or in what order. Scheduling comes later and builds on it.

Key terms in plain language

• Deliverable: something the project produces, such as a homepage design, a logo file set or a launch email.
• Decomposition: the act of breaking a deliverable into smaller parts.
• Work package: the lowest level of the structure. The PMI paper describes work packages as the components used for scheduling, estimating and assigning work.
• WBS dictionary: a companion document that explains each element, such as what is included and who owns it.

Why small teams benefit from a work breakdown structure

The tool is often associated with large programmes, but the idea scales down well. For a small team, the main benefits are practical:

• Nothing gets forgotten. Writing out every deliverable surfaces the easy-to-miss items, like content migration, image licences or a handover document.
• Estimates get easier. It is hard to estimate “build the website”. It is easier to estimate “design the contact page”.
• Ownership is clearer. Each work package can have one named owner.
• Client conversations get simpler. A one-page tree shows a client what is included in the project at a glance.

The Atlassian guide makes a similar point, noting that the structure helps with estimating, assigning responsibilities and tracking progress.

Deliverable-based or phase-based?

The Atlassian guide describes two common ways to organise the second level of the tree:

Either can work. For client projects with a clear list of outputs, a deliverable-based tree can read more clearly to the client. Whichever you choose, keep the items at each level as nouns describing outputs where possible, which matches the deliverable focus described in the PMI paper.

How to build a work breakdown structure in five steps

1. Write the project outcome at the top

Start with one line that names the finished project, for example “New studio website live”. If you ran a kickoff and wrote a mission statement, use that.

2. List the major deliverables

Ask: what are the big things this project must produce? Aim for a handful of items at level two. Include the less glamorous ones, such as project management, testing and handover. The PMI paper describes the “100% rule”: the structure should include all the work defined by the project scope, including internal and interim deliverables and project management itself. If it is not in the tree, it is not in the plan.

3. Break each deliverable down

Take each level-two item and ask what it is made of. “Website” might break into “Sitemap”, “Page designs”, “Built pages” and “Content”. Keep going until each piece is small enough that one person could own it and you could estimate it with reasonable confidence.

4. Stop at a sensible level

There is no fixed number of levels. The PMI paper notes that the right depth depends on the size and complexity of the project. For a small team, three levels is often enough. A useful test: if a work package would take one person a few days and you can describe what “done” looks like, you have probably gone deep enough.

5. Add owners, estimates and a short dictionary

For each work package, note an owner, a rough effort estimate and a one-line description of what is included. That last part is your WBS dictionary. It does not need to be formal; a simple table works. Once this is done, you can turn the work packages into tasks on whatever board or list your team already uses, and the Atlassian guide suggests linking dependencies between them at that stage.

A simple work breakdown structure template

Copy this outline into a document or spreadsheet and replace the placeholders with your own project details:

1. [Project outcome]
   1. [Deliverable A]
      1. [Work package A1] – owner, estimate, definition of done
      2. [Work package A2] – owner, estimate, definition of done
   2. [Deliverable B]
      1. [Work package B1] – owner, estimate, definition of done
      2. [Work package B2] – owner, estimate, definition of done
   3. Project management
      1. Kickoff and planning
      2. Client check-ins and reporting
      3. Handover and close

The numbering matters. Giving each item a code (1.1, 1.2, 1.2.1) makes it easy to refer to a piece of work in emails and status updates without confusion.

Worked example: a small studio’s website rebuild

Here is a hypothetical example for a four-person studio rebuilding a client’s website. The team chooses a deliverable-based structure.

• 1. New client website live
  • 1.1 Discovery outputs: 1.1.1 stakeholder notes, 1.1.2 sitemap, 1.1.3 content inventory
  • 1.2 Design: 1.2.1 style tiles, 1.2.2 homepage design, 1.2.3 inner page templates, 1.2.4 mobile layouts
  • 1.3 Content: 1.3.1 rewritten service pages, 1.3.2 image selection, 1.3.3 alt text and metadata
  • 1.4 Build: 1.4.1 page templates built, 1.4.2 forms connected, 1.4.3 redirects from old URLs
  • 1.5 Launch and handover: 1.5.1 testing checklist completed, 1.5.2 go-live, 1.5.3 client training session, 1.5.4 handover document
  • 1.6 Project management: 1.6.1 kickoff, 1.6.2 weekly client updates, 1.6.3 close-out review

Writing this out reveals two items the team had not included in the first estimate: redirects from old URLs and the client training session. Spotting those before the work starts is the main payoff of the exercise.

Common work breakdown structure mistakes

• Listing activities instead of outputs. “Meet with client” is an activity. “Approved sitemap” is a deliverable. Favour the second.
• Going too deep. Breaking work into hour-long tasks turns the structure into a to-do list that is hard to maintain.
• Leaving out project management. Meetings, updates and handover take real time and belong in the tree.
• Building it alone. The people doing the work are well placed to spot missing pieces. Review the draft together.
• Never updating it. If the scope changes, change the structure so it stays the single picture of what is being delivered.

For more ways to make planning repeatable across projects, browse our business systems articles.

Key takeaways

A work breakdown structure turns a large project into a tree of deliverables and work packages that a small team can estimate, assign and track. Start with the outcome, list the major deliverables, break each one down to a sensible depth, and give every work package an owner and a clear definition of done. Keep it focused on outputs, include project management, and update it when the scope changes so it stays a reliable picture of the work.

Written by the Design Productive Editorial desk. Disclosure: this guide contains no affiliate or sponsored links.