Guidelines for Creating & Maintaining a WBS Dictionary | ACTE
Guidelines for Creating and Maintaining a WBS Dictionary

Guidelines for Creating & Maintaining a WBS Dictionary

Last updated on 15th Jul 2020, Blog, General

About author

Ramesh (Project Manager )

He is a TOP-Rated Domain Expert with 11+ Years Of Experience, Also He is a Respective Technical Recruiter for Past 5 Years & Share's this Informative Articles For Freshers

(5.0) | 19212 Ratings 1298
  • The Work Breakdown Structure (WBS) defines a project’s work in terms of deliverables and the process phases appropriate to the organization and/or project. It also is the basis for establishing all steps/tasks, effort, costs and responsibility.
  • The WBS can be compared to a building’s foundation. Without a good foundation, a building may collapse. Likewise, without a good WBS, project success may be negligible.
  • The problem with a WBS is that deliverable elements are usually defined with very short descriptions. (In fact the graphical nature of the WBS actually encourages brevity.) This brevity often leads to confusion, miscommunication, and unclear expectations for various stakeholders.
  • By linking each WBS element to a dictionary-like item that contains descriptive text, the problem can be eliminated. If we extend that concept just little further by adding several descriptive fields driven by an electronic database system, an extremely beneficial tool can be created.
  • This tool not only addresses the brevity problem, but also can significantly enhance communication and project control.
  • Although this topic is being addressed in the PM Advanced Track, it should not be concluded that only large or complex projects could benefit from the use of a WBS Dictionary. Any size or type of project could benefit from this tool.
  • The concept of a WBS Dictionary is not new, yet almost nothing is written on the topic. The topic will be approached by first discussing the just released work of the PMI Standards Committee on the WBS.
  • Then various definitions of the WBS Dictionary will be examined. Finally an Extended WBS Dictionary, that utilizes database system concepts and several descriptive fields, will be discussed.

    Subscribe For Free Demo



    WBS Dictionary Definitions

    • As previous stated not much as been written on the WBS Dictionary. My research has found a few definitions though:
    • A document that describes each WBS element, including scope, deliverable(s), specification, schedule, resource requirements, and so on.

    Source: PMI‘s pending Work Breakdown Practice Standard glossary.

    • It describes what is in each WBS element, and it may also say what is not in an element, if that is unclear. Example: WBS Element 1.24—Work Environment Request Process—This element describes all the processes that a contract employee will need to use to work effectively on a customers site. Examples include how to get desk space, a telephone, a computer system, access to the Internet, a parking permit.
    • A dictionary comprised of an element index and element descriptions. The elements are defined in terms of technical content, including the relationship with other elements, and a work statement describing the functional services required. Source: US Oak Ridge National Laboratory, Project Managers Handbook, Volume 1, Chapter 10.
    • A document dat describes each element in teh WBS including a Statement of Work (SOW), describing teh work content of teh WBS element, and a Basis of Estimate (BOE), describing how teh budget of teh element was developed. Additional information about each WBS element might include teh responsible organization contract number, and so on.
    • The WBS Dictionary will often result in the project or contract statement of work (SOW). Source: “R. Max Wideman Comparative Glossary of Project Management Terms v2.0”
    • It lists and defines WBS elements. Teh dictionary shows teh hierarchical relationship of teh WBS elements and required resources and processes to produce this element. Each page should include teh following information: WBS title; element number; revision number, authorization and description of changes; element task description;
    • specification number and title; contract line item; contract end item and quantity; cost content and description; and contractor and subcontractor names.
    • Initially, the Government program manager prepares the dictionary, and the contractor later revises it as the CWBS (Contract WBS) is developed.
    • It is updated periodically to include changes and reflect the current program status. Source: US Air Force Material Command, Financial Management Reference System, Chapter 10—Work Breakdown Structure.
    • The Work Breakdown Structure Dictionary is a useful resource for project management, and should be consulted for relevant information on each component of the work breakdown structure (WBS).
    • The WBS dictionary includes entries for each WBS component that briefly defines the scope or statement of the work, defines deliverables, contains a list of associated activities, and provides a list of recognized milestones to gage progress.

    Project management should also consult the Work Breakdown Structure Dictionary for other information such as:

    Identifying which organization is responsible for the specific work component.

    • Scheduled start and end dates.
    • Required resources.
    • Estimated cost of project.
    • Charge numbers.
    • Contract information, details & requirements.
    • Quality control protocol, requirements & standards.
    • Technical information necessary for proper performance of work.

    The Work Breakdown Structure Dictionary is an essential information resource for project management. It should be consulted before commencing any work component in order to insure that proper standards, procedures, and quality control measures are being followed. Due to ever changing circumstances, the Work Breakdown Structure Dictionary is under constant revision. Therefore, frequent review of its contents will assure proper project management.

    Root Cause Analysis

    • As part of the PS-WBS analysis phase, the project team examined reasons why project managers did not prepare “quality” WBSs for their projects.
    • The exercise revealed that while some PMs attempted to create effective Work Breakdown Structures for their projects, they often lacked the written guidance they needed to do so. Verbatim responses to a survey conducted by the PS-WBS Project Team suggest there simply isn’t an easily accessible library of relevant literature that provides sufficient guidance for developing Work Breakdown Structures. Conversely, the team also learned that many PMs believe they had created quality WBSs for their projects when, upon closer examination it was revealed they had simply created a listing of project activities.
    Course Curriculum

    Gain In-Depth Knowledge in PHP Training from Industry Experts

    Weekday / Weekend BatchesSee Batch Details

    These two conditions appear to be rooted in an interesting development:

    • Over the past five years, PM process management and scheduling tools have evolved to become sophisticated and robust product “suites”.
    • These tools now offer an array of automated functions – including what many claim as “work breakdown structure” outputs. (Exhibit 1) Naturally, it is quite easy for PMs to rely on these tools to produce the WBSs they require for their projects.
    • Unfortunately, these tools to do not help the PM define and decompose the scope of the project in terms of it’s deliverables (the true foundational role of the WBS), but rather enable the PM to enter a listing of schedule tasks, push a button and produce what appears to be a WBS.

    Exhibit 1 : Auto-generated WBS

    • Moreover, anecdotal evidence suggests that project management practice at many institutions and corporations encourage project managers to ignore or skip the development of a deliverable-oriented WBS in the rush to “get the project scheduled and started”.
    • This dangerous practice can easily result in missed deliverables and unsatisfactory project outcomes. Additional factors, including the above stated need for “fast track” project delivery and a broadly held assumption that “smaller” projects do not require Work Breakdown Structures, have driven the practice, knowledge and skill required for creating effective Work Breakdown Structure into neglect and disuse
    • Compounding this issue is the array of conflicting guidance regarding the proper approach to structuring the creation of a WBS. As discussed above, the PMBOK
    • Guide, Third Edition defines the WBS as “a deliverable-oriented, hierarchical grouping of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.
    • It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project’s work” (PMI, 2004, p 394). This definition of the WBS is grounded in decades of experience, a vast array of empirical evidence and analysis of practical application. Additionally, this perspective is also “generally recognized as good practice, most projects, most of the time.” (PMI, 2004, p18)
    • The concept of deliverable-oriented development of Work Breakdown Structures is also reinforced by writings from the Department of Energy, Department of Defense and the standard established for development of the WBS, PMI’s Practice Standard for Work Breakdown Structures.
    • None-the-less, many authors recommend creating PROCESS-oriented Work Breakdown Structures (Chapman, 2004, p2), while others suggest the best approach is an ACTION-oriented approach (Pritchard, 1998, p9). Further clouding the path to development of effective Work Breakdown Structures, Systems Development Lifecycle practices such as Rational Rose’s RUP (Rational Unified Process), are built on the principle of process-orientation and don’t easily lend themselves to the creation of deliverable-orientated Work Breakdown Structures to support them.


    The WBS Dictionary can contain whatever information is deemed necessary to communicate the secondary information about the WBS element, such as these 12 items:

    PMP Sample Resumes! Download & Edit, Get Noticed by Top Employers! Download
    • Code or Account Identifier : The project identification code, for example, 4.5 Plant Tree, or the organizational task code, for example 351674 Plant Tree
    • Description of Work : Sometimes a good description of the work provides a strong foundation for the task and is a great communication tool which allows results to be compared to expectations.  It can also be communicated to anyone who need to know what they need to do at a given time.
    • Assumptions and Constraints : Almost every task has assumptions and constraints where it intersects with other project tasks, equipment, team members, and property lines.  Planning for these assumptions and constraints within the WBS is a fantastic way to keep on top of them.
    • Responsible Organization : Every task should have someone who is responsible for it, be it a person or organizational unit.
    • Schedule Milestones : Task start and end dates are integral to the project schedule, which is an important component of the project management plan.  These start and end dates, as well as an important interim milestones can be recorded in the WBS Dictionary.  For example, the purchase date of the tree.
    • Associated Schedule Activities : According to the PMBOK, the WBS is a deliverable-oriented subdivision of the project, rather than a task list.  However, the two are often one and the same in practice.  In any case, the project tasks which correspond to a WBS element can be included in the WBS dictionary.
    • Resources Required : This is very handy.  If a task needs a tool, material, or piece of equipment, the WBS dictionary is a great place to include that information.
    • Cost Estimates : Each task receives an estimate as part of project cost management which, although separate from the WBS, can be included within the WBS dictionary.  Often the time required to complete a task is a major consideration for its cost.
    • Quality Requirements : Nowadays, almost everything has a quality standard written for it.  Either from the International Standards Organization (ISO), or country-specific standards organizations, or industry-specific standards organizations.  If not, you can create your own quality standards for your project, but there is no excuse to not having written quality standards for any WBS element.
    • Acceptance Criteria : This is a great WBS element.  Who decides the task has been completed acceptably?  What criteria are they using?  If this criteria doesn’t exist, maybe it would be worth defining at the project outset.
    • Technical References : Most tasks are performing some sort of technical function.  Nowadays almost all technical functions have some sort of technical references that govern it, for example guidelines, manuals, or standards.
    • Agreement Information : Many tasks are governed by a corporate agreement, contract, or the like.

    Are you looking training with Right Jobs?

    Contact Us
    Get Training Quote for Free