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.

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

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.

Key Differences Between the WBS and the Project Schedule

tip

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.