The Process of Building a WBS

Now that we understand what a WBS is and the importance it plays to our project, let's review the key techniques, guidelines, and principles in building an effective WBS.

In general, the process of breaking down work is something we do frequently and is a straightforward logical endeavor. However, there are frequently two common challenges in the WBS development process.

• Where do I start?
• Where do I stop?

Getting Started

To start the work decomposition process, think about the following:

• Does a template WBS exist as part of our methodology or from a past project that I can use?
• What are the major deliverables?
• What is the project approach? The project lifecycle? The major project phases?
• Think through the entire project. What does the "end" look like?

To continue the work decomposition process, think about these questions:

• Can I break down this WBS element (deliverable) into sub-components?
• How exactly will the deliverables be produced? What processes and methods will be used?
• How do I ensure acceptable quality in deliverables and in the process?
• Can I make adequate costs and duration estimates from this level of detail?

Guidelines for Effective WBS

Here are a few "guidelines" regarding the development of the project WBS that you will want to keep in mind:

• All the work of the project is included in the WBS.
• The WBS should be "deliverable focused."
• All deliverables are explicit in the WBS.
• The WBS should be developed "with the team."
• The WBS is refined as the project progresses.
• The WBS is a top-down decomposition and is logicalthe summary tasks go with lower level tasks.
• The WBS should be organized in a manner that emphasizes the most important aspects of the project and that best communicates the entire scope of the project to your stakeholders.
• The lowest level of the WBS is the work package or activity level and is used for schedule and cost development. This is the level where effort and cost can be reliably estimated.
• Unique identifiers are assigned to each item in the WBS to allow for better management reporting of costs and resources.
• WBS elements should be consistent with organizational and accounting structures.
• The coding scheme should clearly represent a hierarchical structure.
• Review and refine the WBS until all key project stakeholders are satisfied.
• Each WBS element represents a single deliverable and should be an aggregation of lower level WBS elements.

  tip

  WBS should always be defined at least one level lower than what is required for management reporting purposes. This allows you to better identify the source of any issues or variances.

• Each WBS element has only one parent.
• Upper levels of the WBS represent major deliverables or project phases.
• The WBS should include project management tasks and activities.

  In general, the more detail in the WBS, the more accurate the work estimates and the better level of control. However, there is a balance. Too much detail and you will incur excessive costs performing data collection, tracking, and reporting. Too little detail and you incur higher risks and be unable to effectively manage.

• The WBS should include and isolate any work needed to integrate components/deliverables.
• The WBS should account for any subcontracted or externally committed deliverable.
• The WBS should represent all work needed to ensure completeness, correctness, and acceptance of deliverables.
• Depth of WBS depends on three key factors:
  • The amount of project risk.
  • The reporting requirements.
  • The balance of control versus costs.

The level of depth (granularity) for the work package level in a WBS (lowest levels) will vary. It depends on what level of detail the project manager needs for effective management and control of the project.

In a program, or on large projects, the work package level may represent efforts in the hundreds of hours. In these cases, it is expected that the teams assigned to these work packages (or subprojects) will define the detail activities and tasks needed to complete the work package. From a practical standpoint, these teams should develop their own WBS that can then be rolled-up into the master WBS.

caution

Knowing When to Stop

The other aspect of WBS development that creates frequent uncertainty is knowing when to stop. To determine if you have enough detail in your WBS, review these questions for each lower level item:

• Can each lower level item be estimated, scheduled, budgeted, and assigned to a responsible party?
• Do I need more detail to make it easier to estimate effort, assign work, track costs, or measure progress?

  You will read about common rules of thumb for the proper size of work packages. The most common rules are 8/80 and 4/40, which means no task should be less than 8 hours or more than 80 hours, or in the case of 4/40, it would less than 4 hours or more than 40 hours. These are solid guidelines, but not rules. The most important thing to remember is to size the work package to the level you need for effective management and control. Again, setting the maximum size to correspond to your reporting period is an excellent idea.

• In addition, consider further decomposition of the lower level item, if any of the following are true:
  • The work cannot be completed within the standard reporting period for the project.
  • There are specific risks associated with a smaller portion of the work element.
  • More than one individual or group is responsible.
  • More than one deliverable is included.
  • More than one work process is included.
  • There is time gap involved.
  • The resource requirements for the work element are not consistent.

The importance of the WBS cannot be over-emphasized. Since the correctness and completeness of the WBS has a direct impact on how well we determine our resource needs, estimate the work efforts, and properly sequence the work, it is the foundation that drives our schedule and most of our planning efforts.