The Process of Building a WBS

Through the previous post we understood 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. There are frequently two common challenges in the WBS development process:

• Where do I start?

• Where do I stop?

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 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 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?

Following are a few guidelines regarding the development of the project WBS that you 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 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.

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

·        Depth of WBS depends on three key factors:

• Amount of project risk

• Reporting requirements

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

Now the next question, 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 you need more detail to make it easier to estimate effort, assign work, track costs, or measure progress?

·        In addition, consider further decomposition of the lower-level item, if any of the following are true:

o   The work cannot be completed within the standard reporting period for the project.

o   There are specific risks associated with a smaller portion of the work element.

o   More than one individual or group is responsible.

o   More than one deliverable is included.

o   More than one work process is included.

o   There is time gap involved.

o   e resource requirements for the work element are not consistent.

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. Any work not defined in the WBS is considered to be outside the project scope.

There is no one way to organize a WBS. It should be organized in a manner that emphasizes the most important aspects and that best communicates the entire scope of the project to your stakeholders.

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. A well-done WBS can become a template for similar, future projects.

Here I am ending this post. In the next we shall discuss work estimation.