The Process of Building a WBS

Now that you understand what a WBS is and the importance it plays in your 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 your methodology or from a past project that you can use?
• What are the major deliverables?
• What is the project approach? The project life cycle? 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 you break down this WBS element (deliverable) into subcomponents?
• How exactly will the deliverables be produced? What processes and methods will be used?
• How do you ensure acceptable quality in deliverables and in the process?
• Can you 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 want to keep in mind:

 Note

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

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 are unable to effectively manage.

• 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 logical—the 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. CautionMost troubled projects have WBS elements that are too large. If each lower-level element should be completed within the standard reporting period (every week or every two weeks), it is much easier to track actual progress and to take any corrective actions.
• 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.
• 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.
• The WBS should include and isolate any work needed to integrate components and 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.
• The depth of WBS depends on three key factors:
  • Amount of project risk
  • Reporting requirements
  • Balance of control versus costs NoteThese are solid guidelines—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.

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 might 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.

Knowing When to Stop

The other aspect of WBS development that creates frequent uncertainty is knowing when to stop. To determine whether 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 you 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 be less than 4 hours or more than 40 hours.
• 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 a time gap involved.
  • The resource requirements for the work element are not consistent.

The importance of the WBS cannot be overemphasized. Because 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.

Do I Need a WBS for an Agile Project?

You might be wondering if this WBS development process applies to you if your organization is using agile project management. Let me assure you…it does. The main difference is when this work breakdown occurs. For an agile project, the targeted work items are prioritized and details refined on an iterative basis rather than attempting to do it all upfront. In addition, the tool that manages the Product Backlog (the work items yet to be completed) would capture all of the WBS work packages. But in the end, the quality of your schedule and your ability to manage expectations are dependent on the degree that all of the work required was accounted for in the plan. Missing work items are a common reason why all the planned work for an agile iteration or sprint was not completed within the designated time box. Of course, this is one of the advantages of the agile development approach. The inherent feedback loops and iterative planning processes for each work iteration help identify these gaps sooner and allow you to adjust plans accordingly.

The Absolute Minimum

At this point, you should have a solid understanding of the following:

• A WBS is a logical breakdown of all the work to be performed by the project.
• A WBS is neither the project schedule nor the project plan.
• The WBS should be developed with the project team.
• The WBS is a vital tool to the project manager.
• Avoid judging a current work process or the people involved before you understand why it is done this way or how it evolved to the current point.
• You learned how to evaluate a WBS.
• You learned how to avoid the common challenges and issues with WBS development.
• The WBS is the foundation for developing a realistic schedule, determining project resource needs, and figuring an accurate project budget.
• The work packages included in the WBS should be detailed enough to support effective management and control.
• The maximum size of a WBS work package should correspond to the standard reporting period for the project.
• For an agile project, the WBS is essential, corresponds to the Product Backlog, and is continuously refined.

The map in Figure 6.4 summarizes the main points.