The Work Breakdown Structure
Projects are organized and understood by breaking them into progressively smaller pieces until they are a collection of tasks or work packages. Clustering project tasks or end-products helps form the overall project work into manageable pieces. The resulting structure should serve as the basis for estimating resource requirements, costs, and schedules.
Some project management environments have definite conventions for grouping items in a WBS. The best method is to have a WBS that works for your particular project environment. The WBS should be designed with consideration for its eventual uses. Your WBS design should try to achieve certain goals:
-
Be compatible with how the work will be done and how costs and schedules will be managed
-
Give visibility to important or risky work efforts
-
Allow mapping of requirements, plans, testing, and deliverables
-
Foster clear ownership by managers and task leaders
-
Provide data for performance measurement and historical databases
-
Make sense to the workers and accountants.
There are usually many ways to design a WBS for a particular project, and there are sometimes as many views as people in the process. Simple practicality usually provides the best approach.
The Work Breakdown Structure History
The WBS was initially developed by the U.S. defense department, and it is described in Military Handbook 881 (MIL-HDBK-881, 2 January 1998) as follows: "A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item. A WBS displays and defines the product, or products, to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product. A WBS can be expressed down to any level of interest. However the top three levels are as far as any program or contract need go unless the items identified are high cost or high risk. Then, and only then, is it important to take the work breakdown structure to a lower level of definition."
It requires some mental discipline to develop a product-oriented or deliverable-oriented grouping of project elements adding up to comprise the entire project scope. Intuitively, we tend to start out with a task-oriented approach. This is OK for very small projects where extensive project management controls will not be used. If your organization will be collecting historical data to form a cost database, you should try to select a standard approach consistent with the organization's long term data collection needs. A WBS for a large project will have multiple levels of detail, and the lowest WBS element will be linked to functional area cost accounts that are made up of individual work packages. Whether you need three levels or seven, work packages should add up through each WBS level to form the project total.
WBS Numbering
WBS elements are usually numbered, and the numbering system may be arranged any way you choose. However, the conventional numbering system is 1.2.3.4, where each digit represents the task subdivision level.
WBS Dictionary
If a WBS is extensive and if the category content is not obvious to the project team members, it may be useful to write a WBS dictionary. The WBS dictionary describes what is in each WBS element, and it may also say what is not in an element, if that is unclear. Here is a sample of a WBS dictionary description:
1.3.5.2. - Systems Integration Test Equipment Planning - This element includes the effort to identify requirements and specify types and quantities of test equipment needed to support the System Integration and Test process. It does not include the design or procurement of such equipment, which is covered in Element 1.5.4.6.
WBS Mapping for Cost Management
In a product-oriented WBS, functional categories of work may form "cost accounts" within a WBS element. Cost account managers are responsible for a functional area's contribution to a WBS element. Cost accounts from several departments or functions may combine into one WBS element.
Internal department planning for a cost account will be made up of individual work packages. A work package will typically have its own budget and schedule. Work packages should be small enough to be executed by individuals or small groups in a single department, and they should be of relatively short schedule duration. A small project might define a maximum work package size as two weeks of effort. Larger projects will assemble larger work packages that can be appropriately managed and controlled.
The project manager will have to decide to what degree employment of various details of WBS implementation will benefit the efficient management of the project. On a very small project, a formal WBS may serve no useful purpose, but it can become valuable if project size or complexity start to increase.
As an organization's project management environment matures, or as larger size and complexity are encountered, application of the WBS concept can evolve from an ad hoc list of tasks, to time-phased activity lists, task lists clustered by project deliverables and services, or an end-product focused WBS fed by cost accounts and work packages.
If you are using MS-Project or a similar project management software application, you may encounter the WBS as a vertical list with indents to show structure. This will be compatible with the Gantt View data entry screens. While some software packages provide a separate WBS view, you could prepare your WBS in the vertical format using a word processor, and then cut and paste your WBS into your project management software package.
Program and Contract WBS Structure
A top-level WBS is called a Program WBS (PWBS). If a project involves several organizational participants or contractors, guidance for one contractor can be provided in a Contract WBS (CWBS). The project manager may provide a high-level CWBS for each developer. The developer will fill in the details of lower WBS levels to reflect the work to be accomplished and the data flows in that organization.
Organizational Standards for WBS Structure
Your organization may want to decide on a standard WBS format or group of formats, use these across all projects, and communicate definitions widely so everyone will be speaking the same language. This can save re-learning project lessons and can lay the groundwork for successful data gathering to aid future cost estimates.
WBS Implementation
When you set up a project WBS, think about how you will be using it later in the project. Design the WBS, schedule format, manager assignments, and charge numbers at the same time. The schedule will likely be formatted along the structure of the WBS, so this will be the structure for estimating costs and tracking earned-value performance. It will be helpful if you can map the charge numbers, managers, and task groups to each other. This will help you track costs and progress for each manager. If your project schedule will on MS-Project, you may want to insert "text" columns into your schedule (Gantt View) for project charge numbers and manager names.
If your project charge numbers cannot be linked to groups of tasks assigned to specific managers, you will have no way to provide performance measurement feedback to managers.
