Project Management

Discussion: Is a Work Breakdown Structure worth your time?

A Work Breakdown Structure (WBS) provides a hierarchical listing of project tasks and subtasks. Can a WBS keep crucial details from slipping through the cracks, or is it just one more project management tool to deal with? Read on and give us your opinion.


If you’re struggling to keep track of the details of a fast-paced project, is it worth your time to sit down early in the project lifecycle and create a Work Breakdown Structure (WBS)? The WBS (which you can create using Microsoft Project or other project management software) is simply a hierarchical listing of the tasks and their dependent tasks involved in pursuing a project. By breaking tasks down to their granular level, you can see exactly what work is necessary to hit project milestones.

Not a project plan or functional specification
In a normal workflow, the WBS lies between the functional specification and the project plan. A functional specification includes a detailed definition of each task, including the design and development criteria. Functional specifications are completed during the scoping phase of the project and are based on the business and IT requirements for the project. While a functional specification details application behaviors, a WBS provides an overall understanding of the goals and objectives. In doing so, the WBS lists only the names of the tasks/subtasks and their relationships to other tasks/subtasks.

Likewise, the WBS is not a work schedule; it doesn’t contain any information as to when or in what order or precedence tasks will be accomplished. However, a WBS is often the source for project Gantt charts, which are used to establish a work schedule.

The four steps to create a WBS
Successful WBSs are built as an iterative process by examining a project’s goals, deliverables, constraints, and technical attributes. The creation of a WBS usually follows four steps:
  1. Identify the overall goals of the project. Consider each major deliverable or objective as a candidate for a leg in the WBS hierarchy. These entities will serve as the top-level elements in the WBS.
  2. Identify each project phase necessary to deliver the elements identified in step one. These phases will comprise the second-level elements in the WBS.
  3. Break down the phases identified in step two to their component activities necessary to deliver the phase. These activities become the level-three WBS elements.
  4. Continue to break down the activities in step three to their component tasks. These tasks may in fact require further decomposition to get to root elements. These tasks will then be described as level four through n of the WBS.

How much detail?
In addition to identifying all project deliverables, the WBS should also identify activities related to the management of the project. These include tasks related to project startup, management, and closeout. For example, the WBS should include milestone meetings, product documentation, testing, and quality assurance activities. The WBS should also include items necessary for the successful pursuit of project tasks. For example, you may need to obtain legal permits or insurance prior to embarking on a development task.

Project resources, such as required team members, data, and product support services, are assigned to elements at the lowest level. Tasks can be assigned to individuals or to larger entities such as departments, teams, or contracting entities. Costs to complete each component task are identified at this level as well.

Toss in your two cents
While the WBS may complement traditional project plans, is it “just another piece of documentation” or an effective tool to outline project tasks and subtasks? Have you used a WBS? Drop us an e-mail or post a comment below.

 

Editor's Picks