Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Here’s the short truth. Before writing this article, I came across Akin’s Laws, which aptly summarize the structures of labor decay. The fun “law” reads: It’s called Work Breakdown Structure because the remaining work will grow until you get a breakdown, unless you impose some structure on it. This law is clear and true!
All kidding aside, while I was studying for my project management degree, I found an instructive note in the PMBOK guide. The guide, which is the go-to resource 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 failing to meet stakeholder expectations. You don’t want any of this.
So in this guide, I’ll draw 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 to help you learn more about WBS.
Content
A work breakdown structure (WBS) is a visual overview of the various steps in a project. These steps hierarchically organize everything about your project.
According to Jeffrey Pinto, author and professor, WBS is a planning mechanism for knowing the interrelationship of different activities in a project. In its simplest form, a WBS looks like what you see in the template below:
Source
Based on what I learned from Pinto, every WBS has at least four levels in project management.
However, if your project is complex, you will have more sub-deliverables and your work package will continue to grow.
Here are four levels of WBS for a simple project.
Level |
WBS term |
Description |
Highest Level/Level 1 |
Project |
The entire project under development |
Level 2 |
Deliverable |
Main components of the project |
Level 3 |
Additional delivery |
Supporting results |
Level 4 (activity) |
Work package |
Individual project activities |
To illustrate, I will explain these levels with a WBS for a marketing conference.
The highest level of the WBS covers the entire scope of the project. It is also the final deliverable, which outlines what I want to achieve. For this project, the top level is “marketing conference plan”.
The second level of the WBS outlines the major components of the project. It also reduces the scope of the project to 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 that I’ve numbered each score at this level (and for lower levels).
This is an intentional element, absent from some WBSs I’ve seen.
For advice: Numbering the 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 easier to find a working element, especially for a large project.
The third level of the WBS is the sub-deliverable. Each sub-deliverable is an integral part of the main deliverable you will give to your stakeholders.
When considering an item as a sub-deliverable, ease of handling is a consideration. For example, the sub-deliverable, exploration of potential sites (2.1), fits this bill.
Why? It is manageable. I can give him a few hours. The cost is minimal.
If you are creating your own WBS, be sure to use a template to get started.
The last level of the WBS is the activities. Think of activities like atoms. They are the smallest elements within a subdelivery or delivery.
For example, to deliver event planning and strategy, I will need to carry out the following activities:
When I was learning about WBS, some of my peers didn’t seem convinced. Some have argued that it is great on paper but impractical in real-life situations. For others, its benefits outweigh the misconception that it doesn’t exist.
So how does a WBS actually help?
Every stakeholder is on the same page when there is a WBS.
Without it, stakeholders can keep adding to the project until it becomes unmanageable. When this happens, you’ll need to revisit your timelines, milestones, budget estimates, risks, etc. I would hate for that to happen, especially when it comes to multiple projects.
In a waterfall environment characterized by a sequential approach to project execution, the benefits of WBS in avoiding scope drift will be undeniable.
However, in Agile environments without fully defined end products, some experts argue that stakeholders will change their minds about what they want, when and why.
While this negates the value of the WBS, one expert argues that agile teams should not use agile as an excuse to not plan and risk reducing scope.
“While I understand that a waterfall-style WBS would be necessary in a construction project, they (agile teams) cannot complete any estimates on projects with cross-team dependencies, delivery dates across multiple fiscal quarters, and anything more than five team members.”
“At the very least, all end product requirements should be documented, a plan for all major deliverables should be communicated, some equivalent of a WBS should be worked out over the next two weeks of work, and ideally by the end of the next milestone, and a rough outline of how everything will combine the rest”, they add.
A work breakdown structure is not only a planning tool – it helps with budgeting. By breaking my project down into detailed activities, the WBS makes budget allocation easier.
Budget overruns remain a pervasive issue in project management. In a BCG survey of 403 respondents, 49% said that more than 30% of their organization’s technology development projects exceed their budget. Technical projects use Agile for the flexibility and iterative progress it offers.
While I understand that a predetermined budget is antithetical to an agile mindset, incorporating a WBS into sprint planning helps. Allocating budgets at the sprint level allows teams to remain flexible while maintaining financial discipline.
I’ve found that creating a WBS forces me to think critically about every aspect of a project. From major milestones to detailed deliverables, every work package is accounted for. This not only helps visualize the scope of the project, but also ensures that nothing is overlooked.
But before writing each package, a conversation with stakeholders is key. Failure to do so is one of the reasons for the recent and monumental failure of High Speed Rail 2 in the UK.
According to Tejvan Pettinger, an economist, “(High-Speed Rail 2) is in danger of becoming a £50 billion white elephant and a monument to poor planning.”
Pettinger did not suggest that the HS2 team did not have a comprehensive WBS — however, he makes a verifiable claim about the constant changes to the scope of the project.
And as we’ve found, when that happens, the project gets derailed on almost every front and the team has to go back to the drawing board.
There are two types of WBS:
A deliverable-based WBS obtains tangible results (deliverables) for stakeholders.
What I like about this WBS is its focus on “what to do” instead of “how to do” the task. As such, this WBS is easy to modify, easy to estimate costs, and provides a complete overview of the overall scope of work.
A delivery-based WBS has applications in scenarios such as:
A phase-based WBS organizes work according to the sequential phases of the project life cycle (initiation, planning, execution, monitoring and control, closure). With this WBS, I need to detail the process to achieve specific results.
One of the simplest ways to explain a phase-based WBS is to consider a research writing project. Without conducting an ethical review, I cannot interview participants to gain insights for writing my final report.
With a phase-oriented WBS, I like the clear insights it provides into the elements that are impeding project progress. This WBS is also great for providing a “when to do” task plan, ensuring that each phase builds logically on the previous one.
A phase-based WBS is suitable for:
WBS is great for chopping complex projects into their smallest pieces. But beyond its basic function of visualizing project scope, here’s how to use WBS:
A WBS makes it easy to assign deliverables or tasks to team members. This helps everyone know what they are responsible for and prevents things from being duplicated.
I use a WBS to determine how long each task will take and what resources are needed. This makes it easier to create a realistic schedule and budget.
A WBS is a great way to keep everyone on the same page. Helps align team members and stakeholders around project scope, responsibilities, and timelines.
I look for potential risks in each WBS element and create plans to address them before they disrupt the project.
I’m a fan of tools like Trello and Asana. Entering my entire WBS into these tools makes it easy to track tasks, manage resources, and generate reports.
The work breakdown structure is the cornerstone that gives clarity to projects.
Although I learned about WBS during my studies and applied it in my professional life, diving into its nuances and thinking about its use in real-world scenarios gave me a new perspective.
A WBS is essential not only for planning and organizing a project, but also for identifying risks and maintaining control over scope and budget.
A useful learning for me was the discussion about the relevance of WBS in Agile. The product backlog in Agile projects is like a WBS, where epics or features are managed in sprints.
Without thinking about work items, whether in Agile or Waterfall, the project goes to the rocks.
Bottom line: successful projects start with a well thought out plan, and that plan starts with a work breakdown structure.
I’m not sure if you’d rather embed the table or just use the screenshot so I’ve given you both options for these 3 instances (namely because the third one is BIG)