- Information
- AI Chat
Effective Work Breakdown Structure Handbook
COMPUTER NETWORKS IV (CNW401T)
Tshwane University of Technology
Preview text
P a g e | 3
WORK BREAKDOWN STRUCTURES
<A Work Breakdown Structure is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.= 1
A Work Breakdown Structure (WBS) is a fundamental project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure. The first two levels of the WBS (the root node and Level 2) define a set of planned outcomes that collectively and exclusively represent 100% of the project scope. At each subsequent level, the children of a parent node collectively and exclusively represent 100% of the scope of their parent node.
A well-designed WBS describes planned outcomes instead of planned actions. Outcomes are the desired ends of the project, such as a product, result, or service, and can be predicted accurately. Actions, on the other hand, may be difficult to predict accurately. A well-designed WBS makes it easy to assign any project activity to one and only one terminal element of the WBS.
TYPES OF WORK BREAKDOWN STRUCTURES
Even though the term <Work Breakdown Structure= has been used as a label for all project scope hierarchical diagrams, there are, in practice, many types other than <deliverable= oriented structures.
1 A Guide to the Project Management Body of Knowledge , (Newton Square, PA: Project Management Institute, 2004).
P a g e | 5
The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results.
Planned Outcomes, Not Planned Actions
If the WBS designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to assure an outcome-oriented WBS is to use a product breakdown structure (PBS).
Feature-driven software projects may use a similar technique which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable- oriented WBS. Work breakdown structures that subdivide work by project phases (e. Preliminary Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a deliverable (e. an approved Preliminary Design Review document, or an approved Critical Design Review document).
Level 2 is the Most Important
Of all the levels on a WBS, Level-2 is often the most important because it determines how actual costs and schedule data are grouped for future project cost and schedule estimating. A project manager may find it useful to know how much it took to design (major work element) a product after it had been completed so that the data can be used for future analogous estimating. In other cases, the project manager may want to know how much a major part of the product actually cost after the project was completed. For this a PBS would be used. Level-2 is therefore used to capture <actuals= from a project for future estimating purposes.
The Four Elements in Each WBS Element
Each WBS element, when completed should contain the following four items:
- The scope of work, including any <deliverables.=
- The beginning and end dates for the scope of work.
- The budget for the scope of work.
- The name of the person responsible for the scope of work.
By using a WBS in this manner the project manager can approach a complex project and decompose it into manageable, assignable portions. There is minimal confusion among project members when this technique is used.
P a g e | 6
Mutually-exclusive Elements
In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a WBS. This ambiguity could result in duplicated work or miscommunications about responsibility and authority. Likewise, such overlap is likely to cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements
How Far Down?
The WBS is decomposed down to the work package level. A work package is the lowest level in the WBS, and is the point at which the cost and schedule for the work can be reliably estimated. 2
A question to be answered in the design of any WBS is when to stop dividing work into smaller elements. If a WBS terminal elements are defined too broadly, it may not be possible to track project performance effectively. If a WBS terminal elements are too granular, it may be inefficient to keep track of so many terminal elements, especially if the planned work is in the distant future. A satisfactory tradeoff may be found in the concept of progressive elaboration which allows WBS details to be progressively refined before work begins on an element of work.
One form of progressive elaboration in large projects is called rolling wave planning which establishes a regular time schedule for progressive elaboration. In reality, an effective limit of WBS granularity may be reached when it is no longer possible to define planned outcomes , and the only details remaining are actions. Unless these actions can be defined to adhere to the 100% Rule, the WBS should not be further subdivided.
2 PMBOK
It is important that there is no overlap in scope definition between two elements of a WBS.
An effective limit of WBS granularity may be reached when it is no longer possible to define planned outcomes , and the only details remaining are actions
P a g e | 8
Figure 1 shows a WBS construction technique that demonstrates the 100% Rule quantitatively. At the beginning of the design process, the project manager has assigned 100 points to the total scope of this project, which is designing and building a custom bicycle. At WBS Level 2, the 100 total points are subdivided into seven comprehensive elements. The number of points allocated to each is a judgment based on the relative effort involved; it is NOT an estimate of duration. The three largest elements of WBS Level 2 are further subdivided at Level 3, and so forth. The largest terminal elements at Level 3 represent only 17% of the total scope of work. These larger elements may be further subdivided using the progressive elaboration technique described above.
In this example, the WBS coding scheme includes a trailing "underscore" character ("_") to identify terminal elements. This is a useful coding scheme because planned project schedule activities (e. "Install inner tube and tire") will be assigned to terminal elements instead of parent elements.
It is recommended that WBS design be initiated with interactive software (e. 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.
Another example of a Project WBS using the 100% Method is shown below.
PROJECT 1267 (100%)
Reqt’s Definition1267. (7%)
Regulations1267. (5%)
Scheduling1267. (5%) 1267. Mon & Control(5%)
Conceptual Design1267. (5%)
Preliminary 1267. Design(5%)
1267. Final Design (5%)
1267. Civil Engineering(7%)
Mechanical 1267. Engineering(5%)
1267. EngineeringElectrical (3%) 1267.3 Engineering(5%)
1267. Foundation(7%)
1267. Structures(5%)
1267. Roads(5%)
1267. Landscape(3%)
1267. Safety Planning(4%)
1267. Safety Documents(4%)
Inspections1267. (4%)
1267. Closeout(3%)
Procurement 1267. Management (8%)
1267. Systems Integ. (33%)
1267. Design (15%)
1267. Engineering (20%)
1267. Construction (20%)
1267. Safety (12%)
P a g e | 9
COMMON PITFALLS AND MISCONCEPTIONS
A WBS is not an exhaustive list of work. It is instead a comprehensive classification of project scope.
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. 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- 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 do 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.
WBS Checklist
The top element of the WBS is the overall deliverable of the project, and all stakeholders agree with it.
The first two levels of the WBS (the root node and Level 2) define a set of planned outcomes that collectively and exclusively represent 100% of the project scope.
The WBS elements are defined in terms of outcomes or results. (Outcomes are the desired ends of the project, and can be predicted accurately).
Each WBS element has an identification number assigned which identifies its relative position within the structure.
WBS Handbook
- Page- Work Breakdown Structure Handbook Overview................................................................... TABLE OF CONTENTS
- 1 Purpose
- 1 Definition
- 1 Benefits
- WBS Overview
- 2 Project WBS
- 2 Contract WBS
- 2 Subcontract WBS
- WBS Development and Documentation................................................................................
- 3 Preparing a Project WBS
- 3 Selecting WBS Elements
- 3 Use of Common Elements
- 3 Building Block Approach
- 3 Determining Appropriate WBS Levels
- 3 WBS Dictionary
- 3 Additional Considerations
- 3 Common Mistakes in WBS Development..................................................................
- WBS Evolution
- 4 Project Initiation Phase
- 4 Definition Phase
- 4 Execution Phase
- 4 Closeout Phase
- Considerations for Other Acquisition Activities and Disciplines
- 5 Contracting
- 5 Earned Value Management System
- 5 Cost Estimating...........................................................................................................
- Summary
- References
- Acronym list..................................................................................................................................
- Appendices Overview
- Appendix A: Buildings
- Appendix B: Tanks and Silos
- Appendix C: Tunnels
- Page WBS Handbook
- Appendix D: Wells
- Appendix E: Site Works
- Appendix F: Cap and Liner..........................................................................................................
- Appendix G: Ponds and Basins....................................................................................................
- Appendix H: Process/Scientific/Technical Equipment
- Appendix I: Power Generation
- Appendix J: Power Transmission
- Appendix K: Decommissioning and Decontamination (D&D) Efforts
- Appendix L: Common Elements
Page WBS Handbook
Page 5
1. WORK BREAKDOWN STRUCTURE HANDBOOK OVERVIEW
1 Purpose
DOE Order 413, Program and Project Management for the Acquisition of Capital Assets, dated November 29, 2010, briefly reference the requirement for preparing a WBS in the context of planning and monitoring DOE projects. Furthermore, the Government Accountability Office (GAO) Cost Estimating and Assessment Guide states <Establishing a product-oriented WBS is a best practice because it allows a program to track cost and schedule by defined deliverables, such as a hardware or software component. This allows a program manager to more precisely identify which components are causing cost or schedule overruns and to more effectively mitigate the root cause of the overruns. 1 = This handbook presents suggested guidelines for effectively understanding, preparing, and presenting a product oriented WBS. It provides the consistent framework and guidance for DOE Federal Project Directors (FPD) to define their project WBS (PWBS) and is valuable guidance to DOE contractors in their application and extension of a contract WBS (CWBS) and subcontractor WBS (SWBS). This guidance is appropriate for all types of DOE projects regardless of acquisition phase (e., Initiation, Definition, Execution, and Transition / Closeout).
This handbook applies to all types of projects subject to DOE Order 413. Some examples of project types in this handbook include the construction of buildings, tanks, silos, ponds, power transmission, process, scientific, and technical equipment; as well as the removal of facilities and systems through site remediation and Decontamination and Decommissioning (D&D) efforts. DOE project leadership teams are encouraged to further develop, modify, and expand the WBS constructs for their project type using a similar approach (product-oriented) when possible.
1 Definition
A WBS is a product-oriented hierarchical structure that may be composed of products, material, equipment, engineering, services, data, support facilities, and related tasks that make up a project. It is a product-oriented grouping of project scope elements shown in graphical display to organize and subdivide the total work scope of a project. The WBS defines the product(s) to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the overall project end product. In other words, the WBS is an organized method to breakdown a product into sub- products at lower levels of detail. It provides a consistent and visible framework for items and contracts within a project. This handbook offers uniformity in definition and consistency of approach for assembling a project WBS. The benefit of uniformity in work breakdown structures will be realized through improved communication and informed decision making throughout the acquisition process.
WBS9s are developed at varying levels of detail. Generally, at a minimum, the number of levels employed should be sufficient to identify and measure work progress, assigned responsibility, and enable effective management and reporting to project oversight. The number of levels to which work is decomposed varies depending on the project9s size and complexity, technical maturity, organizational constraints, and management9s assessment of need. It is critical for WBS product elements identified as high-cost, high-risk, and/or high technical interest to be defined at lower levels of detail to provide sufficient visibility and enable effective management. A suitably structured WBS
1 GAO Cost Estimating and Assessment Guide, GAO-09-3SP, March 2009, Chapter 8, page 65.
WBS Handbook
Page 6
will also facilitate accurate and meaningful cost collection that is valuable in predicting performance in similar efforts and allow comparisons between like activities across the complex.
This handbook offers uniformity in definition and consistency of approach for developing all levels of the WBS. Generating and applying uniform structures improves communication between the Government, industry, and other stakeholders during the acquisition process. It also provides guidance to industry in extending the CWBS.
1 Benefits
The WBS serves as a coordinating medium, providing a basis for effective communication throughout the acquisition process. It is a common link, which unifies planning, scheduling, cost estimating, budgeting, contracting, configuration management, and performance reporting disciplines. Performance data (cost, schedule, and technical) are routinely generated for reporting purposes. The WBS is the organizing structure used to summarize data for successive levels of management and provide accurate information on projected, actual, and current status of the individual elements. When appropriately structured and used in conjunction with sound engineering principles, cost estimating, Earned Value Management System (EVMS), integrated scheduling, and risk management, the WBS allows for project status to be continuously visible to identify, coordinate, and implement changes necessary for desired results. The product-oriented WBS assists in several ways during the project phases to include:
Segregates a project into its components, clarifying the relationship among the components, and clarifying the relationship of the tasks to be completed 4 to each other and to the end product. Facilitates effective planning and assignment of management and technical responsibilities. Provides a common basis and framework for the Integrated Master Plan (IMP) and the Integrated Master Schedule (IMS) facilitating consistency in understanding project cost and schedule performance and assigning to the appropriate project phase. Since the link between the requirements, WBS, the statement of work, IMS and the IMP provides insights into the relationship between cost, schedule and performance; all items can be tracked to the same product oriented WBS element. Aids status tracking and alignment of technical efforts, risks, resource allocations, expenditures, and cost/schedule/technical performance. Allows for program status to be continuously visible so that the FPD and contractor can identify, coordinate, and implement changes necessary to achieve desired results. Improves the organization and presentation of contractor Basis of Estimates (BOEs). Provides a common thread for Earned Value (EV) data metrics analysis as part of a contractor EVMS and the Resource Loaded Schedule (RLS), allowing consistency in understanding project cost and schedule performance. Product-oriented WBSs facilitate the use of discrete EV performance measurement techniques, as opposed to Level of Effort (LOE), by aligning tasks directly to delivered products. Allows DOE to capture cost across numerous projects by using a common product-oriented structure that facilitates the development of metrics and benchmarks.
WBS Handbook
Page 8
Figure 2-1. PWBS example involving several projects/systems
The PWBS notionally consists of at least three levels with associated definitions provided via a WBS dictionary (Section 3). The dictionary contains uniform terminology, definitions, and placement in the product-oriented hierarchical structure.
2 Contract WBS
A CWBS is the Government approved structure for the contract scope reporting level and any discretionary extensions to lower levels for reporting or other purposes. It includes all product elements (hardware, software, data, or services) for which the contractor is responsible. The CWBS includes the contractor9s discretionary extension to lower levels, in accordance with Government direction and the Contract SOW. This comprehensive CWBS forms the framework for the development of the contractor9s cost and schedule performance baseline, and the contractor9s management control system. The contractor is responsible for expanding the PWBS to create the CWBS and for developing a CWBS dictionary. CWBS elements provide a structure for planning, budgeting, collecting costs and assessing project performance, thus facilitating compliance with the EVMS requirement as required. See Figure 2-2 for an example of a PWBS with a CWBS beneath one of the project elements (systems). Variations of this simplistic example can be tailored to the different forms of contracting within DOE within any given level of the WBS. For example, DOE may have a general contractor or a Managing and Operating (M&O) contractor at the project level.
Figure 2-2. PWBS and CWBS Relationship
WBS Handbook
Page 9
The CWBS should be aligned to the PWBS. Contracts for specific WBS elements that are in the PWBS will become Level 1 CWBS elements with all applicable Level 2 Common WBS elements included, resulting in the CWBS. The following Figure 2-3 depicts the relationship of the PWBS and CWBS at level 2.
The data from the various project contracts supports the FPD in evaluating contractor performance, preparing budgets, and preparing life-cycle cost estimates for future contracts.
Figure 2-3. PWBS and CWBS Relationship
2 Subcontract WBS
Prime contractors should require significant subcontractors to use a WBS to fulfill contractual EV
reporting requirements (References: DOE O 413, Appendix C, Earned Value Management System; and DOE G 413-10A, Earned Value Management System ). The prime or associate
contractor is responsible for incorporating WBS requirements into its subcontract. Figure 2-4 below
provides an example of a CWBS and its relationship to the Subcontract WBS (SWBS). This
relationship show how the prime contractor may further break down the CWBS to manage
subcontracted work. It is the contractor9s decision to determine how this will be accomplished and
should be documented in the contractor and subcontractor plans. In the figure below, a subcontractor
is awarded a contract by a prime contractor, and the SWBS is an extension of the CWBS maintained
by the prime contractor. Replacing the words <Project= and <Contract= from the Figure 2-3 above with <Contract= and <Subcontractor= respectively, the flow down to the WBS requirement can be
shown in the Figure 2-4 below. In this case the Project WBS could be both the Project and the
Contract WBS.
WBS Handbook
Page 11
3. WBS DEVELOPMENT AND DOCUMENTATION
The WBS may span one or more of the categories, elements, or systems that define the project at the highest level in the WBS. The DOE project management office may define the WBS product- oriented modules and elements that best describe their particular projects based on the appendices found at the back of this handbook. The structure may be extended to lower levels to include subsystems or components to link subsystems or components to the parent system. However, a WBS should not be decomposed to piece parts or attempt to display low level purchased items normally included in a vendor Bill of Material (BOM).
The WBS should accurately and completely represent the system that is being developed and/or procured. The WBS should include only those elements that are part of the logical decomposition of the system. The WBS is intended to structurally illustrate a clear understanding of the technical objectives and the end item(s), end state, or end product(s) of the work to be performed.
The project plan (scope, schedule, and budget) is usually defined in the Project Execution Plan (PEP). The PEP should include guidance on development of a product-oriented WBS. Ultimately, the WBS is approved through the Critical Decision (CD) Process 3 as it evolves. The WBS is integral to cost and schedule reporting required by implementation of a contractor 9 s EVMS 4 , and is an integral tool for uniform data collection, analysis and management.
The primary challenge is to develop a WBS that defines the logical relationship between all project elements without constraining the contractor9s ability to effectively execute the project. A secondary challenge is to balance the project definition aspects of the WBS relative to formal reporting requirements.
3 Preparing a Project WBS
Early in the Definition phase, systems engineering efforts transform the required capability outlined in the Initiation phase to top level alternative product solutions. For example, suppose the capability required is to <safeguard highly enriched uranium (HEU).= The objective is clear and can be met through numerous capabilities. Systems engineers perform tradeoffs, which ultimately define the preliminary system level functions. In this case, the systems that will <safeguard HEU= must have storage capability, address the proper level of physical security, and protect the environment from accidental release. The Project WBS is not formed around these functional requirements, but is developed based on the products which are expected to satisfy these requirements.
3 Selecting WBS Elements
The WBS provides a framework for specifying the technical objectives of the project by defining the project in terms of hierarchically related, product-oriented elements. Each element of the WBS provides logical summary points for assessing technical accomplishments and for measuring cost and schedule performance accomplished in attaining the specified technical objectives. A properly structured WBS will readily allow complete aggregation of cost, schedule, and performance data
3 Appendix A, DOE Order 413 Program and Project Management for the Acquisition of Capital Assets 4 Section 2.f, DOE G 413-10A, Earned Value Management System (EVMS)
WBS Handbook
Page 12
from lower elements up to the project level. Lower level (i., <children=) elements, when aggregated together should represent the higher level (i., <parent=) elements. Users of this handbook should always apply the 100% rule 5 , which states the next level of decomposition of a WBS element (child level) must represent 100% of the work applicable to the next higher level (parent). If an "other" category is utilized to capture several small constituent elements for completeness, every effort should be made to ensure it represents the least effort at that element level and is less than 10% of the total work value (labor and material) for that element level.
DOE Projects can be described using various combinations of WBS modules tailored to their complexity and technologies. The appendices found in this handbook contain standard WBS structures for typical DOE projects and should be used as appropriate.
3 Use of Common Elements
The following are common WBS elements (defined in Appendix L) that can be applied to various types of projects:
Integration, Assembly, Test & Checkout Support Equipment and Facilities System Test and Evaluation Project Administration/Project Management System Design and Engineering Operations and Support
In order to support uniform cost estimating and data comparisons among DOE projects, there is an interest in establishing this set of common elements as a standard or commonly accepted WBS building module similar to the Department of Defense9s MIL-STD-881C 6. Careful consideration should precede any additions to, or alterations of, this list of common elements and the general definition of scope for them (see Appendix L). Managers should be vigilant during execution to ensure that multiple levels of Common Elements do not cause the overall cost of management, or other cross-cutting costs, to increase disproportionately.
3 Building Block Approach
Many projects will use a combination of the structures listed in the appendices of this document (the list is not all inclusive and could be further expanded/modified by the DOE projects). These structures may be used as building blocks of WBS development, and should be logically assembled into a comprehensive project WBS. Depending on the project, any given building block may be at a higher, lower, or equal level to another given building block. The resulting hierarchy of building blocks will typically require the insertion of <parent= level WBS elements at various levels in order to logically assemble the required building blocks. WBS development is typically an iterative process. It is recommended that a block diagram first be assembled in order visualize the modules required to logically complete the contract scope needed by the PM to effectively manage contract execution and reporting.
5 GAO Cost Estimating and Assessment Guide, GAO-09-3SP, March 2009, Chapter 8, page 65. 6 MIL-STD-881C, Department of Defense Standard Practice, Work Breakdown Structures for Defense Materiel Items, 3
October 2011; Section 1.5 Common Elements.
Effective Work Breakdown Structure Handbook
Course: COMPUTER NETWORKS IV (CNW401T)
University: Tshwane University of Technology
- Discover more from:
