Introduction Today, project managers are more frequently finding high value in the creation of work breakdown structures (WBS) as they begin the process of project management. Project success may be attributed specifically to use of a WBS (Halli, 1993).
As an essential element of the Planning Process Group outlined in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Third Edition (Project Management Institute PMI, 2004), everyday practice is revealing with increasing regularity that creation of a WBS to define the scope of the project will help ensure delivery of the project’s objectives and outcomes. Moreover, the more clearly the scope of the project is articulated before the actual work begins, the more likely the success of the project: “ the intelligent structure of work breakdowns is a precursor to effective project management” (Homer & Gunn, 1995, p.
Specifically, the Planning Process Group begins with three essential steps: scope planning (3.2.2.2), scope definition (3.2.2.3) and work breakdown structure development (3.2.2.4) (PMI, 2004). The following discussion will examine the current trends and practice regarding work breakdown structures.
The Importance of the Work Breakdown Structure Experienced project managers know that many things can go wrong in projects, regardless of how successfully the work is planned and executed. Component or full-project failures, when they do occur, can often be traced to a poorly developed or nonexistent WBS. A poorly constructed WBS can result in adverse project outcomes including ongoing, repeated project re-plans and extensions, unclear work assignments, scope creep or unmanageable, frequently changing scope, budget overrun, missed deadlines, and unusable new products or delivered features.
The WBS is a foundational building block to initiating, planning, executing, and monitoring and controlling processes that are used to manage projects as they are described in the PMBOK® Guide—Third Edition (PMI, 2004). Typical examples of the contribution that the WBS makes to other processes are described and elaborated in the Practice Standard for Work Breakdown Structures–Second Edition (PMI, 2006). There are many project management tools and techniques that use the WBS or its components as input (PMI, 2004, pp. For example, the WBS utilizes the project charter as its starting point.
The high-level elements in the WBS should match, word-for-word, the nouns used to describe the outcomes of the project in the scope statement. In addition, the resource breakdown structure (RBS) describes the project’s resource organization and can be used in conjunction with the WBS to define work package assignments. The WBS Dictionary defines, details, and clarifies the various elements of the WBS. The network diagram is a sequential arrangement of the work defined by the WBS and the elements of the WBS are starting points for defining the activities included in the project schedule. The WBS is used as a starting point for scope management and is integral to other PMI processes, and, as a result, the standards that define these processes explicitly or implicitly rely on the WBS. Standards that take advantage of the WBS either use the WBS as an input (e.g., PMI’s practice standard for earned value management (EVM) and the practice standard for scheduling) or incorporate the WBS as the preferred tool to develop the scope definition (e.g., the PMBOK® Guide—Third Edition; Organizational Project Management Maturity Model OPM3®).
WBS Concepts A WBS, as defined in the PMBOK® Guide—Third Edition 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. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.” With this definition, it is clear the WBS provides an unambiguous statement of the objectives and deliverables of the work to be performed. It represents an explicit description of the project’s scope, deliverables and outcomes—the “what” of the project.
The WBS is not a description of the processes followed to perform the projectnor does it address the schedule that defines how or when the deliverables will be produced, but rather is specifically limited to describing and detailing the project’s outcomes or scope. The WBS is a foundational project management component, and as such, is a critical input to other project management processes and deliverables such as activity definitions, project schedule network diagrams, project and program schedules, performance reports, risk analysis and response, control tools, or project organization. Defining the WBS The upper levels of the WBS typically reflect the major deliverable work areas of the project, decomposed into logical groupings of work. The content of the upper levels may vary, depending on the type of project and industry involved.
The lower WBS elements provide appropriate detail and focus for support of project management processes such as schedule development, cost estimating, resource allocation, and risk assessment. The lowest-level WBS components are called work packages and contain the definitions of work to be performed and tracked. These can be later used as input to the scheduling process to support the elaboration of tasks, activities, resources, and milestones which can be cost estimated, monitored, and controlled. A few of the key characteristics of high-quality work breakdown structures (PMI, 2006) are outlined below:. A central attribute of the WBS is that it is “deliverable orientated” (Berg & Colenso, 2000). The PMBOK® Guide—Third Edition defines a deliverable as: “Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase or project.” In this context, “oriented” means aligned or positioned with respect to deliverables—that is, focused on deliverables.
An additional key attribute of the WBS is that it is a “hierarchical decomposition of the work.” Decomposition is “a planning technique that subdivides the project scope and project deliverables into smaller, more manageable components, until the project work associated with accomplishing the project scope and deliverables is defined in sufficient detail to support executing, monitoring, and controlling the work” (PMI, 2004). This decomposition (or subdivision) clearly and comprehensively defines the scope of the project in terms of individual subdeliverables that the project participants can easily understand. The specific number of levels defined and elaborated for a specific project should be appropriate for effectively managing the work in question. The 100% Rule (Haugan, 2002, p.
17) is one of the most important principles guiding the development, decomposition, and evaluation of the WBS. This rule states that the WBS includes 100% of the work defined by the project scope and, by doing so, captures all of the deliverables—internal, external, and interim—in terms of work to be completed, including project management. The rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent”—and the WBS should not include any work that falls outside the actual scope of the project; that is, it cannot include more than 100% of the work. The WBS can be represented in a variety of ways, including graphical, textual, or tabular views. The form of representation should be chosen based on the needs of the specific project. Exhibit 3-Centralized Tree Structure It is clear that the WBS is the starting point in the planning process for many other essential project management processes such as estimating, scheduling and monitoring/controlling. However, applying the WBS effectively to these processes remains a difficult task for many project managers.
Transitioning from the Deliverable-Oriented WBS to the Project Schedule Frequent complaints about the relevance of deliverable-oriented WBSs are attributed to the absence of clear guidance about the methodology used to apply this scope definition to other project processes, tools, and tasks. In particular, the lack of helpful information about the processes used to apply deliverable-oriented work breakdown structures to project scheduling is seen as the primary obstacle project managers face when attempting to use deliverable-oriented work breakdown structures as a basis for scope management and schedule development. The difficulty that they encountermaking the logical association and transition from WBS to project schedule, drives their reluctance to adopt the practice. In fact, much of the available documentation (e.g., Pritchard 1998; Rational Unified Process, ) for applying WBSs to project scheduling actually suggests the development of “task-oriented” or “process-oriented” WBSs to ease the transition from WBS to project schedule. Demystifying Linkages Between the Deliverable-Oriented WBS and Project Schedule To correct and counter this confusing instruction, key guidance to assist project managers can be found in the PMBOK ® Guide—Third Edition, chapter 6.
This chapter, “Time Management,” contains much of the information required to explain and resolve the deliverable-oriented WBS-to-Project Schedule transition challenge. Although somewhat obscured by other important concepts presented in this chapter, the core elements that show the linkage between the deliverable-oriented WBS and the project schedule are present.
The elements, extracted from the chapter, that explain the transition include Activity Definition, section 6.1; Activity Sequencing, Section 6.2 and Project Schedule Development, section 6.5 are examined in detail and contain, specifically, the fundamental concepts required to simplify the process. Activity Definition (section 6.1) describes the inputs, tools, techniques, and outputs necessary to create the listing of activities that will be performed to produce desired project outcomes. The Project Time Management Overview (PMI, 2004, figure 6-1, p.
140) and the detail found in this section clearly show the scope statement, WBS, and WBS dictionary as inputs to the activity definition process. Tools for development of the activity list, milestone list and remaining outputs of the process include decomposition, rolling wave planning, and others. Illustrated simply, this can be described as. Summarizing the information found in these sections:. The core elements that enable the elaboration and development of the project schedule begin with the Scope Statement, WBS, and WBS Dictionary. These inputs are taken through a decomposition process to produce the project’s activity and milestone lists.
These in turn, are input elements to network diagramming that produces the project schedule network diagram and updated activity/milestone lists. Finally, the project schedule network diagram, updated activity, and milestone lists are then used as input to the project scheduling tools and methodology to generate the project schedule. Illustrated in simplified process-flow form as before, the entire process can be summarized as follows. Exhibit 4-WBS to Project Schedule Transition Putting These Concepts to Work To illustrate how this process would be put into practice, a simple example will be used. We will assume for this discussion that the WBS elements listed in the outline below are a few of the key scope components derived from an initial home building contract. Representing Levels 1, 2, 3, and 4, the high-level scope elements include the components of the primary structure, the foundation, exterior walls, roof, plumbing, electrical, and interior walls.
The component element list (without hierarchical structure) appear to the project manager (from the contractor) as follows:. House project. Primary structure. Foundation development.
Layout—topography. Excavation. Concrete pour. Exterior wall development.
Roof development. Electrical infrastructure. Plumbing infrastructure. Inside wall development: rough finish The WBS in Hierarchical Outline Form To organize this component list as it might be developed, the contractor might use the following hierarchical relationships (as even a novice might intuitively use). For this example, we will assume that this work is truly the correct representation. Working with the contractor, the project manager, then, would arrange the high-level deliverables for the house project in the following manner.
Exhibit 5-House Project WBS Elements: An Illustration Here, in Exhibit 5, Level 1 indicates that the work called “house project” represents 100% of the work of the project. All other scope (WBS) elements associated with the project would be subordinate to the house project element. At Level 2, there are four major components that make up the house project: primary structure, electrical infrastructure, plumbing infrastructure and inside wall development. Level 3 shows the key components of the primary structure: foundation development, exterior wall development, and roof development. And finally the foundation development is decomposed into three work elements that become Level 4: layout-topography, excavation, and concrete pour. Granted, this is a highly simplified characterization of the work. It is used here, however, to help illustrate the WBS hierarchical concept, not necessarily the proper breakdown of all the work required to construct a home.
Identifying Dependencies Between WBS Elements Looking at this particular breakdown of the work, contractors, project managers, and homeowners alike would likely recognize that if this were the work to be completed, it would occur in a prescribed order, with some elements coming before—and being completed—before others begin. For example, it would be very helpful to build the foundation and walls before constructing the roof. Although it isn’t mandatory to do it in this way—building the foundation first and then the walls—establishing this order would allow the roof to be constructed on top of the walls, where it will ultimately be completed and integrated to secure the structure.
Certainly this is not the only approach to home construction, and the order can surely be modified to accelerate the building process, but for this illustration, we will presume a traditional home construction project, and the order would be: foundation, exterior walls, then roof. Once the foundation, walls, and roof are completed (and assuming additional details such as windows, doors, and exterior finish are part of the work), the construction can move to the interior of the home. Here, it would make sense to complete the electrical and plumbing work before putting the interior wall material in place. As before, this order is not mandatory, but common practice would indicate that the simplest, quickest, and easiest approach would be to first complete the work that would be hidden by the interior walls, then apply the interior wall material.
Again, for this example, we will use that convention. Representing Scope Sequence and Dependency With the previous discussion in mind, a project manager could begin developing a very high-level representation of the work described by the scope (WBS) using nothing more sophisticated than pencil and paper to illustrate the dependencies described. Beginning with the house project element at Level 1, and including all of the WBS elements required to show the implied dependency, one representation of the work might look like the set of interrelated elements found in Exhibit 6.
Exhibit 6-House Project High-Level Scope Sequence Exhibit 6 shows how the project manager would use a sequence representation or an illustrated dependency map to indicate that foundation development (with its work packages, layout-topography, excavation, and concrete pour) must complete before the exterior wall development can begin, and that roof development depends on the completion of the exterior walls. Once the roof is complete, both the plumbing and electrical work can begin, but the interior walls would not start until the plumbing and electrical work are complete. (In reality, the word “complete” here could mean “roughed-in,” where wires and pipes are run to and from their destinations but without fixtures attached to them.) It is important to note that the work elements shown here are not tasks or activities, but rather significant scope components that logically lead and follow one another.
Once these elements (work packages) are decomposed via the process described earlier, the resulting tasks, activities, and milestones can be placed into the project scheduling tool. Taking the Process One Step Further: Introducing the Concepts of Inclusion and the Scope Relationship Diagram To further ease the transition from the deliverable-oriented WBS to project schedule, we can refine the central process to illustrate more clearly the relationships between scope elements—before they are placed into the project schedule.
In Exhibit 6 above, a scope sequence was used to show dependency between various WBS elements. In this illustration, each element is shown in linear fashion, using a two-dimensional sequential format, with lines connecting the elements to show predecessor and successor dependencies. To produce the network diagram, the two dimensions at the core of the process are order and precedence (or dependency). Although these two dimensions are critically important to the development of a network diagram, in some cases they are not sufficient to enable the project manager to easily envision the project schedule from the network diagram. Absent from this linear depiction of scope is the addition of a third dimension to complement order and dependency. To clarify: the concept/dimension of “inclusion” can be inserted into the process to convert the linear, two-dimensional network into a diagram that would depict how individual WBS elements are related to one another, as parent and subordinate elements, reflecting in graphic illustration, how they are developed and listed in an outline, chart, or WBS template. “Inclusion” as a dimension is used to show which elements are “part of” larger work elements, as well as to articulate clearly which WBS elements are not “part of” the work of others.
Stated another way, some work depicted by a WBS is intended to be seen as being “part of” a higher-order work element, whereas other elements in the WBS are clearly not “part of” specific higher-order elements. Using the example from the house project above, we will take another look at the hierarchical outline for the work. Describing this outline using the concept of “inclusion,” it is easy to see that the WBS elements 1.1, 1.2, 1.3, and 1.4—the primary structure, electrical infrastructure, plumbing infrastructure, and inside wall development are all “part of” the house project.
They are integral to the completion of the project and are “included in” the work. By the same token, it is clear from the outline that the elements 1.1.1.1, 1.1.1.2, and 1.1.1.3 are all “part of” and “included in” the work that makes up the foundation development WBS element (1.1.1). Our sequence diagram in Exhibit 6 shows the precedence and dependency between these elements but does not clearly show which elements are actually “part of” the scope of other elements. In fact, if you examine Exhibit 6 carefully, you will notice that some of the elements have been left out of the diagram—for example, the Level 1 WBS element house project is not included.
Additionally, the first Level 2 element, foundation development is excluded, as are the three Level 4 elements, layout, excavation, and concrete pour. Why have they been excluded? Because including them in this drawing would be confusing and would disturb the illustration of the dependencies that are present. How would it be possible in Exhibit 6 to represent the Level 1 or Level 4 WBS elements without disturbing the logical flow of the dependencies between the relevant elements? In truth, it is nearly impossible to properly include those elements in this illustration.
To correct this issue and explain, we will examine the foundation development elements closely. In Exhibit 6 the foundation development elements at Level 4, layout-topography, excavation and concrete pour were excluded to reduce the confusion about the dependency between the Level 3 elements, foundation development (1.1.1), exterior wall development (1.1.2), and roof development (1.1.3). If we were to include them, however, they would also reflect their own natural or logical sequence.
For instance, the layout of the foundation must precede any excavation—and the excavation must be complete before any concrete is poured. Considering the dependency between these elements, they could be shown as a series of scope elements executed in sequential fashion, under the “parent” element “foundation development” at Level 3.
This concept is shown, as an excerpt from the house project, in Exhibit 8. Exhibit 8-Foundation Development WBS Elements from the House Project In this excerpt, it’s difficult to clearly envision or understand the relationship between the parent and children WBS elements other than that we have been told that the three elements at Level 4 are children of the parent element “foundation development”—which is not accurately represented in Exhibit 8. If we were to link the parent, the foundation development would appear as simply another node in the sequence, when in actuality it isn’t. In truth, the relationship between the foundation development element at Level 3 and its children at Level 4 is more clearly shown in the textual, outline form in Exhibit 9. Exhibit 9-Foundation Development Outline from House Project Here, it is easy to recognize the parent-child relationship between the Level 3 foundation development WBS element and the Level 4 elements, layout–topography, excavation, and concrete pour. Because of the indentation of the Level 4 WBS elements under the parent element, this outline form communicates to us and clearly shows that layout-topography, excavation, and concrete pour are actually “part of” and “included in” the work that is called foundation development. Showing this in graphic format (see Exhibit 10) and using an alternative view to represent this parent-child relationship may help somewhat, but it does not fully capture the true relationship between the parent and child elements.
Nasa Work Breakdown Structure Reference Guide
Exhibit 10-Alternate Foundation Development Graphic from House Project In Exhibit 10, it is difficult to determine the true relationship between the parent and child elements. Does “foundation development” come before or perhaps after the child elements? Of course, neither of those would be correct. Is foundation development above or below? Neither of those would be correct. Clearly, we need a better way to represent and communicate the relationship between these elements.
To solve and illustrate how these relationships actually occur, a scope relationship diagram will be used instead to clearly show the relationships detailed in Exhibit 9, as well as the order and precedence shown in Exhibit 8. The resulting scope relationship diagram reflects the added dimension of inclusion representing these same WBS elements as follows in Exhibit 11. Exhibit 11-Scope Relationship Diagram from House Project Foundation Development Segment Here, in this scope relationship diagram representation, the foundation development WBS element, 1.1.1, is larger and visually includes the lower level elements 1.1.1.1, 1.1.1.2, and 1.1.1.3. With the addition of arrows to show the scope sequence described earlier, we are now able to illustrate how scope elements are planned within the concept of inclusion. In Exhibit 12 it is clear to see that the three elements at Level 4 are executed in sequence “within” or as “part of” the scope of the parent element, foundation development. Exhibit 13-Scope Relationship Diagram for House Project With this illustration, demonstrating or describing which WBS elements are “part of” others is easy. The parent elements always include the child elements and appear as nested representations of work within the scope relationship diagram.
Moreover, it is easy to recognize which WBS elements are both parent and child. Nesting the scope elements clarifies the true relationship between the elements, a representation that previously could be illustrated only in outline form. To take this concept further, although the scope relationship diagram for the house project enables the visualization of the work “included” within the scope of each parent WBS element, it also allows a more direct and straightforward transition from deliverable-oriented WBS to project schedule. This results from the additional clarity that the scope relationship diagram provides, as it represents the relationships between WBS elements graphically, showing how they interact within the entire scope of the project.
Added benefits are also derived from this WBS representation. As decomposition is performed against the WBS elements in this scope relationship diagram (the lowest level being work packages), the resulting tasks, activities, and milestones can be easily grouped in the same manner as the WBS. These will be input to the project schedule and will facilitate the grouping of work that will be monitored and controlled during the execution of the project. Beyond the initial view in Exhibit 13, the various WBS elements can then be moved into a logical sequence. Dependency lines can be added to illustrate how the sequence of each of the scope elements within the project (parents and children) relate to and depend on one another. This reveals a logical representation of the sequence of the work to be performed. Using the scope relationship diagram from Exhibit 13, the logical sequence shown in Exhibit 14 would be produced by adding the dependency lines.
Exhibit 14-Scope Relationship Diagram for House Project-with Scope Sequence Using this approach, the project manager is able to use a step-wise process to create the linkage between the components of the deliverable-oriented WBS and the scope of the project, prior to further decomposition and development of the Project Schedule. Most importantly, representing the WBS in this way may simplify the transition from WBS to a Project Schedule we described at the beginning of this concept discussion.
To conclude this discussion, we want to be sure you are able to clearly see these two methods as reliable ways to transition from the deliverable-oriented WBS to the Project Schedule. So to recap, a clear path can be drawn from deliverable-oriented WBS to Project Schedule, if that path is taken through a logical sequence of decomposition and network diagramming. This concept is represented in Figure 15, which is a repeat of the concepts we discussed at the beginning of the discussion. Exhibit 15-WBS to Project Schedule Transition As we have described, once the WBS is complete, illustrated (documented) and placed under change management control, it becomes the foundation for other important aspects of the project, including the project schedule, risk management plan, budget and financial management plan, quality plan, resource management plan, and others. Beyond this, the WBS plays a vital role in the executing, monitoring, controlling, and closeout phases of a project, and in so doing, transitions from being seen primarily as a planning tool, to having an active role, where the WBS becomes the basis for decision making.
It establishes clear boundaries for the project during the initiating and planning phases, and provides a ready tool for ensuring those boundaries are protected during the remaining phases of the project. Summary In summary, applying the WBS to the project management life cycle is simply an outcome of effective scope analysis, WBS development, and careful project management execution, monitoring, and control by the project manager. Applying a carefully articulated WBS and WBS dictionary to subsequent project processes further utilizes tools such as the network diagramming technique or scope relationship diagram development and results in the creation of a baselined project schedule, drawn from the decomposition of work packages—which reveals key project tasks, activities, and milestones. Key attributes associated with effective WBS development are included below.
Berg, Cindy and Colenso, Kim. 2000, Work Breakdown Structure Practice Standard Project – WBS vs. Activities, PMI Network, April. (2004, November) Work Breakdown Structures, Version 2.01.
Retrieved 2/22/05, Website Halli, Wayne. Scope Management through a WBS.
Key to success for the Logan Expansion project. Homer, John L and Gunn, Paul D. Work Structuring for Effective Project Management. Project Management Institute 26th Annual Seminar/Symposium.
New Orleans LA, October, 1995, p. Project management: A systems approach to planning, scheduling, and controlling (6th ed.). New York: John Wiley & Sons PMI (2004) A Guide to the Project Management Body of Knowledge (PMBOK ® Guide). Newtown Square, Pennsylvania: Project Management Institute Inc. PMI (2006) Practice Standard for Work Breakdown Structures – Second Edition. Newtown Square, Pennsylvania: Project Management Institute Inc.
Pritchard, Carl (1998), How to build a work Breakdown Structure, The cornerstone of Project Management. Arlington, Virginia: ESI International Rational Unified Process, Rational Software Corporation (1987-2001), Rational Unified Process, Overview, Retrieved 3/20/2005, Website: Haugan, Gregory T. (2002), Effective Work Breakdown Structures, Vienna, Virginia: Management Concepts, Macdonald Bradley, Inc (2002, December) Independent Verification and Validation White Paper (December 2002)., retrieved 2/20/2005, Website: U.S Department of Energy (2001, August) Performance Based Contracting: Development of a Work, retrieved 1/18/2005, Website.
Work Breakdown Structure (WBS) A (WBS) is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge defines the work breakdown structure as a 'deliverable oriented hierarchical decomposition of the work to be executed by the project team.' The work breakdown structure visually defines the scope into manageable chunks that a project team can understand, as each level of the work breakdown structure provides further definition and detail. Figure 1(below) depicts a sample work breakdown structure with three levels defined. Work Breakdown Structure An easy way to think about a work breakdown structure is as an outline or map of the specific project. A work breakdown structure starts with the project as the top level deliverable and is further decomposed into sub-deliverables using the following outline hierarchy (Figure 2): Figure 2. Work Breakdown Structure Deliverable The project team creates the project work breakdown structure by identifying the major functional deliverables and subdividing those deliverables into smaller systems and sub-deliverables.
These sub-deliverables are further decomposed until a single person can be assigned. At this level, the specific work packages required to produce the sub- deliverable are identified and grouped together. The work package represents the list of tasks or 'to-dos' to produce the specific unit of work. If you've seen detailed project schedules, then you'll recognize the tasks under the work package as the 'stuff' people need to complete by a specific time and within a specific level of effort. From a cost perspective, these work packages are usually grouped and assigned to a specific department to produce the work.
These departments, or cost accounts, are defined in an organizational breakdown structure and are allocated a budget to produce the specific deliverables. By integrating the cost accounts from the organizational breakdown structure and the project's work breakdown structure, the entire organization can track financial progress in addition to project performance. Why use a Work Breakdown Structure? The work breakdown structure has a number of benefits in addition to defining and organizing the project work. A project budget can be allocated to the top levels of the work breakdown structure, and department budgets can be quickly calculated based on the each project's work breakdown structure.
By allocating time and cost estimates to specific sections of the work breakdown structure, a project schedule and budget can be quickly developed. As the project executes, specific sections of the work breakdown structure can be tracked to identify project cost performance and identify issues and problem areas in the project organization. For more information about Time allocation, see the. Project work breakdown structures can also be used to identify potential risks in a given project. If a work breakdown structure has a branch that is not well defined then it represents a scope definition risk. These risks should be tracked in a project log and reviewed as the project executes. By integrating the work breakdown structure with an organizational breakdown structure, the project manager can also identify communication points and formulate a communication plan across the project organization.
When a project is falling behind, referring the work breakdown structure will quickly identify the major deliverables impacted by a failing work package or late sub- deliverable. The work breakdown structure can also be color coded to represent sub- deliverable status. Assigning colors of red for late, yellow for at risk, green for on-target, and blue for completed deliverables is an effective way to produce a heat-map of project progress and draw management's attention to key areas of the work breakdown structure.
Work Structure Breakdown Template
Abstract Utilization of the work breakdown structure (WBS) technique is an effective aid in managing Department of Energy (DOE) programs and projects. The technique provides a framework for project management by focusing on the products that are being developed or constructed to solve technical problems. It assists both DOE and contractors in fulfilling their management responsibilities. This document provides guidance for use of the WBS technique for product oriented work identification and definition. It is one in a series of policy and guidance documents supporting DOE's project manaagement system.
Publication Date: Fri Feb 06 00:00:00 EST 1987 Research Org.: USDOE Assistant Secretary for Management and Administration, Washington, DC. Office of Project and Facilities Management OSTI Identifier: 6701198 Alternate Identifier(s): OSTI ID: 6701198; Legacy ID: DE87007606 Report Number(s): DOE/MA-0295 ON: DE87007606 Resource Type: Technical Report Resource Relation: Other Information: Portions of this document are illegible in microfiche products. Original copy available until stock is exhausted Country of Publication: United States Language: English Subject: 99 GENERAL AND MISCELLANEOUS//MATHEMATICS, COMPUTING, AND INFORMATION SCIENCE; US DOE; CONTRACT MANAGEMENT; CONTRACTORS; MANAGEMENT; NATIONAL ORGANIZATIONS; PROGRAM MANAGEMENT; US ORGANIZATIONS 990100. Management.
This document provides guidance on development and use of the Work Breakdown Structure (WBS) technique. It describes the types of work breakdown structures, their preparation, and their effective use for organizing, planning, and controlling projects and contracts managed by the Department of Energy (DOE).
The WBS technique is the preferred management tool for identifying and defining work. It provides an ordered framework for planning and controlling the work efforts to be performed in achieving technical objectives and for summarizing data, and the quantitative and narrative reports used for monitoring cost, schedule and technical performance. A WBS is developed for first identifying the major end items or systems to be produced, followed by their successive subdivision into increasingly detailed and manageable subsidiary products.
Work Breakdown Structure Reference Guide
Most of these subsidiary products are the direct result of work, while others are simply the aggregation of selected products into a logical set for management control purposes. In either case, detailed tasks are eventually identified for each product on the WBS at the level where work will be performed. As a minimum, these detailed tasks or work packages identify the product, describe the effort to be performed, identify the resources to be applied, specify the budget and schedule constraints, and the technical requirements, and identify the organizational element responsible for work accomplishment. Site Management System (SMS) guidance requires a Fiscal Year Work Plan (FYWP) to be prepared for the Environmental Restoration (ER) Mission Area and all related programs. This revision is a complete update to cover the FY 1994 time period. This document describes the overall ER Missions Area and provides FYWP appendices for each of the following five program areas: Remedial Action (RA); Decontamination and Decommissioning (D&D); Project Management and Support (PM&S); Surveillance and Maintenance (S&M); and Disposal Facilities (DF).
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |