From Confusion to Clarity (part 1)
Why a well-constructed Work Breakdown Structure (WBS) can tame project uncertainty
“The first thing I'll ask a [struggling] project manager is to show me their WBS.” — Bill McVeigh, Dash360
If you were to ask a group of project managers to describe a Work Breakdown Structure (WBS), you’d probably get a variety of answers. Most of them (correctly) would say something like a list of project deliverables or scope. A few (erroneously) would talk about project tasks (tasks and activities belong in a project schedule, not a WBS). The most experienced PMs, however, would tell you that a WBS is fundamentally a communication tool. It’s a document that ensures we and our stakeholders are—figurative and literally—on the same page when describing what the project will create and deliver. A WBS is nothing more than a tool to manage project expectations. After a Mission Statement, your project’s WBS is arguably the most important document you will ever create.
In this post, I answer the basic What and Why questions of creating WBS’s, and in the next installment, I’ll discuss the How’s, including a discussion of tools and tips.
The TL;DR Key Takeaways:
The What: A Work Breakdown Structure (WBS) is a hierarchical listing of the scope (i.e., products, results, and services) that your project has been established to create, deliver, or provide.
The Why: A complete and accurate Work Breakdown Structure allows you to develop focused and appropriate acquisition plans, establish resource needs, develop an efficient schedule, evaluate and address risk, and fully cost the project. Without an approved WBS, you cannot do any of these things, nor may your stakeholders even agree with you about what the project is intended to create.
What is a Work Breakdown Structure?
”If it’s not written down, it does not exist.” —Philippe Kruchten
In simple terms, a Work Breakdown Structure, or WBS, is just a list. It catalogs and documents the planned scope, or deliverables, of your project. The WBS is hierarchical in nature, which just means it’s arranged in a “top-down” structure, with each level, or “tier” of the WBS representing a progressively more detailed breakdown view of the element above it. At the highest tier, the WBS lists the top-level primary deliverable of the project. At the lowest level are the most junior component deliverables, which are known as work packages. Every element in the WBS is comprised entirely (and solely) of the elements one level below it in the list. The simplest way to understand all of this is by an example.
Imagine that we’re managing a project to assemble a bicycle. At the top-most level of the WBS list would be the bicycle itself. One tier lower in the list might be the major components of the bicycle that are expected to be purchased and assembled, such as frame, wheels, brakes, drivetrain, and ancillary equipment. Underneath each of those would be their respective subcomponents, and so on. For example, the deliverable of Wheels might be further subdivided into Front Wheel Assembly and Rear Wheel Assembly, and under each of those might be Rims, Spokes, Hubs, and so forth.
You may note in this image, above, that the elements shown are all tangible, or “physical” deliverables, a/k/a “products.” This is a very common and easy-to-understand type of scope, as they are things that a stakeholder or customer funds the project to create and deliver. But there are other types of scope as well. Specifically, there are three primary types of scope that can be included in a WBS: products, results, and services.
Products. Product scope is just what it sounds like: some physical, palpable thing that is created and delivered. For example, the bicycle components shown above are easy-to-understand examples of “products.” A house you are constructing can be a product, complete with subcomponents of things like foundations, walls, roof, paint, and so on. A fiction manuscript or a computer user manual are also examples of product-type scope. Similarly, software or mobile applications are products. Even the designs and plans for something can also be a type of product scope, as can also be things like the creation of a training program, the writing of a research paper, or the script for a video. All of these are “products.”
Results. The second type of scope is results. Your scope doesn’t have to be a physical thing, but can be a specific result or outcome. For example, the key deliverable of your project may be the market expansion of your company into a new sales arena. Or improving customer satisfaction by a certain percentage. Or reducing manufacturing costs of an existing product. These are results-type scope that a customer is paying you to provide. Similarly, improvements in quality or productivity, expanding environmental sustainability, training employees, or even reducing lost days because of accidents are result-type scope that a project may strive to deliver. None of these are physical things by themselves, but they are tangible and measurable.
Services. The third type of scope is services. The best way to think of these is as “support” elements of scope. For example, if the primary deliverable of your project is the aforementioned bicycle, above, you may also likely need to provide various services in creating that product scope. For example, professional systems engineering support to create, track, document, and assess quality requirements is a scope item that your customer may pay you to provide. Or imagine that you need legal services scope, e.g., to ensure there are no trademark or patent infringements on the design of the bicycle. Or marketing may be included in your remit on the project, and therefore should be included in your WBS. Even project management itself is a type of service deliverable that is included in most projects. None of these services are things that are “handed over” to a customer, but are still elements they’re paying for and that you need to include in your WBS as part of the “deliverables” of the project.
A well constructed WBS will be broken down into successively lower levels, or tiers, until the smallest pieces are manageable “subprojects” that can be readily produced or provided. These lowest level work packages, when combined hierarchically, create larger and larger assemblies, and, ultimately, the primary high-level deliverable itself.
Why is a WBS so Important?
”With great writing, there is great clarity.” —David Costabile
When thinking about scope, it’s helpful to imagine what a customer or stakeholder is expecting to receive for payment. The WBS is the documented list of everything you’re going to create, provide, and implement as part of the project. In fact, this is the primary reason for a WBS: to ensure you and the stakeholders formally agree on what the project will—and will not—deliver. If something is included in the WBS, you and the customer have agreed that it’s what you will create or provide. If something is not included in the WBS, however, then neither you nor the stakeholders should expect it to be delivered. A fundamental goal of project leadership is the management of expectations, and a WBS is one of the primary means of documenting the agreed-upon expectations of the project.
The WBS also helps you plan. While stakeholders are most interested in the higher-level tiers of the WBS, you as the project manager need to understand the lower-level “breakdown” tiers of the WBS so that you can plan the acquisition approaches, estimate required resources, create an appropriate schedule to create those elements of scope, and of course estimate the costs and, ultimately, budget for them. Further, understanding the lower-levels of a WBS will help you better identify and manage risks that threaten the project.
A well-constructed WBS also helps ensure that the project team remains focused on the result throughout the project lifecycle. This clear product focus enhances understanding and alignment among team members, stakeholders, and customers. It also minimizes wasted time and effort on things that are not included in the formal scope. And along with this, helps you control scope, minimize scope creep, and ensure that all necessary product elements are accounted for.
A properly structured WBS also helps you assign responsibilities and track progress. Each work package within the WBS can be assigned to a specific individual or team, promoting accountability for deliverables. Progress monitoring and control become more manageable as the WBS provides a hierarchical structure for tracking work completion against planned targets.
And finally, a well-constructed WBS helps with effective change management. Change is inevitable in projects, and a WBS helps manage change effectively. As the WBS focuses on deliverables, it becomes easier to assess the impact of proposed changes on specific components or work packages and, hence, against the overall objectives of the project. Changes can be evaluated against the WBS to determine their scope, cost, and schedule implications, enabling informed decision-making and minimizing disruption to the overall project.
The bottom line is that at WBS is at the heart of any well-organized project. A work breakdown structure forms the foundation upon which all other plans, decisions, change, and management are based.
Next Steps
In the next installment of this discussion on Work Breakdown Structures, we’ll walk through a framework you can use to produce a rock-solid WBS for your project. As we’ll see, it’s not actually very difficult to do, but it’s critical to do it correctly. Even one missing element of a WBS can lead to project failure. Taking the time to establish and document your project's scope, whether that be products, results, or services, is fundamental to project success.
I love a good WBS! I've gotten away from doing this with my smaller projects, but you make some important points. I may get out my pen and paper and play around with these ideas.