Close this Window         

"Work Breakdown Structure" Articles

    1. What is a WBS?   ·   2. How to Build a WBS  ·  3. Avoid WBS Pitfalls   


What is a Work Breakdown Structure (WBS)?

The eCorporation Push
Company owners and project managers use the Work Breakdown Structure (WBS) to make a complex project more manageable. The WBS is designed to help separate a project into manageable chunks that can be more effectively estimated and supervised.

Some reasons for taking the time to create a WBS include:
  •  Assists with accurate project organization
  •  Helps with assigning responsibilities
  •  Shows the control points and project milestones
  •  Allows for more accurate estimation of cost, risk and time
  •  Helps explain the project scope to stakeholders

Constructing a Work Breakdown Structure
To start out, the project manager and subject matter experts determine the main deliverables for the project. With these in place, they start decomposing these main deliverables, breaking them down to successively smaller chunks of work.

You may ask, "How small is small enough?" That varies with project type and management style, but some sort of "rule" should govern the size and scope of the smaller chunks of work. You could use a two weeks rule, where nothing is broken down any smaller than it would take two weeks to complete. You could use the 8/80 rule, where no chunk would take less than 8 hours or no longer than 80 hours to complete. Determining the chunk size "rules" can take a little practice, but in the end these rules make the WBS easier to use.

Regarding the format for WBS design, some people create tabulated tables or lists for their work breakdown structures, but most people use graphics to display the project components as a hierarchical tree structure or diagram.

What is a Work Breakdown Structure Diagram?
A WBS diagram expresses the project scope in simple graphic terms. The diagram starts with a single box or other graphic at the top to represent the entire project. The project is then divided into main, or disparate, components, with related activities (or elements) listed under them. Generally, the upper components are the deliverables and the lower level elements are the activities that create the deliverables.

Information technology projects translate well into WBS diagrams, whether the project is hardware or software based. That is, the project could involve designing and building desktop computers or creating an animated computer game. Both of these examples have tasks that can be completed independently of other project tasks. When tasks in a project don't need to be completed in a linear fashion, separating the project into individual hierarchical components that can be allotted to different people usually gets the job done quicker.

Building a Desktop Computer WBS – Say your company plans to start building desktop computers. To make the work go faster, you could assign teams to the different aspects of computer building, as shown in the hierarchical diagram below. This way, one team could work on the chassis configuration while another team secured the components.

WBS 1

Creating an Animated Computer Game – If you are more attracted to the software side of IT, you could start a computer animation company. To assure that you get your product out the door before the competition, you could assign teams to the different aspects of writing, drawing and building animated computer games, as shown in the hierarchical diagram below. Perhaps your key programmer is also a fair artist. Rather than have him divide his time and energy by trying to do both tasks, you will realize faster results if the programmer concentrates on programming while his cousin Jenny draws the scenery.

WBS 2

Conclusion
At the risk of sounding melodramatic, the efficacy of a project's Work Breakdown Structure can determine the project's success. The WBS provides the foundation for project planning, cost estimation, scheduling and resource allocation, not to mention risk analysis.

This subject continues in the next two articles:
• How to Build a Work Breakdown Structure, part 2
• Avoiding Common Work Breakdown Structure Pitfalls, part 3

by Ann Gordon
(published by Bright Hub, 2008)

- Return to TOP -

    1. What is a WBS?   ·   2. How to Build a WBS  ·  3. Avoid WBS Pitfalls   


How to Build a Work Breakdown Structure(part 2)

WBS Basics
The Work Breakdown Structure is a project management tool designed to capture project tasks in a visual, organized manner. Work Breakdown Structures (WBS) were originally developed by the US Department of Defense, which mandated their use across the DoD. Today work breakdown structures are widely used for projects of all types, both business and personal.

On the most basic level, you decompose the project scope in order to create the work breakdown structure. This takes time in beginning, but it will save time during the life of the project and will ultimately afford the managers better control of costs and deadlines. When you use the decomposition process to create your WBS, you run less risk of adding items that are outside the project scope.

A WBS is More Than a To-Do List
The example below is a simple task-oriented WBS that resembles a graphical task list.

A To-Do list like the one above may work for a wedding party, but in the corporate world there is much more to developing and using a WBS than simply creating an expanded list of tasks.

At the beginning of a project, the WBS can serve as a coordinating medium to secure buy-in from stakeholders, supervisors and team members. As the project progresses, the WBS can give visibility to important efforts and foster clear ownership by managers and supervisors. At project completion, the WBS can provide data for performance measurement. This is much more than a To-Do list can do.

Considerations When Building a Work Breakdown Structure
Following are some aspects to consider as you start the WBS development process:

  • As you set up your project WBS, consider how you plan to use it later in the project. For instance, pay close attention to the indents in your WBS because these eventually end up being the indent structure in your Gantt schedule.

  • Intuitively we gravitate toward developing task-oriented work breakdown structures because they are easy to understand and because we tend to think of a project as a collection of tasks. It usually takes more effort to develop a deliverable-oriented WBS because these include multiple levels of detail. Taking the time to develop a deliverable-oriented WBS may better serve the project, especially if extensive project management controls are used.

  • Determine whether you want to build a WBS that is process oriented or product oriented. What’s the difference? If the results you want from your project can be defined in verbs, then you want a WBS that is process oriented. If you want a WBS that is built on nouns, then it will be product oriented.

  • Remember that our brains can simultaneously comprehend only 7 to 9 items at a time. When a project involves hundreds of tasks, they need to be broken into chunks that we can readily understand and use. The process of creating a WBS helps chunk down the project, which makes it easier to manage – and master.

  • Be sure there is no overlap in scope definition between two elements of your WBS. Not only would this result in duplication of effort, but would likely cause confusion regarding responsibility, authority and cost accounting. To help alleviate this problem, create a WBS dictionary to describe each component in detail.

The Building Process
Not only do you need the project scope to create your WBS, you need the input from all project managers and team leaders. Generally the WBS-building process finds all these people in a room with plenty of white boards and markers, or pads of paper and sticky notes. These brainstorm sessions should result in a first draft of the project WBS, one that will foster "buy in" because everyone participated in its development.

Creating a quality WBS can take a substantial amount of time, but is usually worth the effort because of the additional clarity it provides for project management.

Some WBS Resources
Generating a WBS from Microsoft Project – If your project has already been entered in MS Project, you can consider a third-party add-on for MS Project from Critical Tools (http://www.criticaltools.com). Their WBS Chart Pro add-on converts a Gantt chart task list with indents into a standard WBS graphic.

Military Standard for WBS - For a comprehensive examination of work breakdown structures, check out the complete military standard for work breakdown structures on the EverySpec website (http://www.everyspec.com). When you get to the site, just search for Work Breakdown Structures.

This subject continues in the next article:
• Avoiding Common Work Breakdown Structure Pitfalls, part 3

by Ann Gordon
(published by Bright Hub, 2008)

- Return to TOP -

    1. What is a WBS?   ·   2. How to Build a WBS  ·  3. Avoid WBS Pitfalls


Avoiding Work Breakdown Structure Pitfalls  (part 3)

Introduction
A work breakdown structure (WBS) is a project management tool designed to capture project tasks in an organized way. Although the WBS is meant to be a useful tool for managers as well as employees, it can also be ill-designed or misused.

As you build your WBS, pay attention to details and logic and try to avoide these pitfalls, which are not listed in order of importance.

1.   Not creating a WBS dictionary
Creating a WBS dictionary is not always necessary, especially if the acronyms and category content in the WBS are obvious. A WBS dictionary helps keep track of all of the summary and detailed activities, including a short description of what is – and what is not – included in a WBS element. Neglecting to create a WBS dictionary can cause "ownership" dilemmas that can ultimately threaten project success.

2.  Expecting 110%
An important WBS design principle is the 100% rule, which states that the WBS includes 100% (or everything) of what is in the project scope. However we often hear people say that they have given a project or a task 110%.  In reality, a project is doomed to failure if the WBS includes more than 100% of what is in the project scope. A quality 100% WBS is a good measure against “scope creep.”

3.  Why bother with Formal Change Control?
Any update to a WBS, other than an elaboration of details that already exist, should require formal change control. To ignore this step invites changes in scope that can spell doom for the project.

4.  Method Orientation
The WBS should be outcome oriented and not prescriptive of methods. Methodology can change without any change to the planned outcomes. Planned outcomes or deliverables (which should be fairly rigid) should not be closely blended with actions and methods (which can be flexible).

5.  To-Do List Mentality
The To-Do list approach to WBS construction stems from a manager’s belief that the WBS is actually a step-by-step procedure for doing everything. This approach can lead to the concept that managers walk around with a detailed checklist they use to check off each item as it is completed. Ultimately this leads to micro-management, which is not generally attractive to team members.

6.  Adding Requirements
When you place a deliverable on your WBS, you can break down the deliverable into the activities required to create it. What doesn't work is breaking down the deliverable into the requirements that describe it. Deliverables and tasks do belong in the WBS, but requirements do not.

7.  Skipping the Buy-In Process
The WBS should be drafted with input from all project and team leaders. If the project manager creates the WBS with limited input from other project and team leaders, these people may in turn offer limited support for the WBS. It may be time-consuming, but in the long run it pays to engage all of the core project leaders in WBS development.

8.  Too Many Tasks
Team members are generally more productive if they are held accountable for reaching measurable achievements rather than completing a laundry list of tasks. When the WBS is broken down to tasks that take just a couple of hours to complete, workers spend so much time reporting on these small tasks, and managers spend so much time keeping track of them, everyone may lose sight of the desired end result. As a general rule, WBS tasks should have durations between 1 week and 8 weeks long.

This concludes my three articles about WBS. I hope they helped you understand the process.
Best of luck with your project.

by Ann Gordon
(published by Bright Hub, 2008)

- Return to TOP -

    1. What is a WBS?   ·   2. How to Build a WBS  ·  3. Avoid WBS Pitfalls