What Is a WBS Exactly?

As I mentioned in Chapter 1, "Project Management Overview," project management is not "brain surgery" and does not require advanced logic and reasoning skills to achieve winning results (see author for great example of this). In most cases, the disciplines and terms used in project management are very "common sense" and obvious in nature. A WBS is a classic case. As the terms defining the acronym indicate, a WBS is logical "breakdown" (decomposition) and representation (hierarchical "structure") of the "work" required by the project.

A WBS can take one of two forms: graphical or outline. See Figures 6.1 and 6.2 for examples of each.

Figure 6.1. Partial graphical WBS for a software selection project.

Figure 6.2. Partial outline WBS for a software selection project.

Both types have their place in your toolbox. The graphical form is best for communicating the top 35 levels of work activity to senior management or customer stakeholders. The outline form is best for capturing the details needed for cost and schedule development.

A WBS shows the work and any interim deliverables that will be required to produce the major project deliverables identified in the project definition process. In most cases, the WBS reflects the components that make up the final deliverables and the approach (methodology) used to develop, integrate, and validate them. In short, the WBS is an organized task list.

WBS is a logical, hierarchical, organized task list developed with the team.

By simply doing this, we create an organized picture that allows us to see, and more importantly, allows our stakeholders to see, all of the work required to accomplish the project objectives. You can begin to see the power of the WBS in managing expectations.

Also, by doing this, we employ the primary secret weapon of managing large, complex projects, which is "You don't!" You break the work down into chunks and manage many smaller components.

I'm not going to spend a great deal of time on explaining how to create a WBS and how to break down the higher level work of a project, because I think most analytical people do this naturally, and the details of the work decomposition will depend upon the specifics associated with your organization and industry. In fact, many organizations leverage standard WBS templates to ensure any new project includes the recommended work items.

However, what I will spend time on is making sure you are clear on terminology, making sure you understand how this step fits into the overall schedule development process, and reviewing the best practices of WBS development.


Always clarify terms with your project team and project stakeholders in any communication.

For an official repository of project terms, the use of a project glossary document can be helpful.


Isn't WBS Just Another Name for the Project Schedule?

Many industries and organizations routinely use the following terms in an interchangeable fashion: WBS, project plan, project schedule, and work plan. As you know by now, these terms do represent different project management elements and should not be used interchangeably. However, as with all "less than ideal" practices, there are reasons. Understanding the reasons is always helpful, and in this case, can provide additional insights as to why projects can get into a "troubled" state.

When you think about the process for developing a schedule (see Figure 6.3), determining the work (detail tasks) that is required is the first step.

Figure 6.3. The role of the WBS in the development of the project schedule.

Once you have identified the work tasks, you can then determine what resources are required for each task, how much effort each task will take (process details discussed in Chapter 7, "Estimating the Work"), and what logical dependencies exist between the tasks (these details are covered in Chapter 8, "Developing the Project Schedule").

At this point, you can begin to construct the first of several iterations of a project schedule.

Sounds logical enoughso, where's the problem?

In general, the problems lie with the use and application of project scheduling software such as Microsoft Project. Here's a common scenario:

  • Joe Manager is told to go build a work plan for the project.
  • Joe Manager goes to his desk and opens up MS Project and starts entering and organizing the tasks that need to be performed.
  • Joe Manager enters estimated durations and start and end dates for some of the key or most visible tasks.
  • Joe presents results to his supervisor for review.

So, what did Joe present to his boss? A WBS? It does have work tasks listed. A project schedule? It was created in MS Project. A work plan? That's what his boss asked for. Well, what you probably have here is a high level WBS and an initial milestone schedule summary, at best. This example illustrates how an inadequate project planning and schedule development process combined with inadequate training on the project scheduling software can lead to "terminology" confusion. Table 6.1 summarizes these terms and the factors that lead to their interchangeable use.

Table 6.1. Terms Used for Planning Project Work



Key Factors


Project Plan

All-encompassing planning document used as basis for execution and control

Often incorrectly used to describe project schedule or work plan

Common tendency to think of project "scheduling" software as project "management" software

Project Schedule

Shows when the work will be done and by whom Drives project execution

Many "schedules" are more like task lists (WBS), because the task depend-encies and resource assignments are not properly captured

Inadequate training on project scheduling software

Inadequate schedule development and review process

Work Plan

A generic term used to refer either of the other three

Usually refers to project schedule

Need to clarify terms up-front


Work Breakdown Structure Hierarchical representation of work to be performed

WBS often created with project scheduling software (MS Project)

WBS templates often created and saved with project scheduling software (MS Project)

Use of project scheduling software is acceptable as long as the proper process is followed


Key Differences Between the WBS and the Project Schedule


Avoid judging a current work practice or process or the people involved before you understand "why" it is done this way or "how" it evolved to the current point.

This approach will keep you results-focused, improve your ability to develop solution alternatives, increase your effectiveness in leading change, and enhance your relationships with all stakeholders.

The key differences between the WBS and the project schedule include the following:

  • Task dependencies WBS does not show them; a project schedule does.
  • Scheduled tasks WBS does not show when tasks occur; a project schedule shows start and end dates for each task.
  • Task assignments WBS does not show who is assigned to individual task; a project schedule does.

Different Types of Breakdown Structures

Another factor that can impact understanding of the WBS term and concept is that many industries utilize other breakdown structures and related acronyms that can confuse this subject. Therefore, to better understand what is meant be a WBS, you should be familiar with these other types of breakdown structures, as listed in Table 6.2, and how they are different from a WBS.

Table 6.2. Different Types of Breakdown Structures





Contractual WBS

Defines the level of reporting between the seller and buyer. The CWBS is not as detailed as the WBS used to manage the actual work.


Organizational Breakdown Structure

Maps work components to organizational units.


Resource Breakdown Structure

Maps work components to individuals.


Bill of Materials

Describes the physical components needed for the project.


Project Breakdown Structure

The PBS is actually the same as the WBS. This term is only used in areas where the term WBS is incorrectly used to refer to a BOM.

Part i. Project Management Jumpstart

Project Management Overview

The Project Manager

Essential Elements for any Successful Project

Part ii. Project Planning

Defining a Project

Planning a Project

Developing the Work Breakdown Structure

Estimating the Work

Developing the Project Schedule

Determining the Project Budget

Part iii. Project Control

Controlling a Project

Managing Project Changes

Managing Project Deliverables

Managing Project Issues

Managing Project Risks

Managing Project Quality

Part iv. Project Execution

Leading a Project

Managing Project Communications

Managing Expectations

Keys to Better Project Team Performance

Managing Differences

Managing Vendors

Ending a Project

Absolute Beginner[ap]s Guide to Project Management
Absolute Beginner[ap]s Guide to Project Management
ISBN: 078973821X
Year: 2006
Pages: 169

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net