Chapter 5

Considerations While Creating a WBS

5.1 Overview

There are many ways to create a Work Breakdown Structure (WBS). It can be developed entirely as a new document, can reuse components from existing WBSs, can be based on a template, or can follow pre-defined WBS standards. When reusing existing components, WBS elements can be drawn from similar projects or from standard project templates that the organization has determined support accepted good practices.

This chapter discusses the methods used to create a WBS, as well as some considerations that should be taken into account during WBS development. The sections of this chapter are presented as guides for use during the WBS development process, while some sections can be used as checklists for the development and refinement of the WBS. The remaining sections of this chapter are as follows:

5.2 Preparing a WBS

5.3 General Factors to be Considered

5.4 Essential Judgments

5.5 Evaluating WBS Quality

5.6 WBS Usage Continuum

5.7 WBS for Program and Portfolio Management

5.8 Summary

All project, program, or portfolio requirements need to be considered during development of the WBS. A critical factor for success at any level is the creation of a high-quality Work Breakdown Structure.

5.2 Preparing a WBS

The WBS evolves through an iterative consideration of the project's purpose and objectives (both business and technical), functional and performance design criteria, project scope, technical performance requirements, and other technical attributes. A high-level WBS can often be developed early in the conceptual stage of the project. Once the project is defined and specifications are prepared, a more detailed WBS can then be developed. It should be customized to the specific needs and requirements of the project. All non-required work and deliverables should be listed and removed so the WBS represents only the project's scope. The end result is a WBS that represents the complete list of deliverables for the project. A number of authors have provided useful guidance on preparing a WBS (Haugan, 2002; Pritchard, 1998; Uyttewaal, 2005).

The WBS can assist the project manager and stakeholders in communicating a clear vision of the end product(s) of the project, and of the overall process by which those products will be created. It helps communicate the work to be accomplished as well as the interim and end-point deliverables to be completed. With this in mind, the following list of questions should stimulate thought when developing a WBS to manage a project:

• Is the project charter defined and issued?
• Is the project scope statement defined and issued?
• Have the project manager and the team formulated a vision of the final product(s), services, or results?
• Have personnel who will do the work been assigned to develop the WBS?
• What are the project's component parts?
• How do the pieces work together?
• What needs to be done?
• Have the project's intended business objectives been defined? What is required to achieve the business value?
• Has the entire project been thought through? Have the high-level deliverables been progressively decomposed?
• Have all deliverables, both interim and final, been identified? What is to be provided? What is required?
• Has the relationship of each component to the end product been defined? How will this component contribute to the finished deliverables?
• Has the process for production of the deliverables been defined? What methods will be employed? What special processes will be needed? What are the quality requirements? What kinds of inspections need to be done?
• Have the activities that are needed to support the deliverables been identified, including those that directly or indirectly facilitate their creation?
• Has technical input from knowledgeable Subject Matter Experts (SMEs) been obtained, and is that technical input communicated to and validated by other key SMEs assigned to the project?
• Does the project require any external sources to contribute to the project and have they been identified?
• Has all work associated with risk management been identified? Have risks associated with project assumptions been identified?

These thoughts and questions are intended to help the project manager develop a clear statement of what the product(s) of the project are. They should be iteratively reviewed until all questions have been completely addressed and all information is known—to the extent possible. Once completed, all of the work packages (i.e., the lowest-level WBS elements) should together comprise the complete list of deliverables for the project. They depict the project's scope.

5.2.1 Preparation Methods

A number of methods and tools can be employed to create a WBS including outlines, organization charts, fishbone diagrams, brainstorming techniques, and top-down and bottom-up development strategies. WBS templates, as well as corporate guidelines or standards can be referenced or copied for quick-starting WBS development.

There are many benefits to using tools to develop a WBS. For example, tools often promote consistency and repeatability in the development of a WBS, especially if it is an enterprise productivity tool. WBS tools can also promote and enforce the principles of the organization's WBS guidelines or standards, and can significantly reduce the development effort, simplify the WBS process, and even promote reuse of WBS elements.

Some of the more popular methods employed to create a WBS include a top-down approach, a bottom-up approach, the use of organization-specific WBS guidelines or standards, and the use of WBS templates. The choice of appropriate method should be based on the specific project objectives, requirements, assumptions, and constraints. Table 5-1 highlights some advantages and challenges of the aforementioned methods.

WBS Creation Method	Advantages	Challenges
Top-Down	Structures project conveniently for status reporting Helps ensure projects are logically structured Is valuable when brainstorming/discovering project deliverables Can accommodate additional deliverables as they are uncovered	Requires constant attention that no work packages are overlooked WBS needs to be elaborated to sufficiently detailed level to permit management oversight and control
Bottom-Up	Starts with all deliverables and works backwards into a project Confirms that all work packages are included	Identifying all deliverables before producing the WBS Making sure work packages are logically grouped Can lose focus on big picture
WBS Standards	Formats are predefined Enhances cross-project WBS consistency	Making a project fit the standard Can lead to inclusion of unnecessary deliverables or failure to include project-specific deliverables Not all projects fit into a highly structured set of WBS standards
WBS Templates	Provides a starting point for WBS creation May help determine appropriate level of detail required Enhances cross-project WBS consistency	Requires a project fit the standard Can lead to inclusion of unnecessary deliverables or failure to include project-specific deliverables Not all projects fit into a highly structured set of WBS templates

Table 5-1. WBS Creation Methods

.1 Top-Down

The following steps describe the general top-down process for developing a WBS:

• Step 1. Identify the final products of the project—what must be delivered to achieve project success. A thorough review of high-level project scope documents (such as Statement of Work and Technical Requirements) is recommended to ensure consistency between the WBS and the project requirements.
• Step 2. Define the project's major deliverables, which are often interim deliverables necessary for the project, but which in themselves do not satisfy a business need (such as a design specification).
• Step 3. Decompose major deliverables to a level of detail appropriate for management and integrated control. These WBS elements are normally tied to clear and discrete identification of stand-alone deliverable products. The sum of the elements at each level should represent 100% of the work in the element above it, as noted in the 100% Rule. Each work package of the WBS should contain only one deliverable.
• Step 4. Review and refine the WBS until project stakeholders agree that project planning can be successfully completed, and that execution and control will successfully produce the desired deliverables and results.

.2 Bottom-Up

The following steps describe the general bottom-up process for developing a WBS:

• Step 1. Identify all of the deliverables (or work packages) involved in the project. If participants propose activities, then the associated deliverables, but not the activities, should be included (i.e., translate suggested activities into associated deliverables). This will encompass the entire output of the effort. Each work package should contain only one deliverable.
• Step 2. Logically group related work packages (or deliverables) together.
• Step 3. Aggregate deliverables to the next level, for instance, the parent level. The sum of the elements at each level should represent 100% of the work below it, as noted in the 100% Rule.
• Step 4. Once a given group of related tasks has been aggregated to a parent, analyze the subset again to ensure that all of the work has been encompassed.
• Step 5. Repeat until all subelements have been aggregated to a single parent representing the project. Ensure that the completed structure includes all of the project scope.
• Step 6. Review and refine the WBS until project stakeholders agree that project planning can be successfully completed, and that execution and control will successfully produce the desired deliverables and results.

.3 WBS (Organizational) Standards

An organizational WBS standard is a set of principles for constructing a WBS and might include a format, numbering scheme, naming convention, or required elements. WBS standards are common in many organizations with a high level of project management maturity. These standards help ensure consistency and completeness in WBSs throughout the organization. Examples of WBS standards include the following:

• Project management must be a Level 2 WBS element
• Graphical and textual WBS views must be developed and maintained.

.4 WBS Templates

A WBS template is a sample WBS, with hierarchical elements filled in to some level of detail, or a generic WBS “container” that is customized (i.e., filled) with project-specific information. An organization can have templates for different types of projects and different life cycles.

The use of WBS standards and WBS templates helps promote consistency through reuse of WBSs or WBS components. When reusing existing components, be sure to customize the WBS to the specific needs and requirements of the project. Any non-required work or deliverables should be removed so that the WBS is aligned with the project scope. In addition, the questions defined in Section 5.2 should again be iteratively reviewed for these two methods. The use of standards and templates in the creation of WBSs helps promote quality assurance through the application of successfully applied WBS good practices.

The use of WBS standards and WBS templates differs from top-down and bottom-up methodology in that top-down and bottom-up are methods of creating new WBSs, while standards and templates involve the reuse of existing WBS materials.

5.2.2 Guidance in Choosing a Method for Preparing a WBS

In developing a WBS, the project management team needs to decide first which development method to use. The choice between a top-down or a bottom-up approach is somewhat personal, and can depend on the habits and thinking styles of the project team, as well as on organizational practices. Aside from those considerations, some guidelines and explanations for which approach might be more appropriate are as follows:

.1 Top-Down

Use the top-down approach in these situations:

• The project manager and project management team have little to no experience in developing Work Breakdown Structures. Top-down development allows for progressive understanding and elaboration of the WBS.
• The nature of the project's products or services is not well understood. The development of a WBS jointly with all stakeholders using the top-down approach is useful in gaining understanding and consensus when the scope and nature of the project is unclear.
• The nature of the project life cycle is not familiar or well known. Top-down development of the WBS more easily uncovers life cycle issues and characteristics.
• No appropriate WBS templates are available. When developing a WBS from scratch, it is far easier to start with the overall project deliverable, such as building a bicycle, and then iteratively determine subelements.

.2 Bottom-Up

Use the bottom-up approach in these situations:

• The nature of the project's products or services is well understood. For example, if the organization has developed very similar products or services on previous projects, the project team might already have a very good understanding of all interim deliverables required for the new project.
• The nature of the project life cycle is well known. If the organization always uses the same project life cycle, the interim deliverables for that life cycle are well known and can be used to begin bottom-up WBS development.
• Appropriate WBS templates are available. If the organization has WBSs from projects with similar products or services, and these can be reused, a bottom-up approach enhances the team's ability to customize the WBS template.

.3 WBS Standards and Templates

In general, if WBS standards or WBS templates are available, they should be used, with the caveats expressed in Figure 5-1. There are plenty of sample WBSs available in the literature, but the choice to use sample WBSs as templates must be made carefully. The organization can have WBS templates for very similar projects, and the use of these templates is highly encouraged. However, if the project significantly differs from other projects in the organization, and no template seems to apply, develop the WBS from scratch with a top-down approach.

.4 Iterations

Construction of the WBS is an iterative process and may rely on more than one method to produce the final high quality WBS. For example, a WBS template and the top-down approach may be used initially to determine the overall structure of the WBS, while it might be more appropriate to use the bottom-up method to verify that all the elements are present to achieve a particular deliverable.

Regardless of what method is chosen to prepare the WBS, the resulting WBS must have all the core characteristics of a high-quality WBS. The WBS must describe 100% of the work on the project, must be oriented toward deliverables rather than activities, and must be hierarchically arranged. For additional details on WBS quality principles, please see Chapter 4, and specifically Section 4.2 for a discussion of WBS core quality characteristics.

5.3 General Factors to Be Considered

In developing a WBS, the following basic tenets should be considered:

• Each WBS element represents a single tangible or intangible deliverable.
• Deliverables include both final and interim deliverables that are required to create the final results.
• Deliverables include intangible items, such as information/communication, integration, administration, training, process management, and procurement.
• All deliverables are explicitly included in the WBS.
• Deliverables are unique and distinct.
• All significant reporting mechanisms, such as review meetings, monthly reports and test reports are included and identified in the WBS.
• Clearly defining the project deliverables, so that each is unique, ensures there will be no duplication in the outcomes of the project or of the work performed to produce the end-products.
• Accountability for each work package can be assigned to a single project team member or subcontractor. If this is not possible, then reconsider whether or not the work package can be further decomposed.
• Each element in the WBS representing subcontracted or externally committed deliverables directly corresponds to matching elements in the subcontractor's WBS.
• The deliverables are logically decomposed to the level that represents how they will be produced and managed (e.g., designed, purchased, subcontracted, or fabricated).
• All WBS elements are compatible with organizational and accounting structures.

The following basic guidelines should be considered when organizing WBS elements into the WBS hierarchy:

• Each WBS element belongs to only one parent WBS element.
• The set of child elements into which a parent element is decomposed includes all of the work contained in the parent, such that the 100% Rule applies.
• A coding scheme is used for WBS elements that clearly represents the hierarchical structure when viewed in text format.
• All “legs” of the WBS need not be to the same depth. Some areas of the WBS will need to show more detail than others.
• There is no need to have all work packages at the same level.

The WBS development process should:

• Be iterative
• Be reviewed and revised as the rest of the project planning process progresses
• Provide a vehicle for flexibility, particularly when the scope of the project effort might change.

A well-managed project, however, will incorporate a rigorous change control process to document and manage scope changes. When work scope changes do take place, the WBS must be updated. Any change in the WBS requires an associated change in related project management tools, such as the WBS Dictionary, network diagram, and schedule.

5.3.1 Project Management Knowledge Area Considerations

In the iterative WBS development process, the following guidelines and questions should be considered as they relate to each Project Management Knowledge Area in the PMBOK® Guide—Third Edition:

.1 Project Integration Management

• Include work in the WBS for the integration of components. Place the WBS element for component integration at the same level as the components being integrated.
• Include work in the WBS for the necessary communications and meetings required for effective integration management.
• Is the work defined by the WBS grouped in a logical manner? Have all reporting and control mechanisms been addressed?

.2 Project Scope Management

• WBS development is critical to scope management. Revisit the WBS often and expect to iterate WBS development.
• Are requirements defined and approved?
• Is there a statement of work, a set of contract requirements, or other documented requirements? Be sure that each WBS element can be traced to these requirements. Include only those activities that are considered in scope and can be traced to contractual or other requirements.
• As the WBS is defined, keep a list of activities and efforts that are considered to be out of scope. Confirm scope with stakeholders often by reviewing the WBS and the out of scope list.
• Are all deliverables explicitly identified in the WBS?
• Will horizon or rolling wave planning be applied to develop or further decompose the scope progressively over time?
• Have historical data, risk registries, checklists, and lessons learned been consulted to ensure identification of all work?

.3 Project Time Management

• Deliverables should be decomposed to the level of detail needed to estimate the effort required to obtain or create them.
• How will the status of work in progress be determined?

.4 Project Cost Management

• Deliverables should be limited in size and definition for effective control—not so small as to make cost of control excessive, and not so large as to make the item unmanageable or the risk unacceptable.
• How will budgets be established?
• Will it be possible to relate the budget to the proposed work assignments?
• Is the level of detail in the WBS appropriate for effective planning and control?

.5 Project Quality Management

• Will the quality of the work be evaluated through efforts such as testing and inspection?
• Are there quality requirements for the project? If so, be sure to include WBS elements to document the periodic review of quality requirements, quality management activities, quality audits, and quality reviews.
• Are there requirements to show compliance with ANSI, ISO or other standards? If so, include WBS elements for outside auditing of the project for compliance.
• Are there quality requirements defined for the deliverables outlined in the WBS?
• Have metrics been defined for how the deliverables will be measured?

.6 Project Human Resource Management

• Ensure that each WBS element has a single point of accountability. If a WBS element might involve more than one accountable person, consider decomposing the WBS element.
• Is all the work planned to a degree of detail necessary to make and keep commitments?
• Ensure that the reporting structure indicated by this WBS supports establishing and managing individual work assignments.
• Can work assignments be established from a progressive expansion of the WBS?
• How will work generally be assigned and controlled?
• Will it be possible to reconcile individual work assignments to the formal scheduling system?
• Is more than one organization involved, requiring validation of the WBS with others before doing detailed resource planning?

.7 Project Communications Management

• Have all communication needs been accounted for?
• Are there long distance, Regional, National and International communications required?
• Are there any special deliverables required for international communications, such as translations and other country-specific requirements?
• Are there special communication needs for any deliverables outlined in the WBS?

.8 Project Risk Management

• For areas of the WBS that are considered high-risk, consider decomposing the WBS to a more detailed level. This will allow better definition of assumptions and expectations, and will allow for more accurate planning, thus reducing risk.
• Are the deliverables completely and clearly defined?
• What is the likelihood of change?
• Is the technology changing faster than the project can be accomplished?
• Have manpower, facilities capability, availability of internal resources, and potential suppliers been checked?
• Has a formal change process been defined and implemented?
• Have metrics been defined for how the deliverables will be measured?
• Have resource requirements been identified for development of the project deliverables?
• Have other risks been identified, including stakeholder buy-in, public relations, management approval, team understanding, and project opposition?
• Has both an internal and external communication plan been defined and implemented?
• Are third-party dependencies understood and monitored for change?
• Have alternate suppliers of required products, supplies, or expertise been identified?
• Have historical data, risk registries, checklists, and lessons learned been consulted to ensure identification of all risks?
• Has risk management and contingency work been included?

.9 Project Procurement Management

• Is extensive subcontracting expected?
• Is there a WBS element for each procured deliverable?
• Are intangible deliverables required for managing the procurement process?
• Will procurement be managed by the project team or by an existing procurement organization?

5.4 Essential Judgments

Effective application of use-related characteristics relies on experience and judgment. This section examines that concept in a bit more detail. Factors that can vary from one project or application to another, depending upon the purpose for which the WBS is intended, include, but are not limited to, the level of detail needed in the decomposition of the deliverables, the selection of the type of WBS element to be included, and structuring the logic of the decomposition.

5.4.1 Determining Appropriate WBS Level of Detail

The WBS development process has been described as proceeding to successive levels of increasing detail, culminating in a level of detail that captures all elements of the scope of the project. This process also provides needed insight for clear communications and effective project management. The level of detail in a WBS is a function of the size of the project, and reflects a balance between complexity, risk, and the project manager's need for control. The level of detail can also vary during the evolution of a project. A top-down and bottom-up analysis of the WBS can clarify whether the WBS is both complete and defined at the proper level of detail.

Short-duration projects can lend themselves to decomposition to a high degree (extensive level) of detail at the outset, while projects of longer duration and higher complexity can preclude decomposition of all deliverables until more is known about the project. Again, this means that on any given project, some portions of the WBS can have different levels of decomposition. This is especially true when doing rolling wave planning, where the plan is detailed only for the immediately upcoming work, and work far in the future is defined at a high level until later in the project life cycle.

When proceeding to successive levels of increasing detail, the 100% rule must still apply. This rule states that the children nodes of a parental node must make up 100% of the work of that parental node. Additionally, not all legs of the WBS must be symmetrical in terms of the number of levels developed. There is no need to decompose all legs of the WBS if the need is only present in one area.

Should the WBS be decomposed further? The following questions provide guidance for determining the need for further decomposition of the WBS. If the answer to any of these questions is yes, then further decomposition should be considered. The greater the number of positive answers, the stronger the justification for further division of some or all of the WBS.

.1 Scope and Work Package Detail

• Are clear, objective criteria missing for measuring the progress for the WBS element?
• Does the WBS element contain more than one deliverable?
• Do prerequisites differ among internal deliverables within the WBS element?
• Can a portion of the work to be performed within the WBS element be scheduled as a unit?
• Are there acceptance criteria applicable before completion of the entire WBS element?
• Is the WBS element clearly and completely understood to the satisfaction of the project manager, project team members, and other stakeholders—including the customer?
• Are there relationships between internal WBS element deliverables and other external WBS elements?
• Is there a stakeholder interested in analyzing status and performance of only a portion of the work covered by the WBS element?
• Can progress of the work be assessed as needed?

.2 Resources and Risks

• Can the work element be assigned to a single accountable individual? While there might be a variety of resources assigned to a given WBS element, there should ultimately be only one individual accountable for delivery of the work package.
• Are there specific risks that require focused attention to a portion of the WBS element?
• Can actionable risks be identified for each WBS element?

.3 Costs and Timing

• Are there significant time gaps in the execution of the work processes internal to the WBS element?
• Is there a need to improve the accuracy of the cost and duration estimates of the WBS element?
• Is there a need to separately define the cost of work processes or deliverables internal to the WBS element?
• Is there a need to precisely know and report the timing of deliverables internal to the WBS element?

5.4.2 Selection of the Type of WBS Element to be Included

A WBS organizes and defines the total work scope of the project. Not every WBS, however, needs to include all types of work. Rather, the kinds of work included in a WBS should be dictated by the scope and nature of the project for which the WBS is being developed. Some examples of this are presented here.

• Some projects require certain types of WBS elements that are not necessary for other projects. For example, in a project that involves production of several different components that need to be assembled into a finished product, it would be necessary to include an integration or assembly WBS element so that the assembly work can be identified, resourced, tracked, and reported. In contrast, a project to develop a business process might not require such an assembly element.
• All projects require a project management WBS element at Level 2, in order to ensure that the work of planning, tracking, and reporting is adequately captured and managed. A particular organization, however, might require use of a standardized WBS template that does not include certain kinds of project management WBS elements (for example, administration, documentation, or reporting elements) because the need for these is adequately addressed by other business processes established by that organization. In such cases, these elements would not be required.
• Quality assurance is applicable to all projects. Some organizations could have requirements for compliance with specific quality standards. In such cases, the WBS must include elements, such as documentation and audits, to account for compliance with the specified procedures.

5.4.3 Structuring the Logic of the Decomposition

An essential feature of a WBS is that it clearly and comprehensively defines the scope of the project work through decomposition of deliverables into a hierarchy of simpler components, thereby providing one of the primary methods for managing complex projects. The way that the project manager decomposes the project (i.e., the logic used for decomposing the work) can vary depending on the needs and requirements of the performing organization and the use to which the WBS will be put. This is illustrated by the following examples:

• One organization might be structured along very strict functional lines, with few business processes that facilitate communication among the separate subunits. In such a case, it can make sense to structure the decomposition in terms of the work and sub-deliverables that each function independently contributes. In contrast, in a projectized organization without functional divisions, the same deliverable might more effectively be decomposed into a hierarchy of subassemblies.
• Where new product development proceeds in sequential stage-like phases with later work contingent on the outcome of earlier work, it would make sense to organize the WBS in terms of the product development life cycle, rather than in terms of physical components of the product.
• A food-service enterprise with regional offices might find it particularly valuable to structure the WBS for a program to create a new chain of restaurants as a series of geographic subprojects, while a centralized enterprise that sub-contracts, for instance, building development, food sourcing, or marketing, would find it more useful to decompose the new restaurant program in terms of sub-systems.

In all cases, it is important that the WBS remain deliverable-oriented, rather than process-oriented, and explicitly contain all intermediate deliverables.

5.5 Evaluating WBS Quality

There are several points that are considered essential when creating a WBS. As detailed in Chapter 4, there is a set of core characteristics that every WBS must have, which enable it to satisfy project needs. Failure to address these considerations can lead to failure of the project, because there would be a high risk of not identifying all of the required work.

5.5.1 Core Characteristics

• The WBS structure is not based on timing or sequence dependencies among components. Timing, sequencing, and dependencies are project schedule concerns.
• The WBS is not structured strictly by process or organization.
• The WBS defines the logical relationships among all the components of the project.
• All WBS elements are deliverable-oriented.
• Project activities are not listed, as these are components of the project schedule, not the WBS.
• All element names are nouns. Verbs are not used to identify WBS elements.
• The WBS includes only sufficient and necessary deliverables. All deliverables are necessary components of the project's product, service, or end result, and are defined in the project's scope.
• All project deliverables including regulatory permits, packaging, distribution, or marketing, as well as preliminary, interim, internal, external, or final deliverables, are identified and detailed.
• There are no WBS elements with overlapping responsibilities. Each WBS element must have one person who is clearly accountable for its completion.

Also, as discussed in Chapter 4, there is an additional set of use-related characteristics that might vary from one WBS to another. These characteristics enable the use of the WBS for purposes that can be unique to a specific project, industry, or environment, or are applied in a particular way on individual projects. With respect to use-related characteristics, the quality of the WBS depends on how well the specific content and type of WBS elements meet the use for which the WBS was intended.

5.5.2 Use-Related Characteristics

• Identify key project management (non product) work such as:
  • Initiating, planning, executing, monitoring and controlling, and closing
  • Process management
  • Services and provisioning
  • Information/communication
  • Administrative documentation, training, and software.
  These should be defined as level-of-effort WBS elements in those cases where they can be interim deliverables, do not themselves generate discrete deliverables, and might not be included in the delivery of the final product.
• Include cross-project WBS elements, such as those representing opening and closing stages, for example, planning, assembly, integration, and testing.
• Balance the project definition aspects of the WBS with the data collecting and reporting requirements. The primary purpose of the WBS is to define the project's scope through the decomposition of deliverables.
• Decompose the WBS to the appropriate level of detail by achieving a balance between project complexity, risk, and the project manager's need for monitoring and control.
• Do not decompose the WBS too far. Each WBS is a tool designed to assist the project manager with decomposition of the project only to the levels necessary to meet the needs of the project, the nature of the work, and the confidence of the team. Excessive WBS levels can require unrealistic levels of maintenance and reporting.
• Do not omit WBS development, such as Gantt chart, CPM schedule or precedence diagram before proceeding to the network diagram. Omitting the development and refinement of the WBS can lead to unforeseen and unexpected difficulty, including project delays, cost over-runs, or outright project failure.

5.6 WBS Usage Continuum

The ability of a WBS to meet the needs of a project is directly related to the level of project management competency available within the project management team.

An experienced project management team will be able to identify a greater range of stated and implied project needs that the WBS can address. A more experienced project management team will ensure the WBS is employed in a greater variety of project roles, and will use the WBS in more efficient and sophisticated ways than will a novice or inexperienced project management team. A WBS can be of high quality even if it is not being used to its full capacity by the project management team.

The project management team's development and use of the WBS as an effective planning and control tool represents its position on the WBS usage continuum. In other words, once the project management team begins using a WBS within the project context, their ability to make the WBS play an important defining and controlling role for scope, budget, and risk follows a growth continuum similar to that of any other project management methodology or tool. The following is an experience continuum for WBS development and use:

5.7 WBS for Program and Portfolio Management

According to the PMBOK® Guide—Third Edition, projects, programs and portfolios are defined as follows:

Project. A temporary endeavor undertaken to create a unique product, service, or result.

Program. A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program.

Portfolio. A collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives. The projects or programs of the portfolio may not necessarily be interdependent or directly related.

Work Breakdown Structures are useful not only for projects, but for programs and portfolios as well. Use of the WBS at these levels is a growing practice. There is no conceptual difference among a project WBS, a program WBS, or a portfolio WBS. A high-quality WBS developed at any of these broader levels possesses precisely the same characteristics and attributes as a high-quality WBS developed at the individual project level. These differ only in the breadth of the content (scope).

All of the principals defined in Section 4 that apply to a project WBS also apply to a program or portfolio WBS. Great care should be taken, however, when working with WBSs beyond the program level. The difficulty in verifying that all work and deliverables are defined increases significantly as the scope increases.

5.8 Summary

This chapter has shown that there are many ways in which a WBS can be created. It can be developed as an entirely new document, can reuse components from existing WBSs, can be based on a template, or can follow predefined WBS standards. Regardless of the method used to construct it, the WBS evolves through an iterative consideration of the project's scope, including the project's purpose and objectives (both business and technical), functional and performance design criteria, technical performance requirements, and other technical attributes.

This chapter has presented several guidelines and checklists to assist in the preparation of a WBS. All other Project Management Knowledge Areas (such as Project Time Management, Project Cost Management, and Project Quality Management) are highly dependent upon the resulting WBS. In the end, a high-quality WBS provides a strong foundation upon which to build a successful project.