Introduction
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.
The Work Breakdown Structure Today
In June of 1999 the PMI Standards Program issued a Project Charter to develop the Work Breakdown Structure (WBS) Practice Standard. According to the Charter “the WBS Practice Standard is intended to provide guidance useful in the initial generation, further development and application of the WBS in managing projects.” Furthermore, it is intended not to be a restrictive mandate, but instead to be a how-to guideline document, where all reasonable uses for the WBS could be explored without rigidly adhering only to traditional approaches. The exposure draft of the document was published in October of 2000. It is anticipated that the official document will be published just prior to the 2001 PMI Seminars & Symposium. Note: the 2001 WBS Practice Standard document will only mention the term “WBS Dictionary” in its glossary. However it is anticipated that this topic will be addressed much more prominently in the next update (year 2003/2004) of the WBS Practice Standard.
It is highly recommended that anyone interested in this topic read the (75+ page) WBS Practice Standard. However since the WBS Data Dictionary is closely related to the WBS topic, I‘ve included some key concepts from that paper.
The definition of the WBS was a divisive topic of discussion that took many months to resolve. The current WBS definition from the PMBOK® Guide 2000 version is “a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.” This is a somewhat radical shift from the PMBOK® Guide of several years ago that described the WBS as task-oriented. However as the guideline is examined one will find that there is room for several approaches:
• The WBS is NOT a pure deliverable-oriented hierarchy. If it were pure a deliverables hierarchy, then commonly used life cycle attributes and some commonly used verb-noun phrases such as “test system” would be banned.
• The WBS can be structured primarily as a deliverables hierarchy, with phases/process steps detailed within it or vice versa.
• Deliverable oriented components can be either products or services.
• There is a general consensus that the naming convention should be nouns, especially at the highest levels (usually 1st three). However, the project manager has the flexibility to use the verb-noun phrase structure (usually at the lower/work assignment level).
• The project manager should have the flexibility to decompose the WBS to whatever level of detail he or she requires to effectively plan and manage the project.
• Hierarchy can be shown in a variety of ways such as assigning a unique number to each element where decimal points show the hierarchy relationships, using a spreadsheet where elements placed in different columns denote hierarchy, or using a graphical display tool such as WBS Chart Pro from Critical Tools Corporation.
Based on the statement above, the following WBS would be quite acceptable that uses life-cycle attributes, deliverables and verb-noun phases in the approach:
1.0 Software Deployment Project
1.1 Initiation Phase
1.11 Needs and Organizational Analysis
1.12 Proposal/Statement of Work
1.13 Agreements/Contracts
1.2 Discovery Phase
1.21 Preliminary Project Plan
1.22 Project Control Management (Service)
1.23 Needs and Organization Analysis Validation
1.24 Work Environment Request Processes
1.241 Work/Office Space
1.242 Communication Systems
1.243 Logistical Issues
1.2431 Describe Security Access/Badge Process
1.2432 Describe Parking Process
1.2433 Get Site Maps
1.3 Planning Phase
1.4 Design Phase
1.5 Deployment/Rollout Phase
1.6 Closedown Phase
I could write hundreds of pages describing the WBS. In fact many authors have done just that. Those desiring more detailed information on how to create a WBS for various situations can find many references by searching the Internet using the phase, “Work Breakdown Structure.” Other great resources include: Carl Pritchard's book, How to Build a Work Breakdown Structure published by ESI International in 1998; MIL-STD-881B or MIL-HDBK-881 are instructions by the US Military for creating Work Breakdown Structures for developing defense material items and can be found by searching the Internet.
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 that describes each element in the WBS including a Statement of Work (SOW), describing the work content of the WBS element, and a Basis of Estimate (BOE), describing how the budget of the element was developed. Additional information about each WBS element might include the 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” at http://www.pmforum.org/library/glossary/index.htm.
• It lists and defines WBS elements. The dictionary shows the hierarchical relationship of the WBS elements and required resources and processes to produce this element. Each page should include the 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.
In summary it can be seen that at minimum, a good definition for the WBS Dictionary must include a written description of the element. Other definitions typically add several additional descriptor fields and sometimes a complete Statement of Work detailing the activities to be performed. It is clear there is no one single definition; and that perhaps it should be seen as a niche term with a definition that varies from industry to industry. In fact, PMI does not currently include the term in its PMBOK® Guide.
The Extended WBS Dictionary
It cannot be over emphasized that a deliverables-oriented WBS should be the foundation of every project. The WBS allows one to most effectively manage the scope of each deliverable product that in turn rolls up to a project. However in order to understand each deliverable requirement, each element must be complete, correct, precise, consistent, relevant, feasible, manageable, traceable and free of too much design detail. A simple electronic database system, which I‘ll refer to as the “extended WBS dictionary,” may be the key to understanding deliverable requirements by any stakeholder.
Let's first create a definition: The Extended WBS Dictionary is an electronic database system that links a variety of information to each element in a WBS. The purpose of this information is to provide clarity for all stakeholders so that they “fully” understand the deliverable and therefore have similar expectations regarding the scope of the deliverable. Because the information is an electronic database, one will be able to easily add or change information and create a variety of reports in order to harvest the knowledge contained in the system.
The following information typically could be linked to each element in a WBS:
WBS Number—the hierarchal number assigned to each WBS element; example, 1.24.
WBS Name—the short name used in the WBS to describe the element/deliverable.
Description—a textual narrative describing what is in each WBS element; and it may also say what is not in an element, if that is unclear. From the description any stakeholder should be able to understand what will and will not be delivered.
Deliverable Format—describe what it will look like; example, a Word document about 10 pages in length provided electronically.
Completion Criteria—Describe the requirements for completion; example, the Program Management Executive. Team will review the submitted document and formally accept it as complete during their weekly review meeting.
List of Stakeholder and Roles—Provide a list of the names of each key stakeholder and determine his or her role (Accountable, Participant, Review Required, Input Required, Sign-off/Approval Required). This information can later be used to create a Responsibility Assignment Matrix.
Activities/Tasks—a list of major activities/tasks/steps that need to be undertaken.
Assumptions/Risks—a list of assumptions and or risks that could impact the success of the deliverable.
Estimated Budget—a preliminary estimate with regard to effort, resource types and other material items needed for consideration.
Project Phase or Life Cycle—optional, this item allows reporting flexibility and focus on certain deliverables when one has incorporated a phased or life cycle approach into the WBS.
Using the Extended WBS Dictionary as a Control Tool
So far I have described a system that can be created to enhance stakeholder communication and understanding primarily during project startup. During project startup various team, program and technical approaches are explored, the WBS is created and the Extended WBS Dictionary is created. However, resource assignments and dependencies between various WBS deliverable items are not defined at this time.
Once startup is completed and deliverable are assigned, then the Extended WBS Dictionary can be further enhanced to allow for project control/tracking. Note that from a control standpoint, tracking a large multitude of WBS deliverables may not be desirable. Therefore even though you maybe able to decompose your project to many levels of detail, experience has found that it is best to keep deliverables rolled up at a relatively high level (low quantity of deliverables to track).
The following items can be added to the Extended WBS Dictionary to aid in project control:
Dependencies and Constraints—Describe and dependencies that impact deliverable completion.
Progress Comments—A memo field that allows one to keep a daily/weekly log of progress.
Responsible Person—The person who is responsible for getting the deliverable complete. This may not necessarily be the person or team doing the work, but could be a functional manager.
Start Date—date when effort was first applied toward the deliverable.
Percent Complete to Date—The amount of deliverable completion expresses as a percent on a particular date; for example, 20% as of 12/14/2000.
Estimated Date to Completion—Date when you think it is reasonable for the work to be complete.
Completion Date—The date when the WBS deliverable was completed.
Issue Log—List of problems that are currently impacting the deliverable (reactive engagement).
Risk Log—List of possible things that could negatively impact the deliverable and planning alternatives (proactive engagement).
Deliverable Status—Red, Yellow, Green or other simple measure to indicate overall state of the deliverable.
Is This Just a Concept or Does a Real System Exist?
Those attending the Seminars & Symposium will have an opportunity to see that a true working database system does exist that functions like the Extended WBS Dictionary concepts described above. If you cannot attend you can receive a copy of the database system by writing to this author at greg.ward@compaq.com.
