Here’s a quick truth. Before writing this article, I stumbled on Akin’s laws, which aptly summarize work breakdown structures. The fun “law” reads: It's called a Work Breakdown Structure because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it. This law is clear and true!
Jokes aside, while studying to acquire my project management degree, I found an instructive note in the PMBOK guide. The guide, which is a go-to source for project managers, warns that “no project should be without a WBS.”
Without a work breakdown structure (WBS), your projects have a high chance of exceeding their deadlines and budgets, and not meeting stakeholder expectations. You want none of these.
So, in this guide, I’ll lean on my experience as a project management professional to share what I’ve learned about work breakdown structures. You’ll also get insights from industry experts who will help you learn about WBS.
Table of Contents
According to Jeffrey Pinto, an author and professor, the WBS is a planning mechanism for knowing the interrelationship of various activities in a project. In its simplest form, the WBS looks like you see in the template below:
Elements of Work Breakdown Structure
Based on what I learned from Pinto, every WBS has at least four levels in project management.
However, if your project is complex, you’ll have more sub-deliverables, and your work package will continue increasing.
Here are the four levels of a WBS for a simple project.
| Level |
WBS Term |
Description |
| Top-Level/Level 1 |
Project |
The overall project under development |
| Level 2 |
Deliverable |
The major project components |
| Level 3 |
Sub-deliverable |
Supporting deliverables |
| Level 4 (Activity) |
Work package |
Individual project activities |
To illustrate, I will explain these levels with the WBS for a marketing conference.
Top-Level/Level 1
The top level of the WBS covers the entire project scope. It’s also the final deliverable, which outlines what I want to accomplish. For this project, the top level is a “marketing conference plan.”
Level 2
The second level of the WBS outlines the major project components. It also reduces the project scope into units that serve as deliverables.
Deliverables include features for products or phases for tasks. My project is a series of eight tasks. You’ll notice I numbered each deliverable at this level (and for the lower levels).
This is a deliberate element, which is absent from some WBS I’ve seen.
Pro tip: Numbering a work breakdown structure helps with clarity, organization, and tracking. With numbering, I have a logical and visual way to know the relationship between deliverables, sub-deliverables, and work packages. This makes it easy to find a work element, especially for a large project.
Level 3
The third level of the WBS is the sub-deliverable. Each sub-deliverable is a component of the main deliverable you will provide to your stakeholders.
When considering an item as a sub-deliverable, a consideration is the ease of managing it. For instance, the sub-deliverable, researching potential venues (2.1), fits this bill.
Why? It is manageable. I can assign some hours to it. The cost is minimal.
If you’re making your own WBS, definitely use a template to get you started.
Activities
The last level of the WBS is activities. Think of activities like atoms. They are the smallest elements within a sub-deliverable or deliverable.
For instance, to deliver the event planning and strategy, I will need to execute the following activities:
- 1.1 Define objectives and goals
- 1.1.1 Conduct a kickoff meeting with stakeholders
- 1.1.2 Draft a list of measurable goals
- 1.1.3 Finalize objectives in a project charter
- 1.2 Identify target audience
- 1.2.1 Conduct market research
- 1.2.2 Create audience personas
- 1.2.3 Validate personas with stakeholders
- 1.3 Develop event theme and branding
- 1.3.1 Brainstorm theme ideas
- 1.3.2 Design logo and branding materials
- 1.3.3 Approve theme and branding with stakeholders
- 1.4 Set a budget and allocate resources
- 1.4.1 Identify key expense categories
- 1.4.2 Create an initial budget plan
- 1.4.3 Get budget approval from stakeholders
- 1.5 Create project timeline and milestones
- 1.5.1 Draft a detailed project schedule
- 1.5.2 Identify key milestones
- 1.5.3 Share the timeline with the team
Benefits of Using WBS in Project Management
While learning about the WBS, some of my peers didn’t appear convinced. Some argued that it’s great on paper but unapplicable in real-life situations. For others, its benefits outweigh the flawed thinking of not having one.
So, how does a WBS actually help?
A WBS prevents scope creep.
Every stakeholder is on the same page when there’s a WBS.
Without one, stakeholders can continue adding to the project until it becomes unmanageable. Once this happens, you’ll need to revisit your timelines, milestones, budget estimates, risks, etc. I wouldn’t like this to happen, especially when handling multiple projects.
In the waterfall environment characterized by a sequential approach to project execution, the benefits of a WBS in avoiding scope creep will be undebatable.
However, in Agile environments without fully defined end products, some experts argue stakeholders will change their minds on what they want, when, and why.
While this negates the value of a WBS, one expert argues that Agile teams shouldn’t use the excuse of agile to not plan and risk having scope creep.
“While I get that a full waterfall style WBS would be necessary in a construction project, they [agile teams] can't go complete no estimates on projects with inter-team dependencies, multi-fiscal-quarter delivery dates, and anything more than five team members.”
“At a minimum, all requirements of the end product should be documented, a roadmap of all major deliverables should be communicated, they should be doing some equivalent of a WBS for the next two weeks of work and ideally up to the end of the next milestone, and a rough outline of how everything else is going to come together,” they add.
A WBS aids project budget estimation.
A work breakdown structure isn’t just a planning tool — it helps with budgeting. By breaking my project into detailed activities, the WBS makes it easy to assign budgets.
Budget overruns remain a pervasive issue in project management. In a BCG survey of 403 respondents, 49% said over 30% of their organization’s technology development projects exceeded their budgets. Tech projects use Agile because of the flexibility and iterative progress it offers.
While I understand that a pre-established budget runs against the Agile mindset, incorporating a WBS into sprint planning helps. Assigning budgets at the sprint level allows teams to remain adaptable while maintaining financial discipline.
A WBS captures all work packages.
I’ve found that creating a WBS forces me to think critically about every aspect of a project. From major milestones to granular deliverables, each work package is accounted for. This not only helps visualize the scope of the project but also ensures nothing is overlooked.
But before penning down every package, talking to stakeholders is vital. Not doing so is one reason for the recent and monumental failure of the High-Speed Rail 2 in the United Kingdom.
According to Tejvan Pettinger, an economist, “[High-Speed Rail 2] risks being a £50 billion white elephant and a monument to poor planning.”
Pettinger didn’t suggest that the HS2 team didn’t have a comprehensive WBS — however, he makes a verifiable claim of constant changes to the project scope.
And as we’ve established, when this happens, the project gets derailed on almost all fronts and the team has to return to the drawing board.
Types of WBS in Project Management
There are two types of WBS:
- Deliverable-based work breakdown structure.
- Phase-based work breakdown structure.
Deliverable-Based WBS
A deliverable-based WBS gets tangible outcomes (deliverables) for stakeholders.
What I like about this WBS is its focus on “what to do” over “how to do” a task. As such, this WBS is easy to modify, simple for estimating cost, and provides a complete view of the total work scope.
The deliverable-based WBS has applications in scenarios such as:
- Projects with clear outputs such as organizing an event or constructing a building.
- Client-focused projects like specific marketing campaigns or design projects.
- Projects requiring detailed scope management such as launching a new product.
Phase-Based WBS
A phase-based WBS organizes work according to the sequential stages of the project lifecycle (initiation, planning, execution, monitoring and control, closure). With this WBS, I must detail the process for achieving specific deliverables.
One of the simplest ways to explain a phase-base WBS is to consider a research writing project. Without doing an ethics review, I can’t interview participants to get insights for writing my final report.
With the phase-oriented WBS, I like the clear insights it gives into elements that hinder the project’s progress. This WBS is also great for providing a roadmap of “when to do” tasks, ensuring each stage builds logically on the previous one.
The phase-based WBS is suited for:
- Process-driven projects such as implementing a business system or conducting research and development.
- Standardized lifecycle projects like those following Waterfall methodology.
- Long-term projects with sequential progression, such as multi-year infrastructure builds or strategic planning initiatives.
How to Use a WBS for Managing Projects
A WBS is excellent for chopping complex projects into the smallest bits. But beyond its core function of visualizing the project scope, here’s how to use a WBS:
1. Assign responsibilities.
The WBS makes it easy to assign deliverables or tasks to team members. This helps everyone know what they’re responsible for and keeps things from getting duplicated.
2. Estimate time and resources.
I use the WBS to figure out how long each task will take and what resources are needed. This makes it easier to create a realistic schedule and budget.
3. Facilitate communication.
The WBS is a great way to keep everyone on the same page. It helps align team members and stakeholders on the project’s scope, responsibilities, and timelines.
4. Manage risks.
I look for potential risks in each WBS element and create plans to address them before they disrupt the project.
5. Integrate with project management tools.
I’m a fan of tools like Trello and Asana. Inputting the entirety of my WBS into these tools makes it easy to help keep track of tasks, manage resources, and generate reports.
Final Thoughts
The work breakdown structure is a cornerstone that provides clarity on projects.
While I had learned about WBS during my studies and applied it in my professional life, diving into its nuances and reflecting on its use in real-world scenarios gave me a renewed perspective.
The WBS is essential not just for planning and organizing a project, but for identifying risks and maintaining control over scope and budgeting.
A useful learning for me was the debate about the relevance of WBS in Agile. A product backlog in Agile projects is like a WBS, where epics or features are managed in sprints.
Without putting thought into the work items, whether in Agile or Waterfall, the project is heading for the rocks.
Bottom line: Successful projects start with a well-thought-out plan, and that plan begins with a work breakdown structure.
Not sure if you prefer to embed a table or just use a screenshot so I gave you both options for these 3 instances (namely because the third is LARGE)