WBS Project Management

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

Our 25 years of experience helping organizations improve their project performance has taught us that the work breakdown structure or WBS is the best predictor of the success of a new project. By reviewing the work breakdown structure before a project starts it is relatively easy to determine five key project success factors:

  • Will the project team members clearly understand what the PM expects of them?
  • Will the project manager be able to identify problems early when they are small rather than after it is too late to fix them?
  • Will executives and the project sponsor be able to assess progress versus the plan?
  • Will the estimates of work, cost and duration be reasonably accurate?
  • Will the project manager be able to exercise tight control and spot problems early without micromanaging the team?

It is very efficient to assess the entire project planning process by reviewing the work breakdown structure before work starts. At that point, the PM can still make corrections and avoid dozens or hundreds of hours of wasted time. In fact, this is such an efficient insurance policy on new projects that we recommend to our clients that it be part of the organizations pre-launch project review.  This pre-launch review of the WBS does not take a great deal of time even if the work breakdown structure is large. Main WBS Work Breakdown Structure Page

WBS Project Management: Pre-launch Pressure

Right before the project launch is a stressful time for project managers and project sponsors. There is tremendous pressure to start work. But of a few hours of delay for a WBS review can save many days of wasted time and head off project failure. Because of the pressure-filled environment, we recommend that this pre-launch WBS review be a mandatory part of the organization’s project management protocol. The review takes place at the end of the project planning process. No matter how big or small the project is, the project manager is always suffering from near-sightedness at that point. It’s very hard for the project manager who created the WBS to see its flaws as well as its strengths. Because errors in the work breakdown structure are so costly and so difficult to correct later on, it is advantageous to have another project manager who was not involved in the planning evaluate the WBS.

WBS Project Management: Review Process Steps

You begin the review of the work breakdown structure for another PM’s new project by looking at the structure of the WBS. Look to see if the entries are organized into subheadings for each of the major deliverables of the project. If so, ask a couple of questions of the project manager who developed this WBS. Did the project sponsor and major stakeholders of the project sign off on the project scope and 4 to 7 major deliverables? If the project manager says no, they must go back to the drawing board. Clearly they can’t launch a project that has not been approved by the sponsor and stakeholders.comm23

If the PM’s answered yes, the next item to examine is the entries in the WBS including the high-level deliverables and the scope. Are they deliverables that describe an end result and the acceptance criteria that the sponsor will use to judge the work? You should see deliverables like, “Customer history database is 99% accurate,” or “Average response time on the network is less than three seconds” or “Quality control has signed off on the product prototypes.” The PM should define each of those deliverables with the acceptance criteria that are either metrics or a yes/no. In other words, they are objectively measurable. If every entry in the work breakdown structure does not meet this measurability criterion, the project should not be launched. The reason this is so critical is that properly defined deliverables tell the team members what’s expected and let the sponsor and executives track progress unambiguously.

The third item to examine is the size or average duration of each of the deliverables. What you’re looking for is micromanagement where the project manager has defined a very large number of WBS entries that have a duration of an a few hours. If you see that kind of excessive detail, you know several problems will occur. First, the project manager will not be able to keep the project plan current because there is far too much detail. Second, with that micro level of detail it is likely that every one of these entries will change over the course of the project and the project manager will not be able to keep it up to date. And a project plan that is three weeks out of date is the same as having no plan at all. What you are looking for on most projects is an average task size that is about a week’s worth of work. Some tasks will not require that much time and others will require several weeks of time. But on the average, you are looking for about a seven-day duration for each of the WBS entries.

The next item to check is the adequacy of the deliverable definitions for making duration and work estimates. This is a subjective area but you want deliverables that are defined with sufficient precision that the team member and project manager can make an accurate estimate of the work involved. If there is inadequate precision, the project manager will develop work packages for the assignments with weak definitions.

Finally, you need to examine the WBS to determine whether the project manager will be able to exercise tight control and spot problems early without micromanaging the team. Here you have to look a bit beyond the WBS and determine the requirements for the status report and the frequency of the project manager’s reports. The most important requirement is that the team members provide the PM with an estimate to completion each week. That is the key to project managers being able to identify problems early on any component of the WBS.

When you are evaluating a work breakdown structure for another project manager, it’s always best to look at it from the perspective of all the different audiences who will use that work breakdown structure. That will let you give the PM helpful, well-rounded feedback.

Create WBS

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.co

The WBS or work breakdown structure is a listing of every deliverable that the team must produce. Creating the WBS with team members  is a great opportunity to improve people’s commitment to the project and give them a sense of ownership. Usually, the project team sees their tasks after the project manager lists everything they have to complete. That yields very little ownership and even the lack of understanding of how each team member’s deliverable connects to the overall scope. Main WBS Work Breakdown Structure Page

The starting point for working with your team is after the project sponsor has approved the scope and 4 to 7 major deliverables in the project. Note that all of the entries on the work breakdown structure are deliverables with acceptance criteria like, “Error rate less than 3%.” That acceptance criterion could cover an entire project or it could be one high-level deliverable in a project aimed at improving customer service. Finally, it could be the deliverable assigned to an individual.  However, every entry has a metric that tells people what a good job is. Having your team participate gives them an understanding of how the entire network of deliverables fits together.

Create WBS with Team MembersCreate WBS: Brainstorming With the Team

With those definitions in mind, we start the process by taking one of the high-level deliverables and decomposing it. Decomposition is the process of breaking a deliverable into its component parts. As an example, if we were decomposing a deliverable we talked about earlier, “employees can retrieve items from the supply inventory in less than 180 seconds 90% of the time.” we might talk with the team about how we go about achieving and identify these supporting deliverables;

  • install new supply room map that lets 90% of the people locate the shelf with their item in less than 60 seconds
  • reorganize shelves so people can find their specific item in less than 45 seconds
  • automate the supply signed out process so people can record the item(s) they took in less than one minute 15 seconds.

There might be many ways to go about achieving the high-level deliverable of reducing the time to retrieve supplies. During the conversation with your team, you would allow people to suggest different ways of achieving that end result. It is good practice to achieve consensus on the approach to each of the deliverables.

Another way to develop the work breakdown structure besides brainstorming with the team is to use work breakdown structures from previous projects.  You may not be able to use the entire work breakdown structure. However very often you can find a section of the WBS that is close enough to what you’re doing in the present project that you can simply copy the deliverables. On larger projects that are more complex you may bring in experts on certain kinds of deliverables like computer programs, remodeling of workspace and so on. You would use their expertise to develop the deliverables for your project.

Predecessors that control the sequence of the tasks will link them. Then we assign resources to each task in the WBS. The resources could be people, materials, or contractors. Then, the project manager calculates the duration of every task in the WBS and that completes our project schedule. When the project sponsor approves the schedule, the project manager saves that approved version of the schedule as the baseline. When work begins, the project manager keeps track of the progress the team makes on each task. That is the basis for status reporting.

Create WBS: The Decomposed Project Scope

We always develop the work breakdown structure by working top-down from the scope, not by assembling a list of the things people want in the project. That to do list approach to developing the work breakdown structure yields projects that cost much more and take much longer than they should. When we work top-down, we start with the scope of the project as defined by the project sponsor and we decompose it or break it into 4 to 7 high-level deliverables, each of which is a metric. Then we continue working top-down and we take each of those major deliverables and break it into its components, the elements that are required to produce that deliverable. On a very large project, we may work down another level or even two, subdividing large deliverables into smaller deliverables until we get down to the level of individual assignments. That’s developing the work breakdown structure top-down.

Create WBS: Best Practices

As you can see, the WBS is very central to the entire process of planning, scheduling and tracking a project. The best practices for developing a WBS involve these steps:

  1. After the sponsor of the project defines the scope or overall objective, the project manager begins the creation of the WBS by decomposing the scope into 4 to 7 major deliverables.
  2. We define each of the major deliverables by what the team will produce at the end. As an example, “Clean up the file room” is not a clear deliverable because we can’t measure the end result. On the other hand, a deliverable like, “98% of the books on the shelf in alphabetical order,” does define the end result in measured terms.
  3. To complete the WBS, the project manager takes each of the major deliverables and further decomposes them into smaller deliverables until they reach the right size task for an individual project team member.