Work Breakdown Structures (WBS) – Quick Tip #7

WBS's Are Constructed of Work Packages


At the lowest level of a WBS tree are individual work packages (WP). When first planning a project you don’t have to identify every single one of these, but you will have to by the time you’re ready to baseline your project. Progressive elaboration is the key to tackling this job of identifying WPs. The purpose of breaking down the WBS into WPs is that you will use these to produce realistic cost estimates and schedule activities for the project. You have to break the work down to this level of granularity to create these things, but it makes no sense to go further than this. The sweet spot the lies between too little and too much detail is something that is different on every project–and something that every project manager has to determine.

Did you find this post useful? Sign up here for our free email list to help ensure more like it are created. Thanks!

You can also email me directly at

Work Breakdown Structures (WBS) – Quick Tip #5

Organize your WBS to align with your contracting strategies.


After you have collected all of your individual scope elements, you should begin organizing these into logical groupings and categories. On my current project, we used butcher paper and note cards to shuffle and move things around on a big table and whiteboard. (Another method is to use so-called “mind-mapping” software to capture content. I’ve personally used products like and MindNode for this purpose on small and large projects alike with very good success.) 

During the initial layout, management should give the engineering team almost complete carte blanche to sort and organize, but they should be given some over-arching guidance; namely, when grouping items together, ask your team to think in terms of contracting strategies. How you’re going to subdivide the procurements on a project should align as closely with your WBS as possible; you should strive to avoid components in a single procurement package spanning multiple major branches in a WBS tree.

Way back at the start of my current project, we were a small team, and the plan was to stay “lean” for a while and try to leverage involvement from industry and partner institutions. This meant larger than typical contracted sub-packages for combined design and fabrication for many of the subsystems. Even if we assumed we were going to self-perform a task in-house, we acted as if we were going to subcontract out that package when organizing the WBS; this kept us focused on ensuring discrete, standalone and self-contained “contract” packages for which we could readily write SOWs, specs, acceptance criteria, and interface control documents, as well as estimating cost and schedule.

Did you find this post useful? Sign up here for our free email list to help ensure more like it are created. Thanks!

You can also email me directly at

Work Breakdown Structures (WBS) – Quick Tip #4

Don't reinvent the wheel.... or an entirely brand new WBS.


One of your most powerful tools as a project manager is the ability to “R&D”, or Rip-off and Duplicate from other, previous projects that are similar to yours. When it comes to capturing all the scope on a new project, look around and see if you can use a WBS from a similar project as a starting point, both for identifying scope as well as organizing it.

You can also copy templates that are used in your specific industry or field. The obvious benefit in doing this is it gives you a leg up, or starting point in the process. Potential downsides, however, include a) all projects by definition are unique, so the WBS for one project won’t map fully to another; and b) organizational and content problems get carried over from project to the next, essentially “in-breeding” errors and omissions. You should definitely consider R&D’ing from other, similar projects, but remember to be judicious about it. Treat it as a starting point, then make it your own.

Did you find this post useful? Sign up here for our free email list to help ensure more like it are created. Thanks!

You can also email me directly at

Work Breakdown Structures (WBS) – Quick Tip #3

Take the time to define was is NOT included in your work scope


In addition to ensuring 100% of the project is contained in the WBS, it is just as important to exclude items that are not true work scope. A well constructed WBS should include exactly 100% of the project work scope—no more, no less. On my current project, a number of items were ultimately excluded because they more correctly belonged to other areas and teams within our institution.

Taking the time to define—and document—what is not included in your project then allows you to convey this to your stakeholders. This, in turn, means that they won’t be surprised at the end of the project when you deliver X and they were expecting Y. It also allows you to properly budget and schedule the work you and your team have to perform during the course of the project.

Did you find this post useful? Sign up here for our free email list to help ensure more like it are created. Thanks!

You can also email me directly at

Work Breakdown Structures (WBS) – Quick Tip #1

A WBS Should Include 100% of Project Scope


While the layout of a WBS doesn’t need to be perfect, the content does. In other words, you absolutely have to account for 100% of the work scope of a project. You must strive to not leave anything out. If you do miss something that is discovered later, you’ll have to ask for additional money and/or time to perform that missing scope, you will have to draw upon contingency reserves to pay for it, and/or you’ll have to sacrifice other, lesser important work scope to pay for the newly discovered scope. None of these are good options.

One way to find the entirety of project scope is via the application of Progressive Elaboration. Hit the higher-level WBS elements first. Review to ensure you have all the big-picture scope accounted for, then drop down a level and subdivide and breakdown the scope. Rinse and repeat at each progressively lower level of the WBS until you get to the work package level. Visualize how a subsystem comes together; what are its constituent components, and what is and isn’t included. Start big and decompose.

Did you find this post useful? Sign up here for our free email list to help ensure more like it are created. Thanks!

You can also email me directly at

Project Management Success Habit #1: Prioritize the Definition of Success

Scope, Quality, Budget, & Schedule-- Decide which is the most important.

Core PM Habits & Skills: Early Definition & Formal Documentation of Success

“Ensure you understand scope, that it’s well defined, and that it doesn’t keep changing.” -Alistair McPherson, Square Kilometer Array (SKA) Project Manager

The logic might sound a little circular, but the majority (>63% surveyed) of competent Project Managers (PMs) stated that project success hinged on first defining what project success is. In other words, they understood that they had to completely define the “what” they were tasked with delivering, and also what constraints and boundary conditions they have to deliver that “what” under. Many of the PMs stated that they did this by fast-forwarding to the end of the project and imagining what a successfully completed project would appear like to them, their customer, and key stakeholders. If they’re tasked with building a scientific “device,” they ensured they took the time to determine exactly what that means:

  • Product Scope. They know exactly what the delivered device is and what are its major constituent parts and functions;
  • Quality Requirements. They understand exactly how “good” the overall device needs to be upon delivery, along with how good each of its constituent parts need to be;
  • Schedule. They know when the required handover date of the device to the customer is; and,
  • Budget. They know how much money and resources are required and available to build the device.
scope, quality, schedule, budget

Scope and the triple constraints of quality, schedule, and budget.

Scope and the Golden Triangle of Quality, Schedule, & Budget

Balancing the triple constraints of project management

In this post, I discuss the relationship between the Scope of a project and the triple constraints of Quality, Schedule, and Budget that get placed on that scope.

scope, quality, schedule, budget

Scope and the triple constraints of quality, schedule, and budget are often illustrated by way of a triangle (hence the term “golden triangle” of project management. At the center of the triangle is scope, which is usually the most important

The Difference Between Scope and Quality

The difference between product scope and quality requirements

On an engineering project, where does scope end and quality requirements begin? Some engineering project managers treat quality as a subset of scope. Others act as if they are essentially the same thing. While both of these approaches can be made to work, I prefer the traditional approach of keeping the two separate. In this post, I discuss the key differences between scope and quality, describe how they can be tracked by way of a V-diagram, and I include a simple example that illustrates the difference between them.

Product Scope and Quality Requirements.

Product Scope and Quality Requirements are closely related– but they are in fact different things.  Scope is what you’re going to deliver, while Quality defines how good that deliverable must be constructed.

V-Diagrams in Project Management

Managing scope and quality by way of a classic systems engineering tool

In this post, I discuss a simple but powerful engineering tool to help define and manage both Scope and Quality: the V-Diagram.

v-diagram used in project management

The classic Systems Engineering V-Diagram is used to illustrate how scope and requirements are defined, and how the components, subassemblies, and assemblies are tested against those scope and requirements definitions.

Definition of a Project’s Scope of Work

What's the difference between Project Scope, Product Scope, and plain old Work Scope?

One of the first things you have to do as an engineering project manager is fully define the scope of work your team is responsible for delivering. You can’t build something unless and until you know exactly what that “something” is supposed to be. Successful project managers predetermine and document precisely what is (and isn’t) going to be delivered; the project’s scope of work is the fundamental piece to defining the overall success of a project. There are two main parts to work scope: 1) the deliverable itself (i.e., Product Scope); and all the supporting project work required to deliver that product (i.e., Project Scope). In this post, I discuss in more detail the differences between the two.

Work Scope, Product Scope, Project Scope

Work Scope = Product Scope + Project Scope