Project Management is like fixing a car – you must break it down into parts. You won’t find the problem if you can’t isolate the defective part, and you can’t fix the problem if the defective part is not separated from the main engine.
A Work Breakdown Structure (WBS) represents this division of a project into constituent tasks. It is a tabular or graphical representation of the tasks that make up the project’s scope. The schedule and budget is then created and tracked by task.
An experienced person in any industry can usually break down a project into its primary tasks within minutes, which illustrates beautifully why project management cannot be completely separated from the technical discipline of the project.
The bible for the creation of a WBS is the Practice Standard for Work Breakdown Structures, published by the Project Management Institute (PMI). There are 9 tricks to creating work breakdown structures that will establish the foundation for a successful project:
- The top layer
- The 100% rule
- No scope overlap
- Number of layers
- Roles and Responsibilities
- Start and finish dates
The PMBOK identifies a process called Decomposition, whereby the project activity list is developed in a top down fashion. Start with the project name or description, for example,
- Build a House
Then decompose it into phases, for example,
Then decompose the phases into individual tasks, for example,
- Mobilize excavator
- Lay out excavation boundaries
- Perform excavation
If those tasks have further sub-tasks, break it down further.
The lowest level of the activity list should contain verbs, such as “Mobilize Excavator” instead of just “Excavator.”
The Top Layer
The top node contains the overall deliverable for the project. It should be approved by all stakeholders, and defined to the appropriate detail. It doesn’t have to be defined to its ultimate level of detail, just to the level that’s appropriate. It’s amazing how easy it is to proceed with planning out work tasks for a report, design, or other deliverable that you haven’t even completely defined.
For example, if your project is to build a house, the top layer of the WBS should be “Build a House.”
This rule states that exactly 100% of the project scope should be included in the work breakdown structure. Not more and not less. If you’re missing a work item in the WBS, you will underestimate the scope and end up over budget or behind schedule. Similarly, if you overestimate the work in the WBS, you will end up with the dreaded “scope creep,” whereby well meaning people insert tasks into the project scope just because it’s easy and nobody stops them. Scope creep can eat projects alive.
All of the deliverables, whether internal, external, or interim, must be included. Deliverables actually make great WBS elements.
The 100% rule also applies at all levels within the hierarchy. The sum of all of the work in “child” elements must equal 100% of the work in their respective “parent” element.
No Scope Overlap
The WBS should not contain items that duplicate the scope of other items. This may seem obvious, but you’d be surprised how easy it is sometimes. In our house-building example, let’s say the excavation contractor and the foundation (concrete) contractor both want to bring earthmoving equipment to the site. In the WBS, it is clear that you need to establish where each task ends and the next one begins.
Number of Layers
The best way to know if you’ve gone to the right amount of detail is to ask yourself if the element can be reliably estimated. At that point, elaborating further simply creates difficulty in tracking and managing small work items.
In general, I would suggest the lowest level of a WBS be no smaller than about 40 man-hours. Any less, and you’re micromanaging and introducing inefficiencies. On the high end, the limit would be when you can no longer track and control the project effectively, which is is probably in the range of 100 hours.
According to the PMI, the minimum amount of information present in a work breakdown structure is:
- Identification: Preferably an identification number, for reference.
- Description: The name and/or a brief overview of the element.
- Person responsible: Someone on whom final responsibility for the work rests.
A project manager is certainly free to include other information, such as schedule and budget. Since the WBS is primarily a graphical tool, these three items, and any other information for each task, are included in a supporting document called the WBS dictionary.
Roles and Responsibilities
As described above, it is a minimum requirement for the WBS to identify responsible people for each WBS element. Every part of a project must have someone responsible for it. In the absence of a specific contact persion this responsibility falls to the project manager.
Start and Finish Dates
An optional, but frequently used, piece of information that can be added to the WBS is the schedule start and finish dates for each item. Although the WBS should not be used as a schedule planning tool, start and finish dates can be added after the schedule planning and used for tracking. So long as the project manager realizes the the creation of the WBS is focused on proper sub-division of the work, not time and schedule planning, this can be a useful piece of information in the WBS.
Similar to the start and finish dates, the budget for the work item can be included in the WBS. It is optional, but frequently used. The project manager should realize that the WBS is not a costing or estimating tool, but once the estimating has been done the budget can be placed in the work breakdown structure for easy reference.
For small projects, a WBS can be as simple as an itemized list of tasks:
|10||Mobilize||Oct. 10||Oct. 11||$250|
|20||Dig Canal||Oct. 11||Oct. 20||$3,000|
|30||Pour Concrete||Oct. 15||Oct. 23||$5,000|
|40||Clean Up||Oct. 23||Oct. 24||$1,750|
Medium and large sized projects can add data fields that are relevant to the project, like man-hours, tools, equipment, rental items, etc.
For presentation, the WBS can be converted into a graphical chart, like this:
Creating work breakdown structures should never become as complex as fixing a car. But with the right level of detail and number of tasks, the complex process of managing and tracking a project is greatly simplified.
WBS Components vs. Tasks
The Project Management Body of Knowledge (PMBOK) contains two separate “processes” related to task lists:
- “Create WBS” under Project Scope Management. The output is the Work Breakdown Structure.
- “Define Activities” under Project Time Management. The output is a task list.
The intention of the PMBOK was that the WBS contain project phases for the purpose of defining the scope, and the activity list defines the project tasks for schedule development and control. However, in practice these are generally one and the same. The terms Work Breakdown Structure and task list are, in my experience, often used interchangeably. I believe there is nothing wrong with this practice, as there only needs to be one official breakdown of the project work. Separating the task list and work breakdown structure can be appropriate for larger projects. Tasks should be grouped into phases regardless of the WBS structure.
Once the work breakdown structure is complete, each task is estimated:
Good luck on your projects! Please leave a note in the comments. I’d love to hear from you.