WBS Examples

WBS Examples (#7 in the series How to Plan and Organize a Project)
By Michael D. Taylor

Graphical WBS Method

Figure 1: WBS Diagram

The above WBS diagram which depicts the Graphical WBS Method also illustrates the 100% Rule. These percentages are usually based on the estimated costs, or estimated effort (direct labor hours). At the beginning of the decomposition process, the project manager assigns 100% to the total scope of this project. At WBS Level 2, the 100% is subdivided into five elements at Level-2. The number of points allocated to each is an estimate based on the relative effort involved. Level 2 elements are further subdivided to Level 3, and so forth.

Indented Outline Method

Another technique for decomposing a project is the indented outline method. In this case the WBS levels are identified by their indenting as shown in the following list. Some project managers prefer this method because it is typically the left portion of the Gantt Chart.

1267 PROJECT
	1267.1 Systems Integration
		1267.1.1 Requirements Definition
		1267.1.2 Regulations
		1267.1.3 Scheduling
		1267.1.4 Monitoring & Control
		1267.1.5 Procurement Management
		1267.1.6 Closeout
	1267.2 Design
		1267.2.1 Conceptual Design
		1267.2.2 Preliminary Design
		1267.2.3 Final Design
	1267.3 Engineering
		1267.3.1 Civil Engineering
		1267.3.2 Mechanical Engineering
		1267.3.3 Electrical Engineering
		1267.3.4 Systems Engineering
		1267.3.5 Construction
		1267.3.6 Safety
	1267.4 Construction
		1267.4.1 Foundation
		1267.4.2 Structures
		1267.4.3 Roads
		1267.4.4 Landscape
	1267.5 Safety
		1267.5.1 Safety Planning
		1267.5.2 Safety Documents
		1267.5.3 Inspections

Figure 2: Indented Outline Method

It is recommended that WBS design be initiated with interactive software (e.g. a spreadsheet) that allows automatic rolling up of point values. Another recommended practice is to discuss the point estimations with project team members. This collaborative technique builds greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity required to manage the project.

A WBS is not a project plan or a project schedule and it is not a chronological listing. It is considered poor practice to construct a project schedule (e.g. using project management software) before designing a proper WBS. This would be similar to scheduling the activities of home construction before completing the house design. Without concentrating on planned outcomes, it is very difficult to follow the 100% Rule at all levels of the WBS hierarchy. It is not possible to recover from an improperly defined WBS without starting over, so it is worthwhile to finish the WBS design before starting a project plan or project schedule.

A WBS is not an organizational hierarchy. Some practitioners make the mistake of creating a WBS that shadows the organizational chart. While it is common for responsibility to be assigned to organizational elements, a WBS that shadows the organizational structure is not descriptive of the project scope and is not outcome-oriented.
Short-term memory capacity should not dictate the size and span of a WBS tree structure. Some reference material suggests that each WBS level be limited to 5-9 elements because that is a theoretical limit to short-term memory. It is far more important to construct a logical grouping of planned outcomes than to worry about the limits of short-term human memory.

WBS updates, other than progressive elaboration of details, require formal change control. This is another reason why a WBS should be outcome-oriented and not be prescriptive of methods. Methods can and will change frequently, but changes in planned outcomes require a higher degree of formality. If outcomes and actions are blended, change control may be too rigid for actions and too informal for outcomes.

MICHAEL D. TAYLOR, M.S. in systems management, B.S. in electrical engineering, has more than 30 years of project, outsourcing, and engineering experience. He is principal of Systems Management Services, and has conducted project management training at the University of California, Santa Cruz Extension in their PPM Certificate program for over 13 years, and at companies such as Sun Microsystems, GTE, Siemens, TRW, Loral, Santa Clara Valley Water District, and Inprise. He also taught courses in the UCSC Extension Leadership and Management Program (LAMP), and was a guest speaker at the 2001 Santa Cruz Technology Symposium. His website is www.projectmgt.com.