Today we want to talk about using a WBS Dictionary. Does your schedule include a Work Breakdown Structure (WBS)? You’ve probably learned how important that is on your project management training course or a detailed training session on scheduling. Maybe your professional schedulers told you how to set it up for your project.
So the WBS is done. But now someone mentions the WBS dictionary. Cue the panic… What do you have to do with that?
Quick definition
A WBS dictionary is a companion document that describes each WBS element in more detail. It includes detail about the scope, deliverables, assumptions, resources, and control accounts for each item on the WBS.
It’s important because it helps avoid ambiguity, keeps everyone aligned, and supports traceability. All these things are important in every project, but if you work in an especially complex or regulated environment, you need to have great records and clarity of deliverables, which the WBS dictionary helps with.
But how do you get started? Don’t worry, we’ve written hundreds of these documents (probably many more). Here’s how to use one, without getting buried in detail.
Know what belongs in a WBS dictionary
First, let’s summarize what you need to include for each item. The core elements you must have are:
- Description of work
- Responsible party or role (if you can’t name a name yet, put the job title in here)
- Deliverables/output
- Milestones or timeframes you are working to
- Budget or cost account
- Assumptions and constraints
Then you can include some optional extras, which we highly recommend but you might not have for every item:
- Acceptance criteria
- Quality requirements
- Related risks (reference the risk number from the risk log so you don’t have to type it all out again, or just link to the risk entry)
- Notes or dependencies
That might sound like a lot, and our top tip is to avoid including everything for the sake of it. Longer is not better when it comes to dictionary definitions! Tailor what you include based on project complexity. The more complex your project, the more detail you will need and even then you might not need the same level of explanation for each item.
Tip: Start with the Level 3 WBS items and only go deeper if you feel you need to.
Here’s a brief worked example:
WBS Code: 1.2.1
Task: Develop user login feature
Responsible: Front-end developer
Deliverables: Secure login form, backend integration
Milestones: Login feature complete by Week 4
Cost Account: DEV-UI-02
Assumptions: OAuth2 integration is feasible
Risks: Delay in external API availability (Risk #004)
Start with a template
It’s hard to get started when you are looking at a blank page. Call up a past project’s WBS entries and use that as a starting point. If you don’t have one, ask another project manager in your organization, download a template, talk to your PMO or even draft a simple spreadsheet or document template that you can reuse each time.
Our favorite format is very simple: one row per WBS code with columns for each field.
You can manage your WBS dictionary in your project management software. Tools like MS Project, Oracle Primavera P6 or even SharePoint can help, so don’t create something new if you already have software functionality to tap into.
Build as you go
As soon as you have information, start filling out your dictionary. You don’t have to do it in one go, and you certainly don’t have to wait until you have all the details about every item. Plus, it’s a very tedious task to have to populate all the rows, so we highly recommend you break up the work and do a few entries at a time!
You’ll find that data comes out of planning workshops, scope reviews, or team alignment sessions. Whenever you hear something that should be in the dictionary, call it up and add it in.
This turns your dictionary from a static list to something that you can use to clarify scope and reduce misunderstanding between teams and clients.
Tip: You don’t have to write the whole thing yourself. Bring in work package owners or functional leads to complete the entries for their areas. This increases accuracy and encourages engagement – hopefully they’ll take over keeping their items up to date as well.
Use it as a living document
We like the idea of creating the dictionary in your project management software or a collaboration tool so that everyone can see it. It should be something that you refer to often, such as at phase gates, or for onboarding new members of the team. Link to it from status reports or share it at handoffs between teams so they have the full picture. If you feel like you won’t update it regularly, put review points in your calendar every month or so as a reminder to go back to it.
Regularly update it when you have more information, but remember that adding more shouldn’t mean adding complexity. Focus on keeping the entries clear and accurate. When a change request comes in, use the WBS dictionary to help assess the knock-on impact. It clarifies what’s already defined, so you can more easily see what needs updating elsewhere.
It’s also a useful tool for supporting audits and earned value management processes or certification. If your project is subject to an Integrated Baseline Review, the WBS dictionary becomes a critical document. It demonstrates traceability, clarity of scope, and helps the review team understand how effort and costs are tied to specific work packages.
In summary, the WBS dictionary shouldn’t be daunting. It’s just a scope translator for your WBS. You can start simple and add more information as you find it out. Getting started is the main thing. The team will soon help you populate the rest of it, and the conversations you have about scope and progress will give you what you need.