Work breakdown structure practice standard project--WBS vs. activities
by Cindy Berg, PMP, and Kim Colenso, PMP
Should the WBS be comprised of deliverables only, or should it include the activities that provide the deliverables?
DOES THE WBS INCLUDE activities, or should it? Is it completely separate from the dependency network, with nothing in common, or do these two key project management tools share some common elements? These were some of the questions that have been raised and discussed by the WBS Practice Standard project team while working toward development of a document that details how to use a WBS.
Background. The WBS Practice Standard project was initiated in 1998 under the volunteer leadership of George Belev. A draft was ready for initial review by the end of 1998. The PMI® Project Management Standards Program Member Advisory Group (MAG) reviewed the document and recommended some modifications as well as the addition of more examples in the body of the document. The project was restarted in mid-1999 under the volunteer leadership of Kim Colenso, and a volunteer project team assembled by August 1999. For the first several months of the new effort, the team focused on one issue: are “activities” part of a WBS? After exhausting the arguments and with no clear consensus on points of view, the question was taken to the Standards MAG for review. The position that resulted is documented below. However, we know that this view is not universally accepted, and therefore the purpose of this article is to inform PMI members of the issue and the direction being taken.
Cindy Berg, PMP, is a member of the PMI Standards Member Advisory Group, and the current project manager for the PMBOK® Guide Update Project within the PMI Standards Program. She is a senior business analyst with Medtronic Inc.
Kim Colenso, PMP, is the project manager for the WBS Practice Standard project within the PMI Standards Program. He is a principal consultant with Artemis Management Systems Inc.
Exhibit 1. In this example, there is complete separation of the WBS from assigned work. There are no dependencies between WBS entries, no individual work assignments in the WBS, and no individual estimates for assigned work. The WBS provides structure only. This example is useful for assigning responsibility for a package of work that will be planned and managed at a lower level, and may be ideal for the project with a large portion of subcontract work (each of the work packages is assigned to an organization for performance), or for program management. This type of WBS ties easily to the Control Account method of project accounting.
Reader Service Number 192
Issue. Fundamentally, the question is whether or not “activities” are part of the WBS. The polar points of view are:
The WBS should not include activities because:
■ The WBS is comprised of deliverables, which are expressed as nouns, whereas activities involve actions, which are expressed as verbs.
■ The WBS does not go to the level of detail where an individual person is assigned and dependency connections are established. Individual team members should have the freedom to exercise creativity in choosing the best method, and activities, to produce their deliverables. These methods, and activities, should not be prescribed in the WBS.
■ The process of creating the WBS is a separate planning activity from the process of creating a dependency network. As a result, there is no direct connection between these two processes.
The WBS should include activities because:
■ When activities are connected by dependency relationships, the relationship is based on the fact that the predecessor activity process creates a deliverable that is required for the successor activity process to create its deliverable. Therefore, activities create deliverables.
■ Deliverables that result from activities are part of the deliverables hierarchy, and in effect are decompositions of higher-level deliverables just like any other level within the WBS.
■ The process of creating the WBS is a top-down planning process that provides transition toward the development of a network diagram. The development of the network diagram may lead to the discovery of missing WBS entries. Even though the development of the WBS and the development of the network are two separate processes and yield two separate project management deliverables, they do influence each other through their common use of the activity.
Resolution. After much discussion, the Standards MAG felt, and the project team concurs, that the following statements were generally true for most projects, most of the time, and therefore are appropriate as the basis for resolving this issue:
■ The project manager should have the right to decompose the WBS to whatever level of detail he or she requires to effectively plan and manage the project. Project managers may find themselves in many different situations and it would be inappropriate for PMI to place restrictions on their options. The WBS is a project management tool that can be used in different ways, depending upon the needs of the project manager. Therefore, there should not be arbitrary limits set on “how the WBS should be created.”
■ As defined in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), the WBS is a “deliverables-oriented hierarchy.” It is not purely a deliverables hierarchy. If it were purely a deliverables hierarchy, then commonly used process or life cycle attributes would be banned from the WBS. Since major WBS elements like Assembly and Test have shown up in many WBS examples from many industries, this distinction is well established.
■ The lowest level in the WBS does not contain a dependency network, nor does it contain the schedule. However, the lowest level in the WBS may be connected with dependency links in a dependency diagram, and therefore, the lowest level in the WBS can be the common link between a precedence diagram and the WBS. Therefore, the lowest level of the WBS may be activities.
■ The naming of the entries in the WBS can have some flexibility. This statement is supported by the argument for providing the project manager with flexibility in managing the project situation. There was general consensus that the naming convention for the WBS should be nouns, especially at the higher levels. However, the project manager has the flexibility to use a verb/adjective/noun structure should that option best meet the needs of the project—especially at the lowest level. In this regard, the general feeling was that all three exhibits would be acceptable examples of a WBS. See Exhibits 1 through 3.
■ The WBS can be structured primarily as a deliverables hierarchy, with process steps detailed within it. The WBS can also be structured from a process or life cycle basis (i.e., the accepted concept of Phases), with noun deliverables detailed within it. The rationale for these statements is to provide the project manager flexibility in approach as well as to recognize that many of the major components in life cycle structures are also major deliverables. Another reason is the commonly held view that the WBS is formed by the intersection of a product breakdown structure and a process breakdown structure.
It should be noted that at the lowest level in the WBS, an individual should be identified and held accountable for the result. This individual may be an individual contributor, creating the deliverable personally, or may be a manager who will in turn create a WBS to plan and manage the results. The assignment of the responsible individual is not the WBS, but like dependencies, uses the WBS as the framework and common factor.
THE PMBOK® GUIDE SUPPORTS the WBS as nouns, but does not go any further in discussing other potentials. The difference, of course, is in the orientations of the two documents. The PMBOK® Guide is a PMI Standard that identifies what is generally acceptable. Because the WBS Practice Standard is intended not to be a restrictive mandate but instead to be a “how to” guideline document, all potential reasonable uses for the WBS should be explored within the WBS Practice Standard document without rigidly adhering only to traditional approaches. In other words, this document is to be a useful “guiding” tool, not a decree of “thou shalts” and “thou shalt nots.” In this way, the various options can be fully explained.
Your input on this issue is welcome; you may e-mail your comments to [email protected]. ■
Exhibit 2. In this example, we see an extension of Exhibit 1. Assuming that the lowest-level entries are assigned to the individual doing the work, this example does not provide good communication, as many time reporting systems will only provide the lowest-level assignment entry, and the hierarchy is missing.
Exhibit 3. This example, for the team member, provides the best communication, as the activity name fully describes both the action (Create, Review, Update) and the desired deliverable (Initial TSS Requirements Specification, Final TSS Design Specification).
April 2000 PM Network