A project is made more manageable by breaking it down into components. In that spirit, the PMBOK requires the decomposition of the project into phases and tasks (also called activities). This task listing is called a Work Breakdown Structure, or WBS.
There are various acceptable formats. Here is a graphical style format:
And here is an example of a spreadsheet style format:
The WBS is structured around deliverables. When there are intermediate or internal deliverables, these make great WBS items. There does not need to be a deliverable associated with every WBS item, but there should be not more than one per task.
Importance of the WBS
The WBS is the foundation of project management and almost everything the project manager does depends on it. During project planning, the cost estimating, schedule development, human resource planning, risk identification and procurement requirements depend on it. During project execution, the day to day scope, schedule and budget control depend on the accurate representation of the project into individual phases and tasks. If the tasks are not representative, the project cannot be well controlled.
Because of this, many project issues can be traced back to poor work breakdown structures. To reduce risk of project problems, a good work breakdown structure is essential.
How to Develop a WBS
The following four techniques are invaluable in developing a WBS for your project:
- WBS Templates
If possible, start with a template that is specific to the industry or product. For example, if the project is for the paving of a highway, and the organization has paved a highway before, the previous WBS is obviously going to be quite similar and should serve as a starting point. Secondly, look for components of work which have been performed before, such as the paving of an intersection or bridge. The existence of WBS templates is the most preferable situation, but it’s the custom tasks where the project manager earns his money. - WBS Standards
These are generic WBS templates for certain types of projects, geographic regions, or corporate deliverables. For example, a generic template for paving projects. Each item in the WBS must be inspected for variations from the predicted standard. - Bottom Up
This is a method by which you determine all of the project’s deliverables, then determine the work packages necessary to produce them and roll it up into the full project. - Top Down
In this method you start with the final product and break it down into its constituent tasks, and progressively decompose the deliverables into a level of detail required for management and control.
The 100% Rule
This rule states that the WBS shall contain 100% of the work required to produce the deliverables. Not more and not less. All child tasks must add up to 100% of their parent tasks.
An underscoped project (WBS is missing items) will result in budget and schedule overruns. An overscoped project (WBS contains unnecessary items) will result in questions about funding and project viability once the project starts.
The 8/80 Rule
This rule states that tasks should generally be between 8 and 80 man-hours. This level of effort is generally easy to estimate, control, and manage. On large projects, however, this could result in inefficient micromanagement.
Length and Size
There are no hard and fast rules regarding the number of WBS components and their organization. However, there are some guidelines that should be followed.
- They should be structured around project deliverables.
- There should be maximum one deliverable per task.
- There should be only one responsible party per WBS item.
Additionally, large tasks often lose sight of who is responsible and the assignment of various sub-tasks within the task becomes difficult to keep track of. Thus, a task can be broken down into multiple tasks if it results in better accountability.
Although the project manager is ultimately accountable for all of the tasks within a project, having just one accountable party per WBS item prevents confusion relating to completion of certain project deliverables. For example, if a site design has been subcontracted to an engineering firm, that firm should provide one accountable person and become one single WBS element. If other items are lumped together, creating multiple responsible parties, project control is lost.
WBS Dictionary
The PMBOK specifies a document calles a WBS Dictionary to support the WBS. This document contains alot of secondary information which is difficult to include within the often graphical WBS.
The minimum level of information required for a functional WBS is:
- Identification Number. To identify the task.
- Description. To identify the task. eg. Painting the walls.
- Person Responsible. To ensure that someone has responsibility for the task.
Other possible information, which can be included in a WBS Dictionary, includes:
- Account code
- Responsible Organization and Agreement Numbers
- Required resources
- Schedule milestones
- Cost estimates
- Quality requirements
- Acceptance criteria
- Technical references
Although several of these items (cost, schedule, etc.) are contained within other knowledge areas, including them within a WBS dictionary within the project management plan is intuitive and provides for easy communication to stakeholders.