One of the pillars of any project is the Work Breakdown Structure (WBS) and the accompanying WBS Dictionary. Whether you are a contractor presenting the project baseline or the customer reviewing the baseline, the WBS and WBS Dictionary is your Rosetta stone to understanding how the disparate pieces of a project will ultimately tie together and ultimately deliver whatever you set out to accomplish with your project.
The WBS is the hierarchical breakdown of the project by deliverables. It is the actual structure we are used to seeing and using to organize the project. It allows us to breakdown the scope into more manageable pieces and provides a reporting structure that we use for planning, capturing performance and actuals. The hierarchical structure allows us to drill down and look at the project at its lowest level, rolled up to look at it as a whole, or somewhere in between. The WBS is great at those things. What is not always obvious when looking at the WBS is how the work relates to the Statement of Work (SOW), which is often not structured in the same way as the WBS.
Figure 1 – Work Breakdown Structure
The WBS Dictionary, in addition to expanding on the simple one line description of the WBS elements, connects the WBS to the Statement of Work (SOW). The WBS dictionary is usually a spreadsheet that lists the WBS, the WBS element name, a description of the work in that element at a minimum. In addition, the good dictionary will have a field that designates which SOW paragraph is covered by that WBS element. This mapping relates the two structures to each other and opens up a lot of capabilities for understanding how the project is planned, how it is performing and what it is costing. A WBS dictionary might look like the example below:
The last column in the example shows how the lowest level elements of the WBS are related to the SOW. In the example, you see each element is related to two different paragraphs in the SOW. The first is common across all the elements; let’s say that is the Project Management paragraph in the SOW. This linking shows that the project will be planning, performing and capturing actuals for project management at each individual element. Each element also is linked to a unique paragraph that might contain specific requirements associated with the communications scope of work. Each WBS element should be associated to at least one SOW paragraph, but typically they will be related to multiple paragraphs. If you have a WBS element that is not associated with a SOW paragraph you have to ask “why are we doing this?” because it’s apparently not part of the contract. Conversely, each SOW paragraph should be related to at least one WBS element and it usually touches multiple WBS elements.
So what does having these two structures linked give you? It allows you to look at your project in different dimensions that open up a lot of reporting and analysis opportunities. For example, just looking at a matrix of where the two documents are connected can quickly tell you if you have everything covered in the SOW or are doing work in a WBS element that is not on contract.
But that is the just the start. Think about what information is captured in a SOW paragraph. All of that information can now be related to a WBS which means it can be related to a schedule, performance from an earned value system, the organization performing the work or actuals from your accounting system.
By looking at relationships that exist between WBS elements in the schedule you can see how different SOW paragraphs are linked and whether that makes sense or not. In the WBS dictionary example above, you might expect to see links between the Component Testing (1.3.1) and System Testing (1.3.2). If those links don’t exist it would be a red flag for your project that should be investigated.
The relationship example is just scratching the surface. Performance and actuals can be allocated back to SOW paragraphs. The linking might not be exact, you might have to allocate actuals associated with a WBS to multiple SOW paragraphs, but that visibility is still valuable. You can also drill into the SOW paragraphs and see how elements within those paragraphs relate. For example, SOW paragraphs will usually identify deliverables impacted by a SOW paragraph. A simple mapping of a deliverable to a SOW paragraph, linked back through the WBS Dictionary opens the door to looking at all of the attributes discussed above by deliverable. Then layer in additional fields to the WBS Dictionary (Contract Line Item Number, Control Account Managers, Control Account flags, etc.) and the possibilities grow.
Used correctly, the WBS Dictionary becomes much more than a document that describes the work. It becomes a project kaleidoscope that allows you to look at your project data in an infinite number of ways.