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.

tip

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

Term	Description	Key Factors	Notes
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
WBS	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

tip

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

Acronym	Description	Notes
CWBS	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.
OBS	Organizational Breakdown Structure	Maps work components to organizational units.
RBS	Resource Breakdown Structure	Maps work components to individuals.
BOM	Bill of Materials	Describes the physical components needed for the project.
PBS	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.