Creating a Work Breakdown Structure

Introduction

The Work Breakdown Structure or WBS is one of the most important artifacts that can be
created in support of project management. The purpose of the WBS is to map the entire
scope of the project under management. Below you will find a step by step process for the
creation of a WBS, along with some rules and recommendations to assist it creating it.

Layout of a WBS

The WBS is typically presented as a tree diagram or an outline/list format, organized in levels
from broad to specific. Each level represents a more detailed breakdown of the work.
Key Components and What Each Section/Line Represents

 Level 1: Project Objective/Title

 What it represents: The entire project or its main goal (e.g., "Build a Website").
 This is the topmost level, encompassing the whole scope of the project.

 Level 2: Major Deliverables or Phases

 What it represents: High-level deliverables, phases, or major components of the
project (e.g., "Planning," "Design," "Development," "Testing").
 These are the main categories of work needed to achieve the project objective.

 Level 3 and Below: Work Packages and Tasks

 What it represents: Smaller, more specific tasks or work packages that make up
each deliverable or phase (e.g., under "Design," you might have "Create
Wireframes" or "Select Color Scheme").
 These are actionable units of work that can be assigned, tracked, and completed.
 Lower levels break tasks into even finer details if needed (e.g., "Create
Homepage Wireframe" under "Create Wireframes").

Level 2 of a WBS is the most important. It is this line that establishes how the rest of the WBS
unfolds.

To decide the best configuration for Level 2 we must apply some simple rules:

Set of Rules for Configuring the First Line of a WBS

These rules serve as decision-making criteria to guide the choice of the Level 2 layout. They
are prioritized to help users systematically evaluate their project and select the best
approach.
 Rule 1: Ensure 100% Coverage of Project Scope
 The first line must include all work required to achieve the project’s goal, with no
gaps or overlaps (the “100% Rule”).
 Why: A complete first line prevents missing critical tasks or duplicating efforts.
 Example: For a website project, “Website Design” and “Development” alone are
incomplete without “Content Creation” and “Testing.”
 Rule 2: Prioritize Deliverables for Outcome-Focused Projects
 Use deliverables (tangible outputs like “Website,” “Event Setup”) as the first line
when the project is defined by specific products or results.
 Why: Deliverables align with stakeholder expectations, especially for clients or
projects where outcomes are the primary measure of success.
 When to Apply: Projects with clear outputs (e.g., software development, event
planning, construction).
 Example: For an event, use “Venue Setup,” “Catering,” “Entertainment” instead
of team roles like “Logistics.”

 Rule 3: Use Departments for Team-Driven or Process-Focused Projects

  Use departments (functional areas like “Marketing,” “IT”) when the project
revolves around distinct team roles or internal processes.
 Why: Department-based structures clarify responsibilities in organizations with
siloed teams or when tracking team contributions is critical.
 When to Apply: Projects where team expertise or internal coordination is the
primary focus (e.g., corporate initiatives, IT rollouts).
 Example: For a training program, use “HR,” “Training Team,” “IT Support” to
reflect team responsibilities.
 Rule 4: Use Phases for Sequential or Process-Driven Projects
 Use project phases (e.g., “Initiation,” “Design,” “Execution”) when the project
follows a clear lifecycle or sequential process.
 Why: Phases align with project management methodologies and help track
progress in structured projects.
 When to Apply: Projects with distinct stages, such as construction, engineering,
or Waterfall-based projects.
 Example: For a building project, use “Design,” “Construction,” “Handover.”
 Rule 5: Match the Structure to Stakeholder Needs
 Choose a first line that is intuitive for the primary audience (e.g., clients, team
members, executives).
 Why: A structure that resonates with stakeholders improves communication and
buy-in.
 When to Apply:
 Use deliverables for clients or external stakeholders who care about
results.
 Use departments or phases for internal teams familiar with organizational
roles or processes.
 Example: A client prefers “App Features” and “Launch” (deliverables), while a
team might prefer “Development Team” (departments).
 Rule 6: Limit First-Line Components to 3–7
 Keep the number of first-line components manageable to avoid complexity.
 Why: Too many components make the WBS unwieldy; too few make it vague.
 When to Apply: If a deliverable-based first line has 10+ components, consider
grouping them (e.g., combine “Content” and “Graphics” into “Creative Assets”).
 Example: For a marketing campaign, use “Strategy,” “Creative,” “Media,”
“Execution” instead of listing 12 specific outputs.
 Rule 7: Ensure Scalability for Decomposition
 The first line must allow for logical breakdown into smaller tasks without forcing
overly granular or vague sub-levels.
 Why: A scalable first line makes the WBS easier to develop and manage.
 When to Apply: Test the first line by drafting a few sub-tasks. If decomposition
feels forced, revise the structure.
 Example: “Website Design” breaks down into “Wireframes,” “Layouts”;
“Marketing Activities” is too vague and harder to decompose.
 Rule 8: Avoid Mixing Structures at the First Line
 Use a single structure (deliverables, departments, or phases) for the first line to
maintain consistency.
 Why: Mixing structures (e.g., “Website Design” and “IT Team”) can confuse
stakeholders and complicate task breakdown.
 When to Apply: Reserve hybrid approaches for lower levels or use them only if no
single structure fits.
 Example: Instead of mixing “Venue Setup” and “Marketing Team,” choose
deliverables like “Venue Setup,” “Promotion.”
 Rule 9: Validate with Project Scope and Stakeholders
 Cross-check the first line against the project scope statement and confirm with
stakeholders to ensure alignment.
 Why: Validation prevents scope creep or misalignment with expectations.
 When to Apply: Always review the first line with key stakeholders before
finalizing.
 Example: If the scope includes “user training,” ensure a deliverable like “Training
Materials” is included.
  Rule 10: Default to Deliverables Unless Specific Conditions Apply
 When in doubt, start with deliverables as the first line, as they are versatile and
widely applicable.
 Why: Deliverables are outcome-focused, stakeholder-friendly, and adaptable to
most project types.
 When to Apply: Use deliverables unless the project is clearly process-driven,
team-driven, or phase-based.
 Example: For a website, default to “Design,” “Development,” “Content” unless
departments like “IT” are explicitly required.

1. Level 1- Define the Project Goal

What to Do: Clearly articulate the project’s purpose and final deliverable in one or two
sentences. This ensures everyone understands the end goal.

How to Develop It:

Gather Input: Consult with key stakeholders (e.g., clients, project sponsors, or team leads) to
confirm the project’s scope and objectives.

Use a Project Charter: If available, refer to a project charter or scope statement to define the
goal. If not, create a simple statement.

Ask Questions: What is the project trying to achieve? What does success look like?

Avoid Ambiguity: Ensure the goal is specific. For example, instead of “Plan an event,” say
“Organize a successful corporate conference for 200 attendees by December 15.”

Example: For a project to build a website, the goal might be: “Launch a fully functional e-
commerce website for a clothing brand by March 1, 2026.”

Tip: Write the goal at the top of your WBS to keep it visible as you develop the structure.

2. Level 2 - Identify Major Deliverables

What to Do: A Work Breakdown Structure (WBS) breaks a project into smaller parts. Level 1 is
the whole project (e.g., "Build a House"). Level 2 is where you decide how to organize the
main chunks of work. For a beginner, think of Level 2 as the big categories you split the
project into. Here are the different ways to organize Level 2 information, explained simply:
 By Phases (Steps of the Project)
 Split the project into the major steps or stages it goes through.
 Example: For "Build a House," Level 2 could be:
 Planning
 Design
 Construction
 Inspection
 Use this when the project has clear stages over time.
 By Deliverables (Main Outputs)
 Split the project into the key things you need to produce or deliver.
 Example: For "Build a House," Level 2 could be:
 Foundation
 Walls
 Roof
 Plumbing
 Use this when the project is focused on creating specific items or results.

 By Components (Parts of the Project)

 Split the project into its main physical or functional parts.
 Example: For "Build a House," Level 2 could be:
 Exterior (outside structure)
 Interior (inside rooms)
  Electrical System
 Landscaping
 Use this when the project can be divided into distinct sections or systems.
 By Teams or Functions (Who Does the Work)
 Split the project by the groups, departments, or roles doing the work.
 Example: For "Build a House," Level 2 could be:
 Architects
 Builders
 Electricians
 Plumbers
 Use this when different teams handle specific parts of the project.

Key Point
Each way organizes Level 2 differently, depending on what makes sense for the project. You
pick the method that helps you manage the work clearly. For example:
 A software project might use phases (Planning, Coding, Testing).
 A product launch might use deliverables (Website, Ads, Product).
 A big event might use components (Venue, Catering, Entertainment).

How to Develop It:

Brainstorm with the Team: Hold a brainstorming session with your project team or
stakeholders to list the big “buckets” of work. Use sticky notes, a whiteboard, or a
collaborative tool like Miro or Trello.

Use the Project Scope: Refer to the project scope or requirements to ensure all key
deliverables are captured.

Focus on Outcomes, Not Tasks: Deliverables are tangible results, not actions. For example,
“Website Design” is a deliverable, while “Design homepage” is a task.

Group by Phases or Categories: Organize deliverables by project phases (e.g., planning,

execution, closure) or functional areas (e.g., marketing, technical, logistics).

Limit to 3–7 Deliverables: Too many deliverables at this level can make the WBS unwieldy. Aim
for a manageable number.

Example: For the e-commerce website, major deliverables might include:

Website Design

Website Development

Content Creation

Testing and Launch

Tip: Validate deliverables with stakeholders to ensure nothing critical is missed and that they
align with the project goal.

3. Level 3 - Break Down Deliverables into Smaller Tasks

What to Do: Decompose each major deliverable into smaller, actionable tasks or sub-
deliverables. Continue breaking tasks down until they are small enough to be assigned,
estimated, and managed effectively.

How to Develop It:

Use a Hierarchical Approach: Start with each deliverable and ask, “What needs to happen to
complete this?” Break it into smaller pieces, then repeat for each piece.
Apply the 8/80 Rule: Tasks should take between 8 and 80 hours to complete (or 1–10 days,
depending on your project). If a task is too big (e.g., >80 hours), break it down further. If it’s
too small (e.g., <8 hours), it may be too granular.

Involve Subject Matter Experts: Work with team members who have expertise in each
deliverable to ensure tasks are realistic and comprehensive. For example, a web developer
can help break down “Website Development” into specific coding tasks.

Consider Dependencies: Identify tasks that depend on others being completed first (e.g., you
can’t test the website until it’s built).

Use Action-Oriented Language: Start task names with verbs like “Design,” “Build,” “Test,” or
“Write” to make them clear and actionable.

Example: For the “Website Design” deliverable, tasks might include:

1.1 Create wireframes

1.2 Design homepage layout

1.3 Develop color scheme and branding

1.4 Review designs with client

Tip: Stop breaking down tasks when they are clear, assignable, and can be completed by one
person or a small team in a reasonable timeframe.

4. Level 4- Assign Task Details

What to Do: Add key details to each task to make the WBS a practical tool for project
execution.

How to Develop It:

Assign Responsibilities: Identify who will perform or oversee each task. Use names, roles, or
teams (e.g., “Marketing Team” or “John, the web designer”).

Estimate Time and Resources: Estimate how long each task will take and what resources (e.g.,
budget, tools, materials) are needed. Use historical data or expert input for accuracy.

Identify Dependencies: Note which tasks must be completed before others can start. For
example, “Develop homepage code” depends on “Design homepage layout.”

Include Milestones: Mark key checkpoints or deadlines (e.g., “Client approves wireframes by
February 1”). Milestones are zero-duration events that signify progress.

Use a WBS Dictionary (Optional): For complex projects, create a separate document (WBS
dictionary) to describe each task in detail, including scope, deliverables, and acceptance
criteria.

Example: For the task “Create wireframes”:

Responsible: Web Designer (Sarah)

Estimated Time: 16 hours

Resources: Wireframing tool (e.g., Figma), client branding guidelines

Dependency: Client provides branding guidelines first

Tip: Use project management software (e.g., Asana, Microsoft Project) to track these details or
create a simple table in Excel.

5. Organize the WBS Visually

What to Do: Present the WBS in a clear, visual format to make it easy to understand and
share.

How to Develop It:

Choose a Format: Common formats include:
Tree Diagram: Shows hierarchy like a family tree (best for visual learners).

Outline/List: Uses numbered lists (e.g., 1.1, 1.2) for simplicity.

Table: Lists tasks with columns for details like responsible person, duration, and
dependencies.

Use Tools: Create the WBS using software like Microsoft Excel, Visio, Lucidchart, or project
management tools like Trello, Jira, or [Link].

Follow a Naming Convention: Use a numbering system (e.g., 1.0, 1.1, 1.1.1) to show hierarchy
and make referencing tasks easier.

Keep It Clean: Avoid clutter. Include only essential information in the visual WBS, and use a
WBS dictionary for additional details if needed.

Example: A tree diagram for the website project might look like:

Website Project
├── 1. Website Design
│ ├── 1.1 Create wireframes
│ ├── 1.2 Design homepage layout
│ └── 1.3 Develop color scheme
├── 2. Website Development
│ ├── 2.1 Code homepage
│ └── 2.2 Integrate payment system
└── 3. Testing and Launch
├── 3.1 Test website functionality
└── 3.2 Launch website

Tip: Choose a format that your team and stakeholders find easy to read and use.

6. Review and Refine

What to Do: Validate the WBS with your team and stakeholders to ensure it’s complete,
accurate, and practical.

How to Develop It:

Conduct a Review Session: Share the draft WBS with the team, client, or stakeholders. Walk
through each deliverable and task to confirm they cover the entire project scope.

Check for the 100% Rule: Ensure the WBS includes all work required to achieve the project
goal (no gaps) and avoids overlap between tasks.

Test for Clarity: Ask, “Can someone unfamiliar with the project understand each task?” If not,
clarify task names or add details.

Look for Missing Tasks: Ask team members if any steps are overlooked. For example, did you
forget “Train staff on website maintenance”?

Refine Based on Feedback: Update the WBS to address feedback, such as adding tasks,
adjusting time estimates, or clarifying dependencies.

Example: During review, the client might point out that “Content Creation” needs a task for
“Write product descriptions,” which was initially missed.
Tip: Iterate until everyone agrees the WBS is complete and realistic.

7. Use the WBS for planning.

The WBS becomes the foundational document for many later artifacts required by the PMO,
including but not limited to:

a) Network Diagram
b) Critical Path
c) Gannt Chart
d) Budget
e) Resource Requirements Document