The Work Breakdown Structure (WBS)
Once you have defined the scope of the project, you can start looking at the individual tasks that must be accomplished in order to complete the project. The Work Breakdown Structure (WBS) is a diagrammatic approach to defining the work to be undertaken by breaking the project down into a number of tasks and sub-tasks in a hierarchical fashion. The resulting tree structure can be used as a framework for estimating costs and developing a work schedule. The work is decomposed into successively smaller logical units, until it becomes impractical to break the work down any further. Each "work package" produced as a result of this process will be accompanied by a description of the activity to be undertaken and the specific deliverable to be produced as a result of that activity. The work package should provide the basis for a realistic estimation of the time and cost involved in carrying out the work, and should result in a specific and measurable deliverable. An example WBS diagram is shown below.
A typical Work Breakdown Structure diagram
The WBS should include 100% of the work required to achieve the projects agreed objectives - no more, and no less. It follows that, for each high-level component in the diagram, the sum of the work embodied in each of the element's sub-tasks (or children) should represent exactly 100% of the work required to complete the high-level component. At each level within the hierarchy, component tasks are numbered, usually from left to right on the diagram (e.g. 1, 2, 3 . . . etc.). Child elements are also numbered in a manner that identifies their relationship to a particular parent element (e.g. 1.1, 1.2, 1.3 . . . and so on). If a particular life cycle model has been used for the project, the high-level tasks identified by the WBS often reflect the phases of the life cycle (e.g. analysis, design, implementation etc.). It is important to decompose the work to an appropriate level of detail. Too little detail and there is a possibility that some important aspects will be missed. Too much detail and the result could be the micro-management of activities that serves only to hamper the work.
The work breakdown structure can be seen as a checklist of the activities that must be undertaken in order to achieve the objectives defined in the scope document. The WBS will in turn form the basis for the detailed project plan. The work packages defined by the WBS provide a basis for assigning tasks to workgroups or individuals, allocating resources, and monitoring project activity. High-level tasks tend to be allocated to workgroups, whereas the work packages that comprise the high-level tasks are often assigned to an individual project team member, since they are generally far narrower in scope and can be carried out within a relatively short timescale. Not that while the WBS groups activities that are closely related to each other, it does not attempt to impose a timeline on those activities or specify the duration of each task. Nor does it attempt to identify any task dependencies that might exist between the tasks. These details will be determined by the project schedulers, and will eventually form part of the project plan. The real purpose of the WBS is to identify a complete range of measurable deliverables for the project, rather than to try and impose a sequence of events.
In some industries, a minor variation on the WBS, called a Product Breakdown Structure (PBS), is used to decompose a complex product in terms of the systems, subsystems and components that together make up the product (for example, the engine management system or braking system of a motor vehicle). Just as the WBS decomposes a project into a number of discrete low-level activities (work packages), the PBS is a hierarchical structure that decomposes a complex product such as an aircraft or an item of heavy machinery into its constituent assemblies, sub-assemblies and components. As with the WBS, the lowest level of the PBS should consist of components that cannot realistically be decomposed any further, and should follow the same 100% rule whereby every single component required to build the top-level product under consideration is included.