Work Breakdown Structure (WBS): How to Create One with Example and Template

A work breakdown structure becomes valuable when a project looks organised on paper but still feels difficult to control in practice.

The scope may be approved, deadlines may exist and teams may already be assigned, yet planning can quickly turn into a long task list with unclear boundaries and missing deliverables.

A well-built WBS solves that problem by translating project scope into a clear hierarchy of deliverables and manageable work packages.

In WBS project management, this structure creates the foundation for estimating, scheduling, budgeting and assigning responsibility.

This guide from LOTC explains how to build a work breakdown structure in project management that covers the full scope, reaches the right level of detail and supports reliable planning and control.

A work breakdown structure in project management turns the approved project scope into a hierarchy that teams can understand, estimate and manage. The complete project sits at the top, followed by major deliverables, smaller sub-deliverables and, at the lowest useful level, individual work packages that can be planned and controlled.

This explains the practical WBS meaning: it organises the full scope around what the project must produce, with each descending level adding more detail. PMI similarly describes the WBS as a deliverable-oriented hierarchical decomposition that defines the total project scope.

A WBS should not be confused with the project schedule:

In WBS project management, this distinction matters: the WBS provides the structural foundation, while scheduling determines how and when that work will be carried out.

Organise a WBS by decomposing the project scope progressively until each branch reaches a level that can be estimated, assigned and controlled without unnecessary detail.

WBS Levels and Decomposition

Typical work breakdown structure levels move from the complete project to increasingly specific deliverables:

1. Level 1: Project
2. Level 2: Major deliverables
3. Level 3: Sub-deliverables
4. Lowest useful level: Work packages

This hierarchy is illustrative, not a fixed rule. A simple project may need only a few levels, while a complex programme may require deeper decomposition in some branches than others. The right level is the one that gives the team enough visibility to plan and control the work without turning the WBS structure into a catalogue of minor tasks.

The 100% Rule and Work Packages

A strong WBS also follows the 100% Rule: the components beneath any parent element should represent all of that element’s scope—no missing work and no duplicated scope.

If a deliverable is divided into four sub-deliverables, those four together should account for the complete deliverable.

The lowest manageable element is a work package. It should be defined clearly enough to estimate cost and effort, assign responsibility, derive schedule activities and recognise when the expected output is complete.

PMI guidance on work breakdown structures treats the 100% Rule and appropriate decomposition as core principles for developing and evaluating a WBS.

Build the work breakdown structure from the project scope outward, not from a list of activities. The aim is to define everything the project must deliver, then decompose that scope only as far as necessary to manage it effectively.

1. Start with the Project Scope and Major Deliverables

Begin with the project objectives, approved scope boundaries, requirements, project charter or scope statement, and the major outcomes expected by the customer or organisation.

At this stage, identify the principal deliverables that collectively represent the project. LOTC’s guide to project planning provides useful context on how scope, deliverables and planning fit together before detailed scheduling begins.

2. Decompose Deliverables into Manageable Components

Break each major deliverable into smaller components by asking:

What must exist or be completed for this deliverable to be accepted?

This keeps the WBS focused on outputs. Asking “What tasks should the team do?” too early often produces an activity list instead of a true deliverable hierarchy.

Continue decomposing until the team can clearly see what each branch is expected to produce.

3. Stop When the Work Package Is Manageable

Do not decompose indefinitely. A useful work package should be specific enough to:

• Estimate effort and cost

• Assign clear responsibility
• Derive schedule activities
• Monitor progress

• Confirm when the expected output is complete

If the element is still too broad to estimate or assign confidently, decompose it further. If it has become a collection of tiny actions, the WBS has probably gone too far.

4. Test the WBS Before Using It

Review the structure with the people responsible for delivery. Check whether:

• The full project scope is represented

• Work appears only once
• No out-of-scope deliverables have been introduced
• Work packages have clear boundaries
• Similar branches are decomposed to sensible levels

• The structure remains manageable for the project team

Once approved, incorporate the WBS and WBS dictionary into the project’s scope baseline and manage subsequent changes through formal change control. Any authorised scope change should be reflected in the structure so that planning, cost estimates and accountability remain aligned.

Learning how to create a WBS is therefore less about drawing boxes and more about making the project scope visible, complete and manageable.

A work breakdown structure example becomes useful when it shows how a real project moves from a broad objective to clearly defined deliverables without turning the WBS into a task list. Consider an office relocation project that must move employees, technology and operations into a new workplace with minimal disruption.

Office Relocation Project

1.0 Office Relocation

1.1 Premises Ready

• 1.1.1 Approved workspace design

• 1.1.2 Completed fit-out

• 1.1.3 Furniture and facilities ready

1.2 Technology Ready

• 1.2.1 Network infrastructure

• 1.2.2 User equipment

• 1.2.3 Access and security systems

1.3 People and Move Readiness

• 1.3.1 Approved move plan

• 1.3.2 Employee communications

• 1.3.3 Workspace allocation

1.4 Operational Handover

• 1.4.1 Acceptance records

• 1.4.2 Outstanding issues register

• 1.4.3 Handover documentation

In this simplified WBS, the Level 3 elements serve as the work packages at the lowest useful level of each branch.

This WBS example works because every branch describes an output the project must produce. “Technology Ready”, for example, represents a required project outcome; the network, equipment and access systems are the components needed to achieve it.

Activities such as configure laptops, install desks, send relocation notices or book the removal company do not belong at this level. Those actions are derived later when work packages are converted into schedule activities.

The numbering also shows the relationship between each element and its parent. In a visual WBS chart or work breakdown structure diagram, the same hierarchy could be presented as connected boxes rather than an outline; the underlying scope would remain unchanged.

A good example should therefore let the project team answer three questions quickly: What must the project deliver? Where does each piece of scope belong? Has anything been omitted or counted twice? If those answers are unclear, the structure needs further decomposition or refinement before detailed planning begins.

A work breakdown structure template should help the team organise scope consistently without forcing every project into the same number of levels. The structure below can be copied into Excel, project software or project documentation and expanded only as far as the project requires.

Copyable WBS Template

Use the WBS template to show scope relationships, not to turn the hierarchy into a schedule. Owners, deadlines, dependencies and detailed activity dates can sit in the WBS dictionary, responsibility matrix or project schedule instead of crowding the core WBS chart.

What Is a WBS Dictionary?

A WBS dictionary adds the detail that cannot fit cleanly inside a short deliverable name. It gives each work package a shared definition so that different teams interpret its boundaries, expected output and completion criteria in the same way.

A practical WBS dictionary template may include:

The combination matters: the work breakdown structure shows where each piece of scope belongs, while the WBS dictionary explains what that piece actually means. Together, they reduce ambiguity before work is estimated, scheduled or assigned.

Use the WBS as the structural bridge between project scope and the detailed planning that follows. It does not replace the schedule, budget, risk register or responsibility framework; it gives each of them a consistent view of the work that must be delivered.

Once clear work packages exist, the project team can use them to:

• Define the activities needed to produce each deliverable

• Estimate cost, effort and resource requirements
• Assign responsibility for defined portions of scope
• Identify risks and dependencies at a manageable level
• Trace approved scope changes to the affected work

• Measure progress against clearly defined outputs

This creates an important planning sequence: the WBS establishes what must be delivered; scheduling determines how and when the work will occur; budgeting determines the resources and cost required; and accountability clarifies who coordinates or owns each element.

A strong WBS therefore supports project planning without becoming the plan itself. As the LOTC project-management cluster develops, this same foundation can connect naturally to Critical Path Method, Project Cost Estimation and Project Change Control.

Where role clarity is needed, a RACI matrix can clarify who is Responsible, Accountable, Consulted and Informed for key work packages, deliverables and decisions.

Review the WBS before relying on it for scheduling, estimating or control. Small structural weaknesses at this stage can become missing work, duplicated effort or unclear ownership later in the project.

Common problems include:

• Building a task list instead of a hierarchy of deliverables

• Leaving parts of the approved scope outside the structure
• Placing the same work under more than one branch
• Decomposing some areas into excessive detail while leaving others too broad
• Assuming every project requires the same number of WBS levels
• Developing the structure without input from people who understand the work
• Using vague work packages without enough detail in the WBS dictionary

• Failing to revise the WBS after approved scope changes

A quick quality check is to select any work package and ask:

• What output does this element produce?

• Where does its scope begin and end?
• Who can estimate and coordinate it?
• How will completion be recognised?

• Does it overlap with another element?

If the team cannot answer these questions consistently, the work package probably needs further definition. A strong WBS should make scope easier to understand and control, not simply make the project look more detailed.

A useful WBS depends on more than knowing how to draw a hierarchy. Project teams also need to define scope clearly, translate deliverables into workable plans and understand how changes in one area affect schedule, resources and control.

LOTC develops these capabilities through:

• Project Management Fundamentals, covering project lifecycles, scope, WBS, planning and control.

• Essential Skills for Project Scheduling and Planning, developing practical capability in scheduling, dependencies, critical paths and resource constraints.

LOTC can also tailor corporate training around real projects and planning challenges. Speak to the LOTC team on WhatsApp to discuss the right programme.

A well-built WBS does not make a project less complex; it makes that complexity visible and manageable.