Work Breakdown Structure (WBS) Dictionary

Have you read the Basics of Scope Management article yet? You might have noticed a quirky equation in the end,

Scope Baseline = Project Scope Statement + Work Breakdown Structure + WBS Dictionary

While all other topics are already covered under the Scope Management knowledge area, WBS is something we will introduce now.

A basic textbook definition would be that a WBS dictionary is the document that provides detailed information about every element of the WBS. We did talk about the WBS dictionary a bit in this Lounge Fever videoTypically, a WBS Dictionary entry will be made for each WBS element with details like a Work Package details, description or statement of work, acceptance criteria, deliverables, cost, schedule etc

Work Breakdown Structures include a numbering system (also known as the Code of Accounts) and this numbering system is referred to in the WBS Dictionary to point to the corresponding WBS element making it easier for the stakeholders to read it.

Below is a sample WBS Dictionary entry for System Requirements document,

Check more articles on Scope Management

Is it mandatory for the WBS to be graphical?







Deconstruction, 8/80 Rule, Control Account and Code of Accounts

While we have covered a whole bunch of concepts related to Work Breakdown Structure (WBS), below are 4 other that might come in handy as options of some of the questions in PMP,


This is just another name for Decomposition. Deconstruction of Project is done via the WBS Creation

8/80 Rule

This is another name for the 10-day rule. WBS follows the 8/80 rule which basically means deliverables are decomposed till they require 8 to 80 hours of work (or 10 days of work)

Control Account

With WBS think about how easy or difficult it could get to track the progress of the project. It could be difficult to track a project at a very high level in the WBS yet equally difficult at the lowest level too. This is where we take a point between the top most level and the Work Package level and call it the Control Account. Control Account are pre-determined points where scope, cost and schedule are integrated and compared to the earned value for performance measurement. A Control Account usually has one or more work packages

Code of Accounts

Code of Accounts is typically a numbering system that uniquely identifies each component of the WBS

Check more articles on Scope Management

Work Breakdown Structure (WBS)

Once you are done with the Define Scope process, the next process in your journey of Scope Management knowledge area is the Create WBS process. The best way to understand this process is to start from the point of understanding the WBS.

Now if you are a newbie in Project Management, one of the many weird terms you need to get yourself acquainted to is the WBS. WBS stands for Work Breakdown Structure and is basically a way to organize the project team's work into manageable parts.

Breaking up the definition of WBS into two parts can help interpret it much better,
- WBS is 'deliverable' oriented (not 'activity' oriented)
- WBS is a hierarchical decomposition of the work

An example of a WBS is below,

Check more articles on Scope Management

Cross Cutting Skills - Exam Content Outline

Avoid the 7 Deadly Sins of PMP

1. Treating PMBOK as the only source of truth

2. Considering Professional experience above PMI perspective

3. Exam anxiety

4. Over thinking and over analyzing

5. Retaking the exam

6. Not creating a PMP Brain Dump

7. Not making use of the 4 hours of exam







Requirements Document or Project Scope Statement | Where do these items go?

Gig Economy - Success in Disruptive Economy

Is it mandatory to perform Alternatives Generation if there's only one way of doing something?

Proficient, Moderately Proficient, Below Proficient | Understanding your PMP Exam Result

What should you know about Expert Judgment?

Have you ever had a person in your project team that understood every single technical detail of the project end-to-end? These are experts. Don't you wish you could have an expert on all your projects? But aren't experts always busy working on the most important projects? To solve this, there is one name in the list of "Tools and Techniques" that you will see over and over again - Expert Judgment

Due to its multiple appearances throughout the Project Management landscape and its sheer usefulness, Expert Judgment is often recommended as one of the best tools and techniques. This relies on the very idea that experts are an asset of an organization and should be leveraged in the most effective way possible. Project teams typically need the help of experts during several planning processes. Planning is one of the most important part of Project Management and having an unbiased and expert opinion during planning can help avoid massive goof-ups later.

Consider a relatively new project manager working on the project cost estimates. Do you realize the importance of having expert judgment? Same goes with many other processes during the course of project lifecycle from defining scope to identifying risks. Expert Judgment as defined in some books is basically, - Using knowledgeable groups or individuals to assist in project decisions.

Who is part of the Expert Judgment Group?

Typically someone outside of the project team. It could be one person or a group of people. They could be SMEs, Team Leaders, a separate department within your organization or even external consultants. They will be an expert either in a specific knowledge area, a specific discipline, an industry etc.

How is Expert Judgment different from Organizational Process Assets (OPA)?

OPA is related to the processes or artifacts. It is also a part of the organization and built on earlier experiences and lessons learned while Expert Judgment could be a group of people totally unrelated to the project.

Facilitated Workshops | Product Analysis | Alternatives Generation - Define Scope Tools and Techniques

There are three tools and techniques of the Define Scope process,

1. Facilitated Workshops

Going over the requirements collected in the collect requirements process with all the stakeholders at the same time can help narrow down on the project scope. Facilitated Workshops is thus one of the most important tools and techniques of Define Scope process.

One of the most important objectives of this technique is to ensure that the requirements have quantifiable goals,

Jack – We need to make sure with this project our product gets easier to use
Jill – Our goal is to reduce customer support requests by 15%

Obviously, what Jill has mentioned is quantifiable and can be measured

2. Product Analysis

While collecting requirements, stakeholders are inclined to talk about requirements from the perspective of the product perspective and not the project perspective.

As an example – "The website is graphics intensive and loads slowly, we need a less graphics intensive website that should load quicker."

This is a product requirement. With the product analysis technique, we convert these product oriented requirements into the actual project work.

Continuing the above example – "Graphics team needs to come up with lighter graphics for the website."

3. Alternatives Generation

As the name goes, coming up with other ways of accomplishing a job is the whole concept behind this technique. This is a technique of the Define Scope process because it may lead to a change in the scope (or other project constraints)

Consider an example – Can the existing IT infrastructure with another department be used for 2 weeks to meet the testing requirements of the project?

- It might lead to realignment of the project dates based on other department's preference
- It can help reduce the project cost of acquiring the IT infrastructure

As you can see an alternative can lead to change in schedule and cost in addition to reduction of scope

Check more articles on Scope Management

Rita Mulcahy 9th Edition Out - Based on PMBOK Guide 6th Edition






Tomorrow is my PMP exam! | What should I be doing?

Vlog - Testimonial by a subscriber who cleared the PMP Exam

PMBOK 6 Online Course

Define Scope Process

The next process in Scope Management knowledge area (under Planning process group) after the Plan Scope Management and Collect Requirements processes is the Define Scope process.

Define Scope is the process of developing a detailed description of the project and product scope. A clearly defined scope is extremely important to project success. On the other hand, an ill-defined scope will eventually lead to conflict, rework and stakeholder discontentment. After the key process of Collect Requirements, it is only fitting that define scope process follows.

It should be noted that the scope of the project not just outlines what will be delivered as part of the project but it also emphasizes whatever that is excluded from it will NOT be delivered. So define scope can also be considered as drawing the boundary of the project and finalizing the project scope.

Check more articles on Scope Management

Requirements Traceability Matrix (RTM)

The Requirements Traceability Matrix (RTM), as the name goes, is all about "tracing" the requirements end-to-end. End-to-end here means right from the inception to design to code to test to acceptance so that they don't get 'lost' during the course of project.

Generally speaking, the Requirements Traceability Matrix is a one-stop-shop for anyone to look into and understand where the requirements come from, where do they get implemented and how do they get verified. It is the most convenient way for someone to take a quick high-level look at any requirement and make sure it is mapped to the corresponding design, code element and test case.

The most important task of the Requirements Traceability Matrix is thus to track all requirements and ensure whether or not they are being met by the current process and design. It also helps ensure that all system requirements have been met during the Verification process.

It is suggested that the Matrix be created at the very beginning of a project as it forms the basis of the project’s scope and incorporates the specific requirements and deliverables that will be produced. The Matrix also comes in handy during the Change Management process as it ensures any change in requirements is not interfering with other requirements. In addition to that, the matrix is also a helpful tool for the Quality Management process.

There are certain software like Quality Center that can generate RTM. Additionally, organizations may also have their own software to generate RTM.

All in all, the RTM shows the connection and relationship between initial requirements of the project and the final product/service produced.

Check more articles on Scope Management