Before you enter tasks in Project 2007, you need to decide what your project tasks are. The starting point for this is to develop a Work Breakdown Structure (WBS).

We strongly suggest that you start by creating a WBS and use that as the basis for creating your schedule.

According to PMI, a Work Breakdown Structure (WBS) is “a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables.”1

Whew! Let’s look at a couple of the key phrases of this definition.

A WBS is “Deliverable-Oriented”

A deliverable is “any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase or project.”2

Deliverables are the products the project is going to produce: both final deliverables that you hand off to your client, (e.g., a completed computer program, building, or relocation) and interim deliverables that your stakeholders use during the project (e.g., a weekly status report).

The WBS should cover 100% of your project’s scope and capture all of your key deliverables. It is generally accepted project management practice that work that is not in the WBS is not within the scope of the project. You need to establish this understanding early with your project stakeholders: if the client requests a deliverable during project execution that is not in the WBS, it is out of scope.

Use your WBS as the baseline for integrated change control: if the requested deliverable was not agreed upon and included in the WBS, it must be negotiated under the project’s change control procedures as an addition to the project.

The work described in the WBS is also the basis for estimating, scheduling, and assigning responsibilities on the project. It is the means for tying project objectives and requirements to the work required to deliver them.

A WBS is a “Hierarchical Decomposition”

When we say that a WBS is a hierarchical decomposition, it simply means that your WBS should break down (decompose) your primary deliverables into smaller, more manageable parts, and that this decomposition should be organized in a logical (hierarchical) way.

Shown below is a portion of a simplified WBS:

Figure 1: A portion of a simplified WBS.

As you can see, the sample WBS:

• Contains the project deliverables (e.g., “2.1 Software Requirements”, “2.2 Initial Software Design” and “2.3 Final Software Design” are all deliverables).
• Has deliverables that are decomposed into smaller parts.
• Is organized in a logical manner to identify the work required to produce the deliverables.

Organizing Your WBS

There are many ways to organize your WBS, e.g., by key deliverables, physical components, chronological phases in the project life cycle, functional specialties, or in a program by project and sub-project.

In our sample WBS above, we organized the WBS by deliverables. Here’s the same WBS, organized by phases—requirements phase, design phase, etc.

Figure 2: Organizing the WBS by deliverable.

Notice that both examples contain the same deliverables.

Regardless of how you organize your WBS, it should be deliverable-oriented, i.e., it should explicitly contain all of the key deliverables for your project.

According to PMI, a WBS with phases and activities only and no deliverables is not a WBS! Every phase, activity, or task must have one or more deliverables. Including deliverables in your WBS makes sense:

• The WBS should be an elaboration of the deliverables promised in the project’s Scope Statement. A deliverable-oriented WBS makes it easier to track work back to the Scope Statement.
• Because many of your deliverables are the key products you’ll be delivering to your client, your client will find it easier to understand a deliverable-oriented WBS.
• Deliverables are often tangible and easily understood when making team assignments. Imagine that you were made responsible for either “researching requirements” (an activity) or for delivering the “list of requirements” (a deliverable) for a project. The latter is a concrete deliverable; it is verifiable and therefore creates a firmer commitment.
• A deliverable-oriented grouping enables you to get useful reports from Project 2007, like an effort or cost by deliverable report.
• Once you identify and describe deliverables, it is easier to identify, estimate, and schedule the activities needed to create those deliverables.

Our definition of a deliverable includes the phrase: a deliverable is “any unique and verifiable product, result, or capability.3” By describing each deliverable identified in the WBS, you create verifiability in the project: you clarify what you are going to produce at each step of the way. When you ask your client to sign off on the WBS and the definition of deliverables, you have established how task and project completions will be verified. This practice of identifying and describing deliverables early in the project will decrease misunderstandings that can become fatal if not surfaced until near the end (when they typically result in nasty disputes or litigation).

You may not be used to thinking in terms of deliverables, and it can take practice to learn to identify them. However, it’s important to put some effort into this. After all, if you can’t define the deliverables, how will you and your stakeholders ever agree upon what needs to be done? It’s a common view that if you can’t identify the deliverables for a project, you don’t have a project.

Phases in the WBS

Often the WBS is organized by phases — distinct periods in the life of a project such as requirements, analysis and development. If you organize by phase, it’s important to identify the deliverables for each phase. For example, the requirements phase may produce requirements definition, the analysis phase designs, and the development phase software modules. These interim deliverables are necessary in many projects to enable a controlled process with checkpoints between phases.

While phases can establish a chronology for the project, it’s important to note that the focus during WBS development should be on identifying, defining, and decomposing deliverables; not on sequencing and scheduling. This comes later.

Chronological breakdowns in your WBS can make it harder to manage iterative (repeating) processes. Iterative processes are common in projects, often as a result of the progressive elaboration of project requirements and designs as the product is developed.

For example, you might create a requirements document during the requirements phase, refine it in the analysis phase, and finalize it in the development phase. If your WBS is organized by chronological phases, work on your requirements document will be scattered across all three phases, making it more difficult to track progress on the deliverable, a finalized requirements document. In a deliverable-oriented WBS the work on the requirements document will all be listed in a single section and you can add activities with ease.

Indented List or Organization Chart Format?

You can build your WBS either as an indented list or in a format similar to an organization chart, with the summary tasks — generally the largest or most important deliverables — toward the top and the detail tasks underneath.

The Bottom Line

There are times when organizing your WBS by phase makes perfect sense. We recommend that in large projects you consider using a combination of phases and deliverables in your WBS. Just make sure that if you do use phases in your WBS, you’ve also captured all your deliverables.

Notes:

1 PMBOK® Guide − Third Edition, PMI, 2004, p. 112.
2 Ibid., p. 232.
3 Ibid.

This article is excerpted from Dynamic Scheduling with Microsoft Office Project 2007, published by J. Ross Publishing. Reprinted with permission from the publisher.