Excavating the Work Breakdown Structure: Your Waterfall Project’s Rosetta Stone

When it comes to managing Waterfall projects, one of the most important first steps is determining scope—what’s in and what’s out for the project. This crucial information is typically defined in a project scope statement that names the project’s major deliverables and exclusions. A well-crafted project statement may seem sufficient to establish the scope—and it can be. Yet I can attest to the incredible value of going one step further and creating a work breakdown structure (WBS). It’s a step that is too often skipped.

The WBS is a visual project management tool that does exactly what the name implies: subdivides the product and corresponding projects into distinct increments of work. Because our brains like to work visually, the WBS becomes an effective way for the team to conceptualize its work.

Generally speaking, scope is driven by requirements elicited from the customer or sponsor. A sponsor may approach a project manager with the initial parameters for a new product, such as a line of laptops that the company will sell in North America. From there, the project manager or business analyst derives a series of requirements, asking questions like, “What colors will the laptops be?” “What is the hard drive’s mean time between failures?” “How many USB ports are needed?” It’s important to remember that, in this context, the scope includes anything contributing to the project’s outcome. This means not only product scope (the features and functions of the laptop) but also project scope (the work required to deliver those results). The project scope could entail tasks like lining up manufacturing for the laptop or allocating resources for project management.

Exclusions are crucial to record in the scope statement so that later no one asks something like, “Why aren’t we shipping to the UK?” Once approved, this scope baseline helps prevent scope creep, which occurs when someone adds more work without considering its impact on schedule, costs, risks, and resources. Any team member can check the scope statement and see that all the decision-makers signed off on which markets to prioritize, although in my experience, many people never actually read the scope statement.

That’s where the WBS comes in. When the team invests the time to develop a WBS together, it provides an opportunity for everyone to visualize and interpret the entirety of the scope—what’s in and what’s out—along with related issues such as budgets and timelines. As such, I like to think of the WBS as a project’s Rosetta stone.

What Is a Work Breakdown Structure?

The WBS was developed by the US Department of Defense in the 1950s and is still commonly used by government teams and contractors, given that project outcomes in these contexts are often determined at the outset. The WBS can also be valuable in other situations where Waterfall is needed, which is more common than many project professionals may realize. Despite the ascendancy of Agile methodologies, which do not include the WBS as part of the standard toolkit, 39% of information technology projects still employ Waterfall, according to the Project Management Institute (PMI). In other industries, the percentages are even higher.

The WBS breaks the project scope into progressively smaller increments. This hierarchical rendering can appear in tabular or list formats, but the most common (and useful) format resembles a family tree, with related work grouped on different branches.

The first level of the WBS identifies the project. The second level divides the project into phases, deliverables, or functions. The choice depends entirely on team preferences, but I prefer phases because they more readily align with Waterfall’s sequenced approach. The subsequent layers are then subdivided until reaching an increment called a work package. In most cases, work packages require no more than two weeks (80 hours) to complete, but that is not inviolate. In large government or aerospace projects, for example, a work package may take several hundred hours. I have rarely seen a WBS drill down more than four or five levels. By then, the team should have sufficient information to know what work needs to be done.

Sometimes a WBS will incorporate a specialized numbering scheme that echoes the hierarchical breakdown. The most basic form assigns a number to each item in the second level of the WBS (e.g., 1, 2, 3). Subsequent layers in each column are further divided with decimal points (e.g., 1.1, 1.2, 1.3; 1.1.1, 1.1.2, 1.1.3). In my experience, teams can achieve the planning benefits of the WBS without the numbering scheme, but in government projects, it is typically a requirement.

It is crucial to note that even if a team organizes a WBS according to phases or functions in the second layer, the WBS is still a “what” document, not a “who” or “when” document. It should capture the entirety of the work that must occur (often called the 100% rule) but not who does it or when. Nonetheless, once the team has created a WBS to define what work must occur, everyone can more easily talk about these related concerns.

So where does the Rosetta stone part of this come in? The WBS is a visual reference that allows team members to align on a shared understanding of product and project scope. It also helps the team begin to make sense of other issues, like costs, risks, resources, and schedules. As PMI eloquently puts it in its Practice Standard for Work Breakdown Structures (an excellent resource for anyone who wants to understand the details of this tool): “The WBS creates a common language among all project stakeholders, including project management and subject-matter aspects.” In my experience, this is undoubtedly the case.

How to Create a Work Breakdown Structure

Ideally, WBS planning should not be a solitary activity that a project manager undertakes alone. It’s better to develop the WBS with representatives of all the teams involved. This collaborative approach is how the common language comes into being. Depending on the size of the project, one WBS may be enough, although in some cases, each team may want to make its own WBS.

As a consultant, I have led project kickoff events for numerous organizations, including global pharmaceutical companies, for which I co-facilitated extensive two-day working sessions to plan new drug development projects. The drug development process can take 10 to 15 years, but the scope is defined at the beginning. Stakeholders would attend from far-flung corners of the globe to meet and better understand the product they would eventually be producing. When done properly, sessions like this also serve as an excellent team-building exercise. I should emphasize that the person leading this exercise should be an experienced facilitator.

Among other things, my co-facilitator and I would teach attendees how to craft and use a WBS. Representatives from each department—regulatory, marketing, manufacturing, sales, and so forth—would produce their own WBS by applying sticky notes to flip charts on the walls of a large conference room. (For remote meetings, Miro is an excellent tool for a similar activity.) Teams can develop the WBS by following a top-down or bottom-up approach: In the first scenario, a team arranges sticky notes that name larger work items and then adds sticky notes representing subtasks. In the second scenario, the subtasks are arranged first. Team preferences dictate which approach works best, but I have always found top-down easier to envision.

Each team aimed to map out the entirety of its scope. If that level of detail wasn’t possible (because a key representative couldn’t attend or for any other reason), the team would still include a planning package for those items on the WBS and elaborate upon them later. The group brainstorming allowed the teams to visualize the full contours of the proposed work. You can imagine the energetic debates that ensued. People would say things like, “Is this really what we’re doing?” or “That doesn’t belong here; it belongs there.” At the end of the two-day sessions, each team had produced its own WBS, and we had a visual picture of the project. The sponsor could look around the room and say, “Yes, there’s my product,” or “Where is the marketing requirement we discussed?” Through those discussions, the team understood the nature of its work in greater detail.

While the attendees were mapping out their work, my colleague and I would input the tasks into a scheduler like Microsoft Project or Smartsheet. Then we focused on linking the items to produce an initial timeline for the entire project. The scope may require official approval and sign-off from the sponsor and other stakeholders, so the schedule created during the meeting is only a rough draft. Still, the schedule illustrates how a WBS has almost instantaneous utility, allowing teams to begin preparing for the next project steps. In the real world, teams often skip WBS planning and jump directly to building a schedule, forcing them to think about “what” and “when” simultaneously. In my experience, the WBS provides a valuable opportunity to detail what goes into the scope first, before determining when the work needs to occur.

It’s important to note that specialized tools can help project managers develop a WBS. One is called WBS Schedule Pro, and it integrates seamlessly with Microsoft Project. If a project manager cannot bring the entire team together, either in person or virtually, I still encourage project managers to draft a WBS on their own, perhaps using a specialized tool. The project manager can present this draft to the team at a meeting. The draft may get some things wrong, but believe me, the team will be happy to correct those issues. That’s a good thing.

For the record, I also asked ChatGPT to generate a WBS for me, and it did so in a bulleted format. The general breakdown was surprisingly good. With careful prompting, I suspect project managers could turn to generative AI tools for helpful brainstorming assistance and even coax an image generator such as Dall-E 3 to render a graphical WBS. Of course, the results would require double-checking for accuracy.

Other Outcomes of WBS Planning

While the WBS may seem like “merely” a scope tool, it offers much more than that. Project managers have to concern themselves not only with scope but also with costs, risks, resources, stakeholders, and any number of issues. If part of the scope is missing, this means there are:

• No resources associated with it.
• No schedule allowed for it.
• No risks identified for it.
• No stakeholders specified.
• No assumptions made about it.

These issues don’t go on the WBS, but if the team is already assembled in a large conference room for WBS planning—or collaborating virtually using a tool like Miro—it presents an excellent opportunity to begin addressing them. In fact, I maintain that there is no better time to do this, given that the project manager already has the right people in the right place at the right time. The team can look at the fleshed-out WBS and say, “How many people do I need for this project?” or “What are the risks involved?” And the sponsor may sigh and ask, “How much will all this cost?”

Using flip charts or online whiteboards, the team can start to record risks, resources, and action items in what we call parking lots. (The government formally defines the relationships between these related concerns using a document called a work breakdown structure dictionary. However, I’ve never encountered a team that uses this dictionary in nongovernment contexts.)

Does the WBS Work in Agile?

An Agilist reading this might say, “All of this sounds great, but can we use this?” Strictly speaking, the answer is yes—PMI’s Practice Standard for Work Breakdown Structures even includes a section on using the WBS in Agile. Yet I wouldn’t recommend it, given that one of the main differences between traditional project management and Agile is how scope is handled.

We typically use Waterfall when we—or the customer or sponsor—have a very clear idea of what we want as an end result, outcome, or product. Change is permissible but requires a somewhat laborious change control process. In Agile, the end result is not as well-defined, allowing the sponsor or product owner the luxury of changing their mind as the project evolves. This means the scope could change from sprint to sprint—typically only a week or two in duration—so time spent creating the WBS would distract the team from the value they should focus on delivering.

Better Planning Means Better Projects

The process of creating a WBS may sound time-consuming, and it can be, especially if a project manager doesn’t have all the stakeholders in the planning session or the requirements are not well understood. With enough upfront preparation, however, creating a WBS as a team can be a bit of a miracle. It brings everyone together, enforces planning, sparks conversation, and leads to documented discussions about who, what, when, and where. These outcomes will save time in the long run.

I have performed about a dozen of the two-day planning workshops I described earlier, and we never failed to end with a good overall sense of the project. If I’m managing a Waterfall project, I will use the WBS whenever possible, even if I can’t pull the team together for two days. The WBS is fundamental to planning, and, put simply, better planning leads to better execution.

Want in-depth guidance on facilitating project meetings? Jim’s book Great Meetings Build Great Teams: A Guide for Project Leaders and Agilists offers practical advice on improving team cohesion and getting the most out of project management meetings and Agile events.