“Work Breakdown Structure”

Work Break Down Structure

The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. In a project or contract, the WBS is developed by starting with the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages) which include all steps necessary to achieve the objective.
The Work Breakdown Structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established.
A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc. For each element of the work breakdown structure, a description of the task to be performed is generated. This technique (sometimes called a System Breakdown Structure) is used to define and organize the total scope of a project.

The WBS is organized around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the WBS also helps map requirements from one level of system specification to another, for example a requirements cross reference matrix mapping functional requirements to high level or low level design documents.


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 PM's 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.