I was well aware of the potential for confusion, and I am pretty sure that I explained what the acronym stood for when the slide went up. But either I hadn’t explained, or I hadn’t done it very well, because not long after I began to discuss WBSs, a participant at the back of the room raised their hand and asked, “I understand what the last two letters stand for, but what does the first one mean?” While I was still trying to digest that question, another student towards the front of the room called out “wholesale!”
Unfortunately, this perception is all too common. When it comes to developing a WBS, all too many project managers are still swearing at it instead of swearing by it.
The WBS is fundamental
Almost any book that you pick up on project management will affirm that a WBS is necessary. Almost any training course that you attend will tell you the same. A WBS identifies the things that must be estimated, budgeted, scheduled, and staffed. The larger your project, the more you need a good WBS.
Even the so-called “agile” approaches create a de facto WBS with their disciplined approach to determining what work is to be done in each iteration.
So why do so many project managers complain about developing a WBS? And more importantly, why do so many WBSs fail to provide the expected benefits? The reason is quite simple: much of the literature is inaccurate, incomplete, misleading, or just plain wrong about how to construct a WBS.
Common misunderstandings
One of the biggest fallacies is the idea that each level has to have a specific name like system, task, work package, or cost account. While these conventions can provide useful guidance for projects with similar characteristics, trying to force-fit them to dissimilar projects is a recipe for disaster. Simply put, there is no need to name the levels at all. Each box in a WBS is either a deliverable or an activity (more on this below).
The next fallacy, and perhaps the most dangerous one, is the idea that a complete WBS can be developed at the start of each and every project. This is only true when the product-scope (the characteristics of the product of the project) is fully detailed from the start. So on a construction project (which is really the construction phase of an asset development project), the project team can usually develop a complete or nearly complete WBS at the start based on the drawings and other information provided by the architects and engineers.
But for a project that includes multiple project life-cycle phases, an adequately detailed WBS for the entire project cannot be developed at the start of the project. For example, if the first phase of the project is a feasibility study for a new laptop, it is clearly impossible to develop a complete WBS when we don’t know what the characteristics of the final product will be. Look at some of Apple’s recent computer designs that have omitted components that most manufacturers would consider standard.
This doesn’t mean, however, that the feasibility study project team can’t develop a WBS. It simply means that their WBS should be limited to the work of conducting the feasibility study.
The following table presents the wrong view and the right view of some other common misunderstanding about the WBS:
Developing a WBS
A work breakdown structure (WBS) is a hierarchically organized presentation of the project’s deliverables and the activities required to produce them. Properly done it is a powerful tool to help ensure that all of the work of the project has been identified so that it can be estimated, scheduled, budgeted, communicated, and analyzed for risk.
A deliverable is defined using a noun or a noun phrase. Each deliverable identifies an artifact: a tangible, verifiable thing to be produced. Deliverables may be given to the customer (a design document, a report, a piece of software, a building) or may be used internally (a draft document, a status report).
An activity is defined using a noun and a verb. An activity identifies work to be done by a person or a group. The work may be related to the product of the project (interview customer, test software, install plumbing), or to the management of the project (collect status reports, update schedule).
The creation of a WBS can be thought of as a six step process as described below. These six steps are not rules but guidelines: there are many variants that will produce a useful result. In particular, if the project will include products and services from outside the performing organization, the buyer’s project management team will have to decide how and whether to involve the contractors.
1. Get the appropriate stakeholders together. The appropriate stakeholders will typically include most of the team members to ensure that any necessary technical knowledge is available when needed. Keep in mind that there are “inappropriate” stakeholders for the development of a WBS as well: your sponsor is unlikely to have much interest in this process, and is also unlikely to have much to contribute.
2. Organize the first level according to how the work will be done or managed. There are three main options for organizing the top level of the WBS:
- By phase. This is probably the most common approach and will almost always be used when the project includes multiple phases.
- By key deliverable. This approach is normally used for single phase projects, or when the key deliverables are being developed using different project life-cycles. This is also the approach most widely used in defense projects.
- By procurement step. This approach is typically used when the bulk of the work on the project will be done by sellers in a buyer-seller environment.
3. Add a branch for project management deliverables and activities. Since the WBS is intended to include all of the work of the project, it must have a place to capture the management work as well as the product-oriented work.
4. Generate additional detail for all branches. There are two major approaches here:
- Top-down. This approach is most effective when the product-scope is well-understood. Working top-down means looking at each of the higher level items and breaking them down into smaller items until you have enough detail to feel comfortable estimating.
- Bottom-up. This approach is almost always used when the product-scope is poorly understood. Creating a WBS from the bottom-up involves brainstorming or other kinds of creative thinking to try to identify all of the artifacts which must be produced and all of the actions needed to do so. Many project managers and teams like to use what is called the yellow sticky process where individual items are written on Post-It® Notes or similar in order to facilitate step 5.
5. Arrange related items into a hierarchy. In a proper hierarchy, each item will occur once and only once and will have a single parent. In addition, the children of each parent must be both necessary and sufficient for that parent. For example, if the deliverable is “subsystem module X,” then the activities below it would have to include the work required to develop, test, document, and inspect module X.
As you develop your hierarchy, you are likely to identify many holes. You can fill these holes with additional or modified deliverables, additional or modified activities, or a rearrangement of the existing items.
6. Edit and revise as needed. Once the basic structure has been agreed, it is usually necessary to revisit the names and descriptions of the individual -items to ensure that they are both useful and correct. A word of warning: leave this step for last! Trying to get the words right before the structure is complete and clear is almost always enormously frustrating.
If you follow these six simple steps, you will discover that the “BS” in your WBS means “brilliant support” for your project.