If you have already developed a detailed Work Breakdown Structure (WBS), it might seem like a straightforward task to compile the information into a WBS dictionary. However, this step can actually be somewhat complex. That’s because in project management there is no single “right” way to create a WBS dictionary. It isn’t just a matter of taking your WBS and compiling a text version for other people to look at. The data has to be considered from both a big picture and a highly detailed perspective to ensure that stakeholders who view the document can fully understand the scope, activities, and requirements of the project.
Bear in mind that information which might be critical to include for one type of project might simply be extraneous and confusing in another. So, the first step in creating a dictionary from your WBS is to determine what to put in and what to leave out. Generally, the following standard information should be included in a separate entry for each WBS element:
- An abbreviated version of the scope or SOW (statement of work)
- A list of deliverables with well-defined milestones to measure progress
- An outline of activities that will be carried out to complete each deliverable
Start with a Template
If you are stuck on how to structure your WBS dictionary, it’s a good idea to begin with a standard template. These are available from a variety of project management sources. However, if you want to look at a free version, try this one from the CDC. As you can see, it offers further suggestions for pertinent information to include for each WBS component including start and end dates, resource requirements, cost estimates, and so forth.
Prepare for Alterations
In project management, it is very rare to know everything about a project from the outset. This means the WBS and its accompanying dictionary will need to be revised/updated throughout the life cycle of the project. So, make sure to include a log that shows the version history of the dictionary and when/why any changes were made.
If you have the ability to upload the dictionary to a central location (such as your intranet resource library), that’s ideal. You should encourage stakeholders NOT to print out their own copy for reference because the WBS dictionary will be updated over time. Instead, they should always visit the online version to ensure that they are working with the most current information available.
Add an Appendix
Remember that the WBS dictionary is not designed to be a complete compendium of every single detail in the project. It should, however, contain a reference page that lets the reader know where to go to find the full version of each document mentioned. For example, let’s say a contract was signed with an outside vendor who will be supplying a service or product necessary to the project. The gist of the information in the contract (items or services being supplied, delivery date, and cost) should be included in the dictionary. However, all the pages of legal fine print don’t need to be. The location where the contract is stored can simply be noted in the WBS dictionary in case the reader needs to review that original document in full.