WBS Examples

February 20, 2009 | Author: PM Hut | Filed under: Project Plan Development

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

Graphical WBS Method

WBS Diagram

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.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

Related Articles

3 people have left comments

This site helped me a lot while preparing project plan

uma wrote on October 10, 2010 - 6:00 am | Visit Link

With due respects…
I believe the first element under
1267.1 Systems Integration, should be

CONCEPT DEFINITION.

Without that, it seems that none of the rest follows rationally. The concept definition defines what is reasonable for the REQUIREMENTS DEFINITION.
Concept definition early does not change the placement of the 1267.2 Design 1267.2.1 Conceptual Design element, it just establishes clarity at the onset.

I would follow the rest of the chart given with that one alteration. More than the requirement, the concept definition is seminal to all else that follows. Being the first issue, we ensure that all are singing from the same sheet of music from the outset.
Peace, bob

Bob Sommer wrote on May 17, 2011 - 2:07 pm | Visit Link

Thank you very much for your help Mr. Taylor, i think it is a very interesting place. Id like to ask you if you have an wbs for small plant instalation. it would be very helpful to form a good idea about it. I am studying a pmi course and our project is about an industrial laundry plant.
Thank you so much again
Frank

frank wrote on July 25, 2012 - 11:55 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories