4PM Home Page

Project Management
Certification & Training

Project "Best Practices" Articles & Videos
Add to Outlook On Google Start Page Get email notice of articles

WBS Templates for Projects?

By Dick Billows, PMP, GCA

Summary: In our 5-step project methodology, a good WBS is "deliverables-oriented" not "activity-oriented." In other words we do not try and list all the"to dos." Instead, we decompose high level deliverables into a WBS with the "right-size" assignment for each team member. A small work breakdown structure with well-defined assignments is the key to success.

Work Breakdown Structure (WBS) Templates Based on Project Size

The work breakdown structure is not a "to do" list.  Rather, it is a hierarchy of deliverables with major deliverables developed during a scope definition process which we then decompose into smaller and smaller deliverables. We stop when we reach the level of a deliverable that an individual will be accountable for achieving.  At this lowest level in the work breakdown structure, we will do our estimating of work, duration and cost.
Get s Summary of New Articles Each Week

WBS Work Packages

Manage what counts

WBS Activities

Fast Food Project Planning

WBS Design

Work Breakdown Structure Steps

Tier 1: Small Project WBS
Done within an organizational unit with your manager or your boss as the sponsor

Tier 2: Medium Project WBS
Cross-functional effort affects multiple departments or is done for your customers/clients

Tier 3: Strategic Project WBS
Organization-wide projects with long term effects
Text book
Course

Participation in Creating the WBS

There is great advantage in terms of project commitment when the team members participate in the development of the WBS.  The lowest level in the WBS will be their individual assignments.  So it helps build commitment if they are involved in setting the acceptance criteria that will be their performance expectation.  Even in a small project our WBS is deliverables-based with quantified measures that define success.

As project size increases, the process of decomposing higher level achievements expands.  Generally we would form separate work teams for each major deliverable and have each team decompose that achievement down to the level of individual assignments. This process not only improves the clarity of assignments but allows for an early consideration of alternatives on each assignment in the WBS.

 On organization-wide projects, it is difficult or impossible to assemble all members of the project team to participate in the WBS creation process so we increasing rely on templates and the work of the project manager.

Work Breakdown Structure Templates

Sections of work breakdown structures from previous projects are always a useful time saver in the development of the work breakdown structure.  These WBS templates are even more valuable when they are accompanied by information about the actual performance on the tasks and the hours of work that the achievement required on a previous project.  There is still great value in having the people who will be doing the work participate in this process rather than simply using the template with modifications made by the project manager.

As the scale of a project increases to the strategic tier, the identities of the team may not be know. As a result it becomes increasingly difficult to involve the project team members in the development of the WBS.  In these situations, templates should be used to as great an extent as possible.

Work Breakdown Dictionary (supporting data on each WBS task)

This is often skipped on small projects because that level of formal documentation is usually not needed.

As the size of the WBS increases, the additional documentation that comes in the work breakdown dictionary is useful.  In it we keep track of all the predecessor, estimating and change control information about the tasks in our work breakdown structure.

The WBS dictionary should be created and continually updated as changes take place. Whenever the WBS or the other information such as duration, resources assigned, cost estimates and precedence relationships we update the WBS dictionary.

Work Breakdown Structure in Theory
Unfortunately, too many academics and academic textbooks teach the work breakdown structure as a big "to do" list. They ignore the impact on the PMs ability to track progress and make good assignments. Many people who have taken these project management classes spend very little time learning the work breakdown structure and, as a result, think it is just a list with "to dos" for every team member. The results are disastrous as we will discuss below.
Work Breakdown Structure in Practice
In practice, many project managers follow a "to do" list approach as discussed above. The result is that their assignments for the team members are vague and the performance expectations are unclear.  On those project teams the estimates are always inaccurate because it is very hard to estimate the work or duration of a "to do" list item when the deliverable is too general.  As a consequence, the team members are guessing about what is expected and routinely have to redo assignments when their guess doesn't meet the current performance expectation of the project manager.  It is this "to do" list approach to the work breakdown structure that is one of the major causes of the overall 70% project failure rate.
WBS "Best Practices"In the Real World
In the typical situation project managers face in the real world, we have no formal authority over the team. But one thing we can do is decompose the work breakdown structure into a measured definition of success on each deliverable.  No matter how limited our authority over the team, we can still follow best practices on the WBS.  We start from the overall project acceptance criteria which is a measurable definition of success.  Then we continue the decomposition,  identifying the major deliverables and defining success on each one in quantified terms.  We don't want to have to guess about whether we produced the right deliverable, we want to be able to measure it at the end of the work.  As an example, a task such as, "improve service on customer phone calls," is a typical "to do" list item that might be included in a work breakdown structure. It makes a terrible assignment and invites scope creep. On the other hand, if we decompose our deliverables properly, that work would have a metric defining success such as: "95% of the customers experience hold time of less than 15 seconds."  It is difficult to come up with these measured outcomes primarily because we have to decide exactly what we want.  However, the benefits are enormous in terms of more accurate estimating, more confident team members who know what success is before they start work and tighter control of the scope because the precision of these definitions helps us keep out unnecessary work.

 

How many Tasks Should I have in the WBS

It's amazing how often people ask, "How many tasks should this project have?" or, "How much detail should I have in the project schedule?"

There is no magic number but the usual mistake project managers make is to lay out too many tasks. Their work breakdown structure (WBS) is a "to do" list of one-hour chores. It's easy to get caught up in the idea that a project plan should detail everything everybody is going to do on the project. This springs from the screwy logic that a project manager's job is to walk around with a checklist of 17,432 items and tick each item off as people complete them.

Not a "To Do" List

This "to do" list approach is usually linked with another fallacy. Namely, that the project plan should be a step-by-step procedure for doing everything in the project in case we have to do it again. If the PM is managing the wrong things, this may be handy because we increase the odds of having to do this project again. Sponsors encourage these fallacies by marveling at monstrous project plans because that makes it seem like the PM has "thought of everything."
 

Unfortunately, on significant cross-functional projects, there is absolutely no chance that the project manager will think of everything. The subject matter experts and specialists are the ones we must hold accountable for that. The result of these fallacies is that PMs produce project plans with hundreds or even thousands of tasks. Many of them have durations of a few hours or a few days. Does this level of detail give us better control and lead to successful projects? In our view, a "to do" list approach does not give effective control, and it interferes with the achievement of a successful end result.

The Laundry List Approach

First, the laundry list approach leads to, and even encourages, micro-management of the people working on the project. Micro-management is appropriate when you have slackers and nincompoops working for you, but few project teams are composed entirely of these losers. The majority of your project team members will not thrive under micro-management. This style tends to encourage dependency on the project manager rather than independence where people are held responsible for their results.

Second, PMs are consistently more effective when they hold people accountable for reaching measured achievements rather than completing a list of tasks. How often does it happen that people complete a list of tasks and achieve nothing? When we base our assignments and monitoring on well conceived and measurable achievements, no one loses sight of the desired end result.

Third, the laundry list approach is hard to maintain. People have to report on many tasks which decreases the odds of receiving accurate and timely status reports. The PM, with or without clerical support, has a great deal of data entry to do to input all this status data. Amid the pressure of on-going multiple projects, tracking can fall behind and may even be dropped because the amount of effort is too large. This may sound like a stupid and improbable solution, but it happens with alarming frequency even on large and important projects. The logic is, "No one is looking at all that detail anyway, so why spend all that time to catch up?"

As a general rule, we like to see the majority of assignments in a project plan have durations that are between 1 week and 8 weeks long. Coupled with this, we advocate weekly status reporting of hours worked, percentage complete and an estimate of the hours of work remaining to complete the assignment. This combination allows the project manager to maintain good control while placing the responsibility for achievements on the team members.

Using the work breakdown structure (WBS) for cross-functional corporate projects, you have the opportunity to design an assignment and monitoring process. As part of our achievement-driven approach, we recommend breaking work down into "packets" of achievement for which you will hold people and teams accountable.

Learn how to craft a WBS that makes your projects more successful by working with a PM mentor in our on-line courses

The Hampton Group, Inc. 3547 South Ivanhoe St. Denver, CO 80237-4320 USA
© 2004 The Hampton Group, Inc. All Rights Reserved. May not be reproduced without written permission . The Microsoft Corporation owns the registered trademark Microsoft Project®. The Project Management Institute, Inc. owns the following registered trade and certification marks: PMI® PMBOK® PMP® and CAPM®. The CompTIA IT Project + certified professional logo is a registered trademark of CompTIA (the Computing Technology Industry Association). All rights reserved.2003