MIL-STD-881C Work Breakdown Structures (WBS)

2011.10.03

Online reader. This page contains the main body of MIL-STD-881C. The system-specific appendices are separate pages so you can open only the reference you need.

NOT MEASUREMENT SENSITIVE

3 October 2011

SUPERSEDING MIL-HDBK-881A 30 July 2005 MIL-STD-881B 25 March 1993

DEPARTMENT OF DEFENSE STANDARD PRACTICE

WORK BREAKDOWN STRUCTURES FOR DEFENSE MATERIEL ITEMS

Reinstated after 3 October 2011 and may be used for new and existing designs and acquisitions.

AMSC 9213 AREA MISC FOREWORD 1. This Standard is approved for use by all Departments and Agencies of the Department of Defense (DoD). It is for direction and should be included as a contract requirement.

2. This Standard addresses mandatory procedures for all programs subject to DoD Instruction 5000.02.

3. This military standard is applicable to all defense materiel items (or major modifications) (a) established as an integral program element of the Future Years Defense Program (FYDP), or (b) otherwise designated by the DoD Component or the Under Secretary of Defense (Acquisition). This Standard is mandatory for all Acquisition Category (ACAT) I, II, and III programs.

4. A Work Breakdown Structure (WBS) provides a consistent and visible framework for defense materiel items and contracts within a program. This Standard offers uniformity in definition and consistency of approach for developing all levels of the WBS. Generating and applying uniform work breakdown structures improves communication in the acquisition process. It also provides direction to industry in extending contract work breakdown structures.

5. This Standard supersedes MIL-HDBK-881A, dated 30 July 2005 and MIL-STD-881B, dated 25 March 1993 entitled Work Breakdown Structures for Defense Materiel Items. MIL-STD-881C is based on the cooperative efforts of the military services with assistance from industrial associations. Changes to the Standard specifically address advances in technology and modifications of the acquisition process, and incorporates new materiel items, developmental concepts, and approaches.

6. Comments (such as recommendations, additions, or deletions) and any pertinent information, which may be useful in improving this document, should be addressed to the Office of the Assistant Secretary of Defense for Acquisition, Performance Assessments and Root Cause Analysis (OASD(A))/PARCA, 3620 Defense Pentagon, RM 5A 1082, Washington DC 20301-3620. Since contact information can change, you may want to verify the currency of this address information using the ASSIST online database at https://assist.daps.dla.mil.

FOREWORD

1. GENERAL INFORMATION

1.1 Standard Purpose and Structure. This Standard presents direction for effectively preparing, understanding, and presenting a Work Breakdown Structure (WBS). It provides the framework for Department of Defense (DoD) Program Managers to define their program’s WBS and also to defense contractors in their application and extension of the contract’s WBS. Section 1 defines and describes the WBS. Section 2 provides instructions on how the WBS is applied as well as how to develop a Program WBS in the pre-award timeframe. Section 3 provides direction for developing and implementing a Contract WBS and Section 4 examines the role of the WBS in the post-award timeframe. This Standard also provides WBS definitions for specific defense materiel commodity systems in Appendices A through K. Appendix L addresses WBS elements that are common to all systems.

The primary objective of this Standard is to achieve a consistent application of the WBS for all programmatic needs (including performance, cost, schedule, risk, budget, and contractual). Discussion and direction was compiled based on many years of lessons learned in employing WBSs on defense programs.

1.2 Support Documentation. The foundation for a WBS is contained in DoD Directive 5000.01 and DoD Instruction 5000.02. These documents identify responsibilities in the acquisition process from the Office of the Secretary of Defense to the DoD component field activities. Preparing a WBS is generally discussed in the context of planning and monitoring a defense system program.

DoD Directive 5000.01 “The Defense Acquisition System” requires a disciplined approach in establishing program goals over its life cycle with streamlined and effective management that “is accountable for credible cost, schedule, and performance reporting.” The WBS is a critical tool in ensuring all portions of the program are covered. The WBS will also facilitate the required collaboration within the Integrated Product Team (IPT) structure by providing a tie between performance, cost, schedule, and risk information. The WBS can also facilitate the required technical rigor and integrated test and evaluation throughout the defense acquisition process.

DoD Instruction 5000.02 “Operation of the Defense Acquisition System” further outlines the required framework and provides impetus for use of a WBS. The evolution of the system through incremental development further drives the requirement to breakdown the system in a structure that clarifies which capabilities will be satisfied in a specific increment of the system development. The instruction sets the requirements for Integrated Master Schedules (IMS), Earned Value Management (EVM) and other statutory, regulatory, and contract reporting information and milestone requirements in which the WBS is a critical element.

The WBS is also a critical link to the Systems Engineering Plan (SEP), which is required to be developed prior to all milestone decisions for all Acquisition Category (ACAT) programs. Guidelines for the SEP are included in the SEP Annotated Outline (current version).

In addition, the purpose of the Chairman of the Joint Chief of Staff Instruction (CJCSI) 3170.01 (current version) (in concert with the Manual for the Operation of the Joint Capabilities Integration and Development System (JCIDS) (current version) is to establish the policies and procedures of the JCIDS, which directly supports the DoD acquisition process and hence has WBS implications.

The Program WBS and Contract WBS aid in documenting the work effort necessary to produce and maintain architectural products in a system life cycle. The DoD Architecture Framework (DoDAF) (current version) defines a common approach for DoD architecture description development, presentation, and integration for warfighting operations and business operations and processes.

The Defense Acquisition Guidebook (DAG) is a source of best practices and includes numerous references to the use of a WBS.

1.3 What Does a WBS Accomplish? The following three sub-paragraphs will discuss Applications, Benefits and Challenges with regard to the WBS. 1.3.1 Applications. This Standard addresses two fundamental and interrelated WBS structures: (1) the Program WBS and (2) the Contract WBS (including flow-down reporting requirements).

The Program WBS provides a framework for specifying program objectives. Each WBS element provides logical summary levels for assessing technical accomplishments, for supporting the required event-based technical reviews, and for measuring cost and schedule performance. The WBS defines the program in terms of hierarchically-related, product-oriented elements and includes “other Government” elements (for example, Program Office Operations, Manpower, Government Furnished Equipment (GFE), and Government Testing). It represents the entire program from the Government Program Manager’s responsibility.

The contract WBS is the Government approved WBS for program reporting purposes and includes all program elements (for example, hardware, software, services, data, or facilities), which are the contractor’s responsibility. It includes the contractor’s discretionary extension to lower levels, in accordance with Government direction and the contract Statement of Work (SOW).

The WBS is defined, developed, and maintained throughout the system life cycle based on a disciplined application of the systems engineering process. The goal is to develop a WBS that defines the logical relationship among all program elements to a specific level (typically Level 3 or 4) of indenture that does not constrain the contractor’s ability to define or manage the program and resources. However, if the Government considers some program elements to be high-cost or high-risk, the system may be defined to a lower level of the WBS; this is reasonable if the product-oriented logical extension is maintained. The contractor should extend all other elements to the level and form based on the way the system is developed, produced, or managed. A secondary, but still important goal, is to provide a systematic and standardized method for gathering cost data across all programs. Having actual historical data to support cost estimates of similar defense materiel items is a valuable resource. However, the primary purpose of the WBS is to define the program’s structure, and the need for data should not distort or hinder the program definition.

Further, the WBS serves as a coordinating medium. Through the Program WBS and the Contract WBS, work progress is documented as resources are allocated and expended. Performance, cost, schedule, and technical data are routinely generated for reporting purposes. The WBS is the infrastructure to summarize data for successive levels of management and provide appropriate information on projected, actual, and current status of the individual elements. When appropriately structured and used in conjunction with systems engineering principles, cost estimating, EVM, integrated scheduling, and risk management, the WBS allows for program status to be continuously visible so the program manager and the contractor can identify, coordinate, and implement changes necessary for desired results.

The WBS applies to the specific categories of defense materiel items listed below. These are further discussed in 1.5 and complete definitions of each are included as Appendices A through L.

a. Aircraft Systems

b. Electronic Systems

c. Missile Systems

d. Ordnance Systems

e. Sea Systems

f. Space Systems

g. Surface Vehicle Systems

h. Unmanned Air Vehicle Systems
i. Unmanned Maritime Systems

j. Launch Vehicle Systems

k. Automated Information Systems

l. Common Elements

1.3.2 Benefits. The WBS assists in several ways during the program life cycle:

a. Segregates a defense materiel item into its component parts, clarifying the relationship among the parts, and the relationship of the tasks to be completed both to each other and to the end product.

b. Facilitates effective planning and assignment of management and technical responsibilities.

c. Aids status tracking of technical efforts, risks, resource allocations, expenditures, and cost/schedule/technical performance.

d. Helps ensure that contractors are not unnecessarily constrained in meeting item requirements.

e. Provides a common thread for the Earned Value Management System (EVMS), the Integrated Master Plan (IMP) and the IMS, allowing consistency in understanding program cost and schedule performance. The contract WBS includes the breakdown of work into small enough entities that can be analyzed and assessed. As part of EVMS, the contract WBS elements provide a structure for collecting costs and assessing performance. The IMP is the contractor’s event-driven plan that documents the significant accomplishments necessary to complete the work and ties each accomplishment to a key program event. The IMS is tied to the IMP and serves as a tool for time phasing work and assessing technical performance. Schedule activities in the IMS are traceable to the IMP and contract WBS elements used in EVMS, allowing commonality for integrated program assessment of cost, schedule, technical performance, and associated risks.

1.3.3 Challenges. The primary challenge is to develop a WBS that defines the logical relationship between all program elements without constraining work necessary to achieve program objectives and meets all program reporting requirements. A WBS should be sufficient to provide necessary program insights for effective status reporting and risk mitigation, facilitating the contractor’s ability to effectively execute the program.

A secondary challenge is to balance the program definition aspects of the WBS with its data-generating aspects. Using available data to build historic files to aid in the future development of similar defense materiel items is a very valuable resource. However, the primary purpose of the WBS is to define the program’s structure, and the need for data should not distort or hinder the program definition.

1.4 How is the WBS Related to Other Contract Requirements? The WBS provides a basis for effective communication throughout the acquisition process. It is a common link, which integrates planning, scheduling, cost estimating, budgeting, contracting, configuration management, and performance reporting disciplines. It permits the Government and Industry managers to continually evaluate progress in terms of contract performance.

The WBS forms the basis of reporting structures used for contracts requiring compliance with ANSI/EIA 748 EVMS Guidelines and reports placed on contract such as Cost and Software Data Reporting (CSDR), Contract Performance Reports (CPR), and Contract Funds Status Reports (CFSR).

1.5 Definitions. The following definitions are intended to improve continuity and support a common understanding of program expectations.

1.5.1 Program Element (PE). The program element is the basic building block of the Future Years Defense Program (FYDP). The PE describes the program mission and identifies the organization responsible for performing the mission. A PE may consist of forces, manpower, materiel (both real and personal property), services and associated costs, as applicable.

1.5.2 Defense Materiel Item. This term refers to equipment, apparatus, and supplies of a military force or other organization. It identifies a system or item usually established as an integral PE or identified as a project within an aggregated PE.

1.5.3 Work Breakdown Structure (WBS). This term is defined as:

a. 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.

b. 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. In other words, the WBS is an organized method to breakdown a product into sub-products at lower levels of detail.

c. A WBS can be expressed to any level of detail. While the top three levels are the minimum required for reporting purposes on any program or contract, effective management of complex programs requires WBS definition at considerably lower levels. This is particularly true of items identified as high-cost, high-risk, or high technical interest. Under these circumstances, it is critical to define the product at a lower level of WBS detail. In this case, managers should distinguish between WBS definition and WBS reporting. The WBS should be defined at the level necessary to identify work progress and enable effective management, regardless of the WBS level reported to program oversight.

1.5.4 Common Elements. The term “Common Elements” refers to the elements listed below that are applicable to all major systems and subsystems as required:

a. Integration, assembly, test, and checkout

b. Systems engineering

c. Program management

d. System test and evaluation

e. Training

f. Data

g. Peculiar support equipment

h. Common support equipment

i. Operational and site activation

j. Industrial facilities

k. Initial spares and repair parts

These common elements are described in further detail in Appendix L. Appendix L also contains sections for unique application for the following:

a. Common Elements L.4 – Space Systems
b. Common Elements L.5 – Launch Vehicle Systems

c. Common Elements L.6 – Automated Information System

In addition to these common elements, each defense system has a unique combination of hardware and software, which defines the capability or end product of that system.

a. Aircraft System – Applies to fixed or movable wing, rotary wing, or compound wing manned air vehicles designed for powered or unpowered (for example, a glider) guided flight

b. Electronic System – Applies to electronic system capability (for example, processor, radio, electronic warfare, radar, etc.).

c. Missile System – Applies to a missile in an operational environment, which produces a destructive effect on selected targets.

d. Ordnance System – Applies to all munitions (nuclear, biological, chemical, psychological, and pyrotechnic) and the means of launching or firing them.

e. Sea System – Applies to surface and submersible ship platforms, systems, weapons, and equipment required for performing naval tasks at sea.

f. Space System – Applies to developing, delivering, and maintaining space vehicles in specific orbit placement, operation, and to recovering unmanned space systems.

NOTE: Appendix F, Space Systems is specifically written to cover unmanned earth orbiting satellites. For manned, recoverable, and interplanetary systems, additional elements are required.

g. Surface Vehicle System – Applies to tracked, wheeled and amphibious vehicles that navigate over the surface and water.

h. Unmanned Air Vehicle System – Applies to fixed or movable wing, rotary wing, or compound wing unmanned air vehicles designed for powered or unpowered (glider) guided flight.

i. Unmanned Maritime System – Applies to unmanned surface and submersible ship platforms, systems, weapons, and equipment required to perform naval tasks at sea.

j. Launch Vehicle System – Applies to developing, delivering, and maintaining launch vehicles.

k. Automated Information System – Applies to developing, delivering and maintaining an assembly of computer hardware, software, firmware, or any combination of these, configured to accomplish specific information-handling operations, such as communication, processing, and storage of information. Included is Enterprise Resource Planning systems (ERPs), Management Information Systems (MIS), networks, or other electronic information handling systems, and associated equipment. 1.5.5 Level Identification. At least the top three levels are specified in each WBS. Some appendices specify a fourth or fifth level.

a. Level 1 is the entire system and/or program, a program element, project or subprogram, for example, an electronic system. An “electronic system” might be a command and control system, a radar system, a communications system, a sensor system, navigation or guidance system, or electronic warfare system.

b. Level 2 elements are the major elements subordinate to the Level 1 major elements, for example, an air vehicle of a missile or aircraft system. These major elements are prime mission products, which include all hardware and software elements. Level 2 elements also include aggregations of system- level services (for example, systems engineering, system test and system test and evaluation, or program management) and data.

c. Level 3 elements are elements subordinate to Level 2 major elements and include hardware, software, and services. For example, the radar data processor of the fire control radar, or the Developmental Test and Evaluation (DT&E) subordinate element of System Test and Evaluation, or the technical publications element of Technical Data.

d. Level 4 elements follow the same process of breakdown and are elements subordinate to Level 3 and represent a further definition of the hardware, software and services. For example, major subsystems of the radar data processor. Lower level elements follow the same process.

1.5.6 Program WBS. The Program WBS encompasses an entire program, including the Contract WBS and “other Government” elements (for example, Program Office Operations, Manpower, Government Furnished Equipment (GFE), Government Testing). It defines at a high level what is to be procured and consists of at least three program levels with associated definitions. The Program WBS is used by the Government program manager and contractor to develop and extend a contract WBS. It contains uniform terminology, definitions, and placement in the product-oriented family tree structure.

1.5.7 Contract WBS. The Contract WBS is the complete WBS as included in the DoD-approved Program WBS extended to the agreed-to contract reporting level and any discretionary extensions to lower levels for reporting, which are considered high-cost, high-risk or high technical interest. It defines these lower level components as to what is to be procured and includes all the product elements (hardware, software, services, data or facilities), which are defined by the contractor and are their responsibility. This comprehensive Contract WBS forms the framework for the contractor’s management control system.

1.5.8 Subcontract WBS. The subcontract WBS is the complete WBS as included in the DoD approved subcontract plan and WBS extended to the agreed to contract reporting level and any discretionary extension to lower levels for reporting which are considered high-cost, high-risk or high technical interest. It defines these lower level components as to what is to be subcontracted and includes all the WBS elements which are defined by the subcontractor and are their responsibility. This comprehensive Subcontract WBS forms the framework for the subcontractor’s management control system. The elements in the Subcontract WBS should not be duplicated in the Contract WBS. Only the Level 1 of the Subcontract WBS should be included in the Contract WBS. The prime contractor should report the subcontract costs in summary on the remaining WBS elements.

1.6 WBS Evolution. Throughout any system’s life cycle, systems engineering leads the system development process. This function includes developing system specifications, functional specifications, or a set of configuration items through requirements analysis, functional analysis and allocation, synthesis and systems analysis, and controls. The important factor is satisfying total systems cost, schedule, and performance requirements at an acceptable level of risk.

As the system is defined and developed, the DoD program manager can better understand and identify the WBS structure that is appropriate for the program. Figure 1 below provides an illustration of the system life cycle.

FIGURE 1. The Defense Acquisition Management Framework

The Materiel Development Decision (MDD) is the formal entry into the Materiel Solution Analysis phase and the acquisition process, and is mandatory for all programs. The purpose of this phase is to pursue a materiel solution to an identified capability gap that meets an established capability need (such as an Information Technology system, incremental improvement to an existing capability, or an entirely new “breakout” or other transformational capability). The Initial Capabilities Document (ICD) establishes conditions for the scope of alternatives to be considered in an Analysis of Alternatives (AoA). The AoA process plays a key role in the selection of a preferred system solution that satisfies the capability need documented in the approved ICD. Throughout the AoA process, a WBS is the key communication tool to establish life cycle cost estimates, the potential solution structure, and the baseline for measuring cost, schedule, and performance criteria.

Throughout the Materiel Solution Analysis phase into the Technology Development (TD) phase, the program WBS provides the basis for the system to be broken into its component parts and support the definition of a the contract WBS. The purpose of the TD phase is to reduce technology risk, determine the appropriate set of technologies to be integrated into a full system, demonstrate critical technologies on representative prototypes, and in many cases to initiate traceable requirements flow down to complete a preliminary design for the full requirement/full system. These activities form the more detailed development of the WBS.

Program offices planning a Preliminary Design Review (PDR) in the TD phase should have a well- documented and defined WBS and associated development schedules. This means that the program WBS needs to be defined with its associated contract WBS prior to Milestone B. It is essential that both the Government and the contractor can agree on a fully defined WBS at PDR and future Engineering and Manufacturing Development (EMD) activities.

By the end of the EMD phase, the establishment of the product baseline for all configuration items requires that production-representative articles be demonstrated in their intended environment and that manufacturing processes have been effectively demonstrated prior to Milestone C. Hence, by the end of EMD, the WBS is defined at its lowest levels, which best represents the entire system.

Just as the system is defined and developed throughout its life cycle, so is the WBS. The WBS will be developed and maintained based on the systems engineering efforts throughout the system’s life cycle. After the Program WBS has been approved (through the CSDR process), the contractor and the Government will then agree to an extension of the Contract WBS to appropriate lower levels, to better define the complete contract scope. When integrated with the Program WBS, the extended Contract WBS forms a complete WBS, which will be used throughout the program’s life cycle. Figure 2 below displays this process.

FIGURE 2. WBS Evolution

2. GOVERNMENT PROGRAM MANAGEMENT INSTRUCTIONS

2.1 Program WBS Attributes. The Program WBS is intended to structurally illustrate a clear understanding of the technical objectives and the end item(s) or end product(s) of the work to be performed by both Government and contract entities.

In order to use the Program WBS as a valuable framework for communicating the technical objectives, it must be product oriented. Its elements must represent identifiable work products, whether they are equipment, data, or related service products. A WBS is a product structure—not an organizational structure—which provides the complete definition of the work to be performed by all participants and the required interfaces between them.

2.2 Preparing a Program WBS.

2.2.1 Developing and Documenting a Program WBS. The government program manager is responsible for maintaining the Program WBS as it develops through systems engineering and management planning processes. The WBS may span one or more of the categories or elements defined in Appendices A-K. While these elements normally provide a basis for the Program or Contract WBS, tailoring may occur when a unique requirement exists. As a result, most appendices contain WBS elements designated as “Other” at the subsystem, element (product) levels that are restricted for unique requirements (products) that have not been envisioned or do not exist within the defined WBS elements in the Appendices. When a unique requirement exists, the WBS element designated as “Other” should be used. If it is determined that the “other” element is needed, the element must be specified and defined and the word “Other” replaced by the newly defined WBS element. The newly defined element must be approved by the Government Program Manager and their representative contracting officer. If it is determined that the “other” WBS element is not needed, this element should be deleted and not used in the WBS. In addition, although each appendix relates to a specific category of defense items, any item from any appendix which is applicable to the program may be used, as long as the integrity of the level of placement is maintained.

The Program and Contract WBS should always represent the system that is being developed and/or procured. Hence the WBS should include only those WBS elements which are part of the logical decomposition of the system. Therefore, the WBS should not be expanded to include all elements identified in an appendix but should only include only those that truly represent the system being developed and/or procured.

The Program WBS will guide development early in the program’s life cycle. It will evolve through iterative analysis of the program objective, functional design criteria, program scope, technical performance requirements, and other technical documentation. The documentation will describe the entire plan to build, field, and support the system through fielding.

Ultimately, the Program WBS is approved through the CSDR plan, in accordance with DOD 5000.04-M-1 CSDR Manual. The CSDR plan describes the Program WBS to be used and defines the approach the Government activity plans to use for collecting cost data.

2.2.2 Selecting Program WBS Elements. The WBS provides a framework for specifying the program objectives by first defining the program in terms of hierarchically related, product-oriented elements and the work processes required for their completion. Each element of the WBS provides logical summary points for assessing technical accomplishments and for measuring the cost and schedule performance accomplished in attaining the specified technical performance. 2.2.3 Determining Levels of Program WBS. The levels of the Program WBS must be related to the system requirements and conform to the product-oriented family tree. The detailed technical objectives are defined, and the scope of work is determined for each WBS element. Then, tasks are assigned to each WBS element. Resources, materials, and processes required for attaining the objectives are added incrementally. This relationship allows all items to be traced to the same WBS elements. Thus, the linkage between the requirements specification, the WBS, the Statement of Work (SOW), the Integrated Master Schedule (IMS), and the Integrated Master Plan (IMP) provides specific insights into the relationship between cost, schedule, and performance.

By following the Acquisition Management Framework (see Figure 1), when developing a Program WBS, systems engineers define the description of the system and its related levels. Early in the Materiel Solution Analysis phase, systems engineering efforts transform operational needs to system performance parameters and configurations. For example, suppose the established need is to “Kill a Tank.” The objective is clear and achievable through numerous capabilities. Systems engineers perform tradeoffs, which ultimately define the preliminary system-level capabilities. In this case, the systems that will “Kill Tank” must be able to detect, maneuver, and shoot (see Figure 3). The Program WBS is not formed around these functional capabilities, but is developed out of the products that are expected to satisfy these requirements.

FIGURE 3. Capability Requirements in the Materiel Solution Analysis Phase

When the TD phase is initiated, the systems engineering development efforts will focus on technology requirements to meet system-level capabilities. Functional requirements are assigned under a system, all meeting the mission need of “Kill Tank.” If Government laboratories or in-house engineering support is accomplishing this work, a statement of work (SOW) may be prepared for a request for support in the TD phase. Otherwise, this may have already been accomplished at the end of Materiel Solution Analysis phase to obtain contractual support for the TD phase.

The TD phase should describe the system and the configuration items that make up the system. Once the system concept is determined, then major subsystems and configuration items can be identified and lower level functions defined, so that lower level system elements can be created. Again, these are not WBS elements since they do not reflect a product. As an example, using the AoA process determined that a fire control system of an aircraft would be the best solution to meet the user need. The fire control system is functionally able to detect, aim, track, and fire (see Figure 4).

FIGURE 4. Identification of Major Subsystems and Functional Requirements

The relationship of the functions shown in this example can now be translated into products that will meet the user’s requirement. The resulting Program WBS should be defined in accordance with Appendix A, Aircraft Systems WBS and Definitions.

The WBS now defines the solution to the problem in terms of a product. Figure 5 shows a simplified representation of the hierarchical relationship of the Aircraft System to the Fire Control Subsystem and to other elements. In practice, this WBS will be developed on the most refined technical representation of the end system available.

FIGURE 5. Program WBS Description

Since competitive prototyping is required to be accomplished in the TD phase, the TD units being developed and produced can be represented in the Program WBS. For ACAT I programs, the WBS should be approved by submitting a CSDR plan (as required by DoD Instruction 5000.02). The plan describes the Program WBS being used and defines the approach the Government activity plans to use for collecting cost data. After the Program WBS is approved by the Deputy Director, Cost Assessment within the Office of the Secretary of Defense (OSD) Cost Assessment and Performance Evaluation (CAPE), a request for proposals will be released with a proposed Contract WBS to each contractor developing prototypes. For all other ACAT programs, the designated Milestone Decision Authority will be the approving official.

Government and industry will work together during the TD phase to create an evolutionary acquisition strategy for rapid acquisition of mature technology for the user. An evolutionary approach delivers capability in militarily useful increments, recognizing, up front, the need for future capability improvements. This means that programs using an evolutionary acquisition strategy need to establish the approved program’s objective and threshold boundaries, and link among the cost, schedule, and performance parameters. The program manager (PM) manages the program within that trade space and the WBS is the key communication tool to support these requirements. The PM will use this information to develop an optimal product within the available trade space for each increment in the evolutionary process. As the TD phase ends and activities move into EMD, the best product that meets the cost, schedule, and performance parameters is defined to the level possible within the Government’s approved Program WBS. A contract is awarded to the contractor whose solution best meets user needs and cost, schedule, and performance criteria. The Contract WBS is extended to the desired level, reflecting those items considered high-cost, high-risk and/or high technical interest as well as how the program is planned and will be managed.

Entering EMD, two major efforts are accomplished: (1) an Integrated System Design (ISD) and (2) Post- CDR Assessment (see Figure 6). The ISD effort is intended to define system functionality and interfaces, complete hardware and software detailed design, and reduce system-level risk. It also includes the establishment of the product baseline for all configuration items. Therefore, the configuration of the entire system has been defined, the relationship between the Program WBS and the Contract WBS is developed at its lowest level, and management of the program is accomplished. Figure 7depicts a format suitable for documenting the subdivision of a program’s work breakdown structure into contract work breakdown structures for each contractor/source. In the example below, the program work breakdown structure Level 4 element, Fire Control becomes Level 1 of the contract work breakdown structure, and all other Level 2 common program work breakdown structure elements (reference Appendix L) are included at Level 2 of the contract work breakdown structure. A separate contract for a Level 4 program work breakdown structure element, such as Aircrew Training Device, also follows the same procedure. The same contract work breakdown structure drawn from the program work breakdown structure will be used for each phase (development and production) of a program. At this point, the WBS is linked to major products and systems and fully integrated with the contractor’s systems engineering, program management and financial functions. Figure 8 provides an example of a resulting system configuration, which reflects the Contract WBS to be delivered.

Engineering & Manufacturing

FIGURE 6. EMD Requirements

The Post-CDR Assessment effort is intended to demonstrate the system’s ability to operate, while still consistent with the approved Key Performance Parameters (KPPs), and that system production can be supported by demonstrated manufacturing processes. Effort ends when: (1) the system meets approved requirements and is demonstrated in its intended environment using the selected production-representative article, (2) manufacturing processes have been effectively demonstrated, (3) industrial capabilities are reasonably available, and (4) the system meets or exceeds exit criteria and Milestone C entrance requirements.

NOTES: 1. WBS LEVELS IN PARENTHESES INDICATE RELATIVITY TO PRIME MISSION SYSTEM (PMS).

FIGURE 7. Work Breakdown Structure Matrix (Contract WBS)

FIGURE 8. Example of System Configuration Documentation

During the Production and Deployment phase, the system is produced as defined in previous phases. The system’s engineering efforts are actively involved in maintaining control over the system configuration as it is produced. The WBS is defined to the level appropriate for contract management and maintenance. When major modifications occur, the same WBS can be tailored or, if the changes are substantial, a new WBS can be developed according to the same rules.

2.2.4 Creating the WBS Dictionary. As part of developing a Program WBS, the program manager will also develop a WBS dictionary. The dictionary lists and defines the WBS elements. Although initially prepared by the Government program manager, the contractor expands the dictionary as the Contract WBS is developed. The WBS dictionary will be developed starting with the generic definitions in this Standard, and made program-specific to define the products being acquired to support effective Program Management by the contractor and to meet essential Request for Proposal (RFP) requirements.

The dictionary shows the hierarchical relationship of the elements and describes each WBS element and the resources and processes required to produce it. It also provides basic technical characteristics for the WBS elements and provides a link to the detailed technical definition documents. The WBS dictionary is routinely revised to incorporate changes and must reflect the current status of the program throughout the program’s life.

2.2.5 Avoiding Pitfalls in Constructing a WBS. An effective WBS clearly describes what the program manager intends to acquire. It has a logical structure and is tailored to a particular defense materiel item. It serves as a common thread among the specifications, SOW, Contract Line Item Number (CLIN) structure, IMS, IMP, EVMS and Risk Management. Remember, the WBS is product-oriented; addressing the products required, not the functions or costs associated with those products. 2.2.5.1 Requirement for WBS Element Exclusions.

Only include elements that are products (hardware, software, services, data, and facilities). A signal processor, for example, is a product, as are mock-ups and Computer Software Configuration Items (CSCIs) or Software Configuration Items (SCIs). On the other hand, items like design engineering, requirements analysis, test engineering, aluminum stock, and direct costs are not products. Design engineering, test engineering, and requirements analysis are all engineering functional efforts; aluminum is a material resource and direct cost is an accounting classification. Thus, none of these elements are appropriate WBS elements.

Program acquisition phases (for example, EMD, Production and Deployment) and types of funds used in various phases (for example, Research, Development, Test and Evaluation) are inappropriate WBS elements.

Rework, retesting and refurbishing are not separate WBS elements. They should be treated as part of the appropriate WBS element affected.

Nonrecurring and recurring classifications are not WBS elements. The reporting requirements of the Contractor Cost Data Report (CCDR) will segregate each element into its recurring and nonrecurring parts. These efforts should be included in the cost of the item they affect, not captured separately.

Cost saving efforts, such as total quality management initiatives, acquisition reform initiatives, and warranty, etc. are not part of the WBS. These efforts should be included in the cost of the item they affect, not captured separately.

Do not use the organizational structure of the program office or the contractor’s organization as the basis of a WBS.

Generic terms are inappropriate in a WBS. The WBS elements must clearly indicate the actual system names and nomenclature of the product to avoid semantic confusion. For example, if the Level 1 system is Fire Control, then the Level 2 item (prime mission product) is Fire Control Radar.

Recurring units of the same end item. This is captured by a unit cost report, learning curve report or CLIN if required.

Tooling is not a WBS element. Tooling (e.g., special test equipment, automatic test equipment, and factory support equipment like assembly tools, dies, jigs, fixtures, master forms, and handling equipment) must be included in the functional cost, if possible, of the equipment being produced. If tooling is used for more than one component/subassembly, the percentage usage will be apportioned to the component/subassembly as appropriate. Programming costs for production automatic test equipment (ATE) must be included here. If the tooling cannot be assigned to an identified subsystem or component, it will be included in the cost of integration, assembly, test, and checkout.

2.2.5.2 Additional Considerations. Include software costs in the cost of the equipment. For example, when a software development facility is created to support the development of software, the effort associated with this element is considered part of the CSCI it supports or, if more than one CSCI is involved, the software effort should be included under integration, assembly, test, and checkout. Software developed to reside on specific equipment must be identified as a subset of that equipment.

Integration, assembly, test, and checkout includes production acceptance testing (including first article test) of Research and Development (R&D) and production units but excludes all systems engineering/program management and system test and evaluation that are associated with the overall system.

This Standard does not identify Level 3 elements for the systems engineering or program management WBS elements. This grants the program manager and contractor the flexibility to identify efforts that are important to the specific program. The definitions in Appendix L illustrate typical systems engineering and program management efforts.

System test and evaluation must always separately identify tests performed in the development of a system (e.g., Developmental Test and evaluation), and tests performed by the operational user (e.g., operational test and evaluation).

2.3 Solicitation and Proposal. The WBS used for a solicitation must be structured by selecting appropriate elements from the approved Program WBS. The CLINs, configuration items, contract SOW tasks, contract specifications, and contractor responses will be expressed in terms of the WBS to enhance its effectiveness in satisfying the objectives of the acquisition. The relationship of the Contract WBS elements to the SOW and the CLINs must be clearly traceable. A one-to-one relationship might not exist, nor is it required.

2.3.1 Contractor Management Control System. The Contract WBS will serve as the framework for the contractor’s management control system. That system will provide auditable and traceable summaries of internal data generated by its performance measurement procedures.

2.3.2 Acquisition Logistics. The acquisition logistics elements will be accommodated in the WBS that they support. These areas are included as part of other WBS elements and reflect the work that needs to be accomplished. For example, acquisition logistics management can be identified as part of the program management, and contractor logistics support would support site activation. Areas for consideration include: (1) acquisition logistics management and reporting, (2) contractor logistics support, (3) peculiar support equipment, (4) initial spares, support data, and training, and (5) transition to sustainment (Operations and Support (O&S) phase).

2.3.3 Planning, Programming, Budgeting, and Execution (PPBE) System. The Program WBS will be the basis for program element data to support the PPBE submittals.

2.3.4 Life-Cycle Cost. Life-cycle cost (LCC) is the total cost for the weapons or support for defense acquisition system research and development (R&D), investment, operation and support (O&S), and disposal. LCC commences at program initiation and ends with retirement or demilitarization and disposition of the system. The established WBS requirements in this standard are associated with those acquisition LCC phases of R&D and investment that are applicable to all contracted efforts.

2.3.5 Procurement. The following will be relatable to elements of the program work breakdown structure:
a. Structure of work statements
b. Contract work breakdown structures
c. Contract line items
d. Configuration items
e. Technical and management reports
f. Government-furnished items

2.3.6 Reporting. All program status reporting requirements will be consistent with the Program WBS.

2.4 Contract Statement of Work (SOW). A standardized WBS is an effective template for constructing the SOW for a system acquisition; it helps to streamline the process. The WBS structure provides a framework for defining program technical objectives. Together with the contract SOW, the WBS aids in establishing an indentured data listing (specification tree), defining configuration items, and planning support tasks. The SOW is the document that describes, in clear and understandable terms, what products are to be delivered or what services are to be performed by the contractor. Preparation of an effective SOW requires a thorough understanding of the products and services needed to satisfy a particular requirement. An explicitly written SOW facilitates effective contractor evaluation. After contract award, if the SOW is absorbed into the IMP, and if the associated tasks and schedule are absorbed into the IMS, the IMS and EVMS become better measures of contractor performance. The WBS also provides a logical arrangement of SOW elements, serving as a convenient checklist to ensure the contractor addresses all necessary program elements and meets specific contract reporting needs. 2.5 Request for Proposals (RFP).

2.5.1 Preparing a Preliminary Contract WBS. The DoD program manager will select the individual WBS elements from the Program WBS that apply to the contract to include in the RFP as described in Section 2.3. This is the first opportunity for open dialogue between the Government and potential contractors. Acquisition approaches (e.g., a Performance Based Acquisition strategy) need to be outlined in the RFP and be inclusive to how the Government will measure technical performance. Technical measures of performance can be allocated to WBS elements. Innovative ideas or promising alternative solutions should be considered for inclusion in the RFP. The RFP will include a Contract WBS and the initial WBS dictionary. The RFP will instruct potential contractors to extend the selected Contract WBS elements to define the complete contract scope, consistent with the contractor’s proposed approach for executing the program.

2.5.2 RFP Solicitation Requirements. CLINs, configuration items, contract work statement tasks, contract specifications, and contractor responses should relate to the WBS so as to enhance its effectiveness in fully describing acquisition objectives. It is important to coordinate the development of the Program WBS and the CSDR plan with the development of the SOW to ensure consistency in document structure. When aggregated with the Program WBS, the extended Contract WBS will form a complete Program WBS, thus providing a logical work flow throughout the acquisition cycle.

2.5.3 Extended Contract WBS. Contractors are expected to extend the Contract WBS to the appropriate lower level that satisfies critical visibility requirements and does not overburden the management control system. A preliminary government approved contract WBS should be included in the RFP and the contractor should provide comments on the adequacy of the CSDR contract plan WBS and submit revised WBS with their proposal if necessary. The proposal will be based on the WBS in the RFP, although contractors should be encouraged to suggest changes needed to meet an essential RFP requirement or to enhance the effectiveness of the Contract WBS in satisfying program objectives.

2.6 Integrated Cost, Schedule, and Technical Performance and Risk Management. Planning tasks by WBS elements serves as the basis for mapping the technical baseline, estimating and scheduling resource requirements, and mitigating risks. By breaking the system into successively smaller entities, program managers can ensure all required products and system components are identified in terms of cost, schedule, and performance goals in order to reduce risk.

Time phasing performance budgets, assigning them to work segments, and identifying responsible units produces a plan against which actual performance can be measured. Corrective action can be taken to resolve deviations from the plan. This integrated approach to work planning also simplifies identifying the potential cost and schedule impacts of proposed technical changes.

3. CONTRACTOR INSTRUCTIONS

3.1 Developing the Contract WBS. The Contract WBS provides the framework for the contractor’s management control system. It must be tailored to the program so that it does not unnecessarily constrain the contractor in meeting defined contract requirements.

3.1.1 Relationship of Program WBS to Contract WBS. The Program WBS captures all efforts of a program to include contract and government efforts. Program WBS elements that will be contracted are reflected in the Contract WBS. The contracted system therefore will be identified at Level 1 of the Contract WBS with all applicable Level 2 Common WBS elements included. Figure 9 depicts the development and relationship of the Program WBS with the Contract WBS. In this example, the Government activity is responsible for the FX Aircraft System reflected by the Program WBS. The Government activity has determined that it will award a contract for the Fire Control System, as reflected by the Contract WBS. Figure 9 identifies the propulsion system as GFE and therefore is captured in the Program WBS. Other Government efforts supporting the program as a whole, such as support from the Air Force Operational Test and Evaluation Center would also be captured in the Program WBS within the Operational Test and Evaluation efforts. Only contract efforts will be captured within the Contract WBS, while both the Government efforts and contract efforts will always be captured in the Program WBS.

FIGURE 9. Relationship of Program WBS to Contract WBS

3.1.2 Subcontractors. When a contract is awarded to a Prime contractor, the Prime will require subcontractors that meet reporting threshold requirements to use the WBS to fulfill contractual requirements and control the subcontracted effort. The Prime or associate contractor is responsible for incorporating WBS requirements into the subcontract. Using the example in Figure 9, the Fire Control System was awarded to a Prime contractor. The Prime has further determined that it requires the Antenna System to be subcontracted. Figure 10 shows how the Prime contractor further defined the Antenna System and created a subcontract WBS for the sub work to be managed. To summarize, the FX Aircraft System is represented by the “Program” WBS, which is used by the Government to manage the FX Aircraft System Program. The Government contracts with the Prime contractor for the Fire Control System and that effort is the Contract WBS for the Prime contractor (Figure 9). The Prime contractor then subcontracts the antenna of the Fire Control System and a WBS is created to support the Antenna System subcontracted efforts (Figure 10).

FIGURE 10. Relationship of Contract WBS to Subcontract WBS

3.1.3 Contractor’s Organizational Structure. A WBS must not be influenced by a contractor’s program organization. The contractor can organize according to corporate standards and still effectively use a valid, product- oriented WBS.

3.1.4 Control Account Level. To provide the responsible contract manager with technical, schedule, and other needed resource information, the management control system must be keyed to the same WBS element and organizational unit. The WBS level at which the management control system is established is primarily a function of the magnitude of the program and the type of product required by the contract. The responsible organizational level is a function of the company’s management span of control and upper management’s desire to delegate the responsibility for WBS elements to lower management levels. In identifying control accounts, the contractor is expected to establish organizational responsibilities at meaningful and appropriate levels. Otherwise, the contractor’s existing management control system and responsibility assignments may be affected adversely.

Virtually all aspects of the contractor’s management control system (i.e., technical definition, budgets, estimates, schedules, risk management, work assignments, accounting, progress assessment, problem identification, and corrective actions) come together at the control account level. Performance visibility is directly relatable to this level of detail.

As the end product is subdivided into smaller sub-products at lower WBS levels, the work effort required by each element should be identified and assigned to functional organizational units. The contractor will assign management responsibility for technical, schedule, and other performance criteria at lower levels within the WBS. The management control system will keep the lower levels of the WBS visible as it intersects with the organizational structure. At the juncture of the WBS element and organization unit, control accounts and work packages are established and performance is planned, measured, recorded, and controlled. To this end, the technical requirements for the work and work product must be specified; the work scheduled, budgeted, and performed; and attainment of specified technical requirements verified.

As Figure 11 illustrates, at some level in a contractor’s organization there is a point at which a control account is managed. Likewise, in any WBS the same point exists. Therefore, every part of a WBS is visible or accessible regardless of the contractor’s organization.

FIGURE 11. Translation from Function to Product

For example, the management information needed by the Government to manage the development of a radar receiver is available from the control accounts that are part of that effort’s WBS. The information the contractor needs to manage the development is available from the same control accounts, which in this example are a part of the contractor’s Electrical Design Department.

Figure 12 illustrates the same example but uses an Integrated Product Team (IPT)-structured organization and its interface with the Contract WBS.

FIGURE 12. IPT Intersection with Contract WBS

3.2 Programmatic Issues in WBS Development.

3.2.1 System of Systems (SoS). A program can either have stand-alone systems or have interfaces with other systems, such as a fighter aircraft that has interfaces with the ordnance it carries. The aircraft and ordnance programs, traditionally separate, will each have a separate Program WBS. In a SoS program, such as the Missile Defense Program or the Cheyenne Mountain Complex, the program is actually a collection of systems and thus the Program WBS at the first tier will consist of the various systems that make up the SoS structure. A SoS Program will require the development of multiple system WBS definitions, found in Appendices A through L. SoS should be treated and managed as a system in their own right, and should therefore be subject to the same systems engineering processes and best practices as applied to individual systems. In this manner, the WBS requirements of a system also apply to a SoS.

Understanding the parent-child type relationship of various related programs and contracts and their impact on the WBS is important in the ever-increasing integrated and joint program environment. Often, individually baselined programs and their various prime or GFE elements are actually part of a SoS approach. The overall parent program, the SoS or joint program, needs to be associated with the various child programs. Each child program would develop a stand-alone WBS structure. The various child WBS elements then would be identified at Level 2 or 3, as appropriate, in the overall parent program. In some cases, common systems will be a child program to different parent programs and may actually enter the parent WBS as a different level. In any case, the parent-child relationship should be thought through and understood by the parent program and the various child programs. The parent-child challenge will repeat itself in the Contract WBS as the Prime contractor decides to subcontract various portions of the system. Each substantial subcontract will in essence create a program for the subcontract and thus create a parent-child relationship between the Prime and the subcontractor.

3.2.2 Family of Systems. A family of systems is a grouping of systems having some common characteristic(s). For example, each system in a family of systems may belong to a domain or product line (e.g., a family of missiles, surface vehicles, aircraft, or situation awareness systems), each having a level of commonality and unique variants. In general, a family of systems is not considered to be a system per se because it does not necessarily create capability beyond the additive sum of the individual capabilities of its member systems. A family of systems lacks the synergy of a SoS. The family of systems does not acquire qualitatively new properties as a result of the grouping. In fact, the member systems may not be connected into a whole.

Developing a WBS for a program that has multiple variants and varying levels of commonality can result in a WBS that is very long. This result is realized when the WBS for a particular defense materiel item (e.g., aircraft, missile, surface vehicle, etc.) is replicated for each unique variant and the degree of commonality between each unique variant.

3.2.3 Intelligence Requirements and Related Costs. Intelligence (Intel) efforts (security, threat, mission data) are often considered late in the acquisition cycle, even after contract award. Identifying where Intel is needed reduces risk and affords a much better opportunity to manage cost, schedule, and performance. The WBS Standard portrays systems in a product-oriented WBS, identifying and considering potential intelligence information and costs using the existing component cost estimating processes.

3.2.4 Software and Software Intensive Systems. It is important to recognize the fundamental distinction between two types of software acquisition: 1) software embedded on a weapon system and 2) Automated Information Systems. Both of these are an increasingly important part of DoD acquisition, but affect the process in different ways and should therefore be treated differently from a WBS perspective.

3.2.4.1 Automated Information Systems (AIS). For AIS, the software is itself the end-item. Further, AIS are typically not production items. Rather, Milestone C reflects the point at which the developed system is deployed rather than produced. This results in a WBS that is of a much different nature for post-Milestone C effort than pre- Milestone C. An AIS will not likely be deployed according to the same WBS by which it was developed. For AISs such as business systems, Enterprise Resource Planning (ERP), and Service Oriented Architecture (SOA) use Appendix K.

3.2.4.2 Software Operating on Specific Equipment. Multi-function software will be identified as a subset of the equipment WBS element, which either includes the software in the element specification or exercises the most critical performance constraint. In cases where a conflict exists between selecting either the element specification or that which exercises the most critical performance constraint, selecting the specification relationship will take precedence. For example, an aircraft’s electronic equipment typically has software included in each of the subsystem elements. Software that resides and interfaces with more than one piece of equipment (for example, applications software and overall system software, which facilitates the Operations and Maintenance (O&M) of the computer systems and associated programs), will be called out at the appropriate work breakdown level. For example, elements of software development often are high technical risk and high cost. Since all critical system software should be identified, it may be appropriate to collect lower level information.

All integral software should be included in a Program or Contract WBS in conjunction with the hardware it supports. This allows for effective performance measurement and management control. When needed, a contractor’s management system can use an identifier for each software element to produce summaries for software management purposes. 3.2.4.3 Visibility into Software Development Processes. Because the WBS has a product-oriented hierarchy, its progressive subdivision will result in common management or functional tasks (for example, development processes, etc.) occurring in many WBS elements. Software may be widespread throughout the WBS and represent high risk in the contract. In such cases, the program manager should require specific visibility into software performance, but care must be taken to not overly complicate the Contract WBS and the contractor’s management system. Appropriate reporting requirements should be specified in the SOW.

As Figure 13 shows, the contractor’s management system and the WBS will provide critical detail and visibility of key software development processes (for example, requirements analysis, design, code and test, etc.) without extending the WBS to excessively low levels or developing a separate WBS for software. The required information can be aggregated for reporting as needed using the contractor’s management system.

FIGURE 13. Linkage Between Contractor WBS and Contractor Management Systems

3.2.5 Integrated Master Plan and Integrated Master Schedule (IMP/IMS)

3.2.5.1 Integrated Master Plan (IMP). The IMP is an event-based plan consisting of a hierarchy of program events, with each event being supported by specific accomplishments and each accomplishment associated with specific criteria to be satisfied for its completion. The IMP should provide sufficient definition to allow for the tracking of the completion of required accomplishments for each event and to demonstrate satisfaction of the completion criteria for each accomplishment. In addition, the IMP demonstrates the maturation of the design/development of the product as it progresses through a disciplined systems engineering process. IMP events are not tied to calendar dates; each event is completed when its supporting accomplishments are completed and when this is evidenced by the satisfaction of the criteria supporting each of those accomplishments. The IMP is placed on contract and becomes the baseline execution plan for the program/project. The IMP is a relatively top- level document in comparison to the IMS.

3.2.5.2 Integrated Master Schedule (IMS). The IMS flows directly from the IMP and supplements it with additional levels of detail. It incorporates all of the IMP’s events, accomplishments, and criteria; to these activities it adds the detailed tasks necessary to support the IMP criteria along with each task’s duration and its relationships with other tasks. The IMS supports multiple views (for example, event-based, WBS-based) to support the user’s needs. This network of integrated tasks, when tied to the start date (for example, contract award), creates the task- and calendar-based schedule that is the IMS. The IMS should be defined to the level of detail necessary for daily execution of the program/project.

3.2.5.3 IMP/IMS Linkage. The IMS is directly traceable back to the IMP and, where applicable, should also be traceable to the program’s Contract WBS, SOW, EVMS, and risk management system. Both the IMP and the IMS should be consistent with the contractor’s management and scheduling system structure and format. In general, the IMP can be thought of as the top-down planning tool and the IMS as the bottom-up execution tool for those plans. However, it should be noted that the primary purpose of the IMS is as a scheduling tool. It serves as a forecasting tool used to track technical performance and time phase the budget. Figure 14 illustrates these interrelationships.

• airframe, propulsion, 1110 Wing •

FIGURE 14. Relationship of IMP/IMS to WBS

3.2.6 Use of Common Elements. Common WBS elements (for example, Integration, Assembly, Test and Checkout; Systems Engineering; Program Management; System Test and Evaluation; Training; and Data (see Appendix L)) will be applied to the appropriate levels within the WBS they support. In other words, if systems engineering is required to support a Level 3 WBS element, the Systems Engineering WBS element would appear at Level 4 of the WBS under the Level 3 element it supports. For example, in Surface Vehicles common elements found at Level 2 of the WBS capture efforts associated with the “System” level as a total system (for example, training for the entire surface vehicle system). However, if training was required to support the Navigation and Remote Piloting System (Level 3 WBS element), the Training common element will also be associated with the element it supports (Navigation and Remote Piloting System) at Level 4 of the WBS. The training element should not be rolled into the “System” level training WBS element.

The intent is to understand the total effort associated with designing, developing, and producing a WBS element. Combining them into the “System” level misrepresents the true effort of delivering a complete Navigation and Remote Piloting System.

4. IMPLEMENTATION OF CONTRACT WORK BREAKDOWN STRUCTURE

The Contract Work Breakdown Structure (CWBS) included in a successful proposal serves as the basis for negotiating a Government-approved Contract WBS. The contractor may have proposed alternate approaches to accomplish the contract objectives. If the Government program manager accepts the alternatives, the Program WBS will require revision to reflect those changes. If changes are significant and broad in scope, the changes made should be evaluated at an Integrated Baseline Review (IBR).

4.1 Contract Award and Contract WBS Approval. The requirement for providing the WBS dictionary using Data Item Description DI-MGMT-81334 (current version), “Contract WBS” identified in the Contract Data Requirements List (CDRL) is included in the contract development process. Additional WBS revisions may result from program changes. Additional contract elements will become the basis for contractor extension of the Contract WBS. The extension of the Contractor WBS should be negotiated by the contractor and Government at a CSDR conference according to the CSDR Manual (DOD 5000.04-M-1). Although there is no limit on the number of additional elements, each should be justified in terms of its contribution to effective program management. All extensions should be incorporated into the Contract WBS reporting level in the contract.

Users of this Standard should understand that the sequence described in the preceding paragraphs may be repeated as the program evolves, contracts are awarded, and the work effort progresses through major program phases. Revisions to the WBS are an essential component of this process. Whenever the WBS is revised, traceability to the previous WBS needs to be maintained. Once work begins, WBS changes should be controlled to preserve the cost baseline. The Contract WBS requires a contract modification before approved changes can be incorporated.

4.2 Reporting Relationships. The contractor maintains the Contract WBS, including change traceability. In accordance with the contract terms, only changes approved by the contracting officer may be incorporated. The contract will indicate levels of the Contract WBS at which costs will be reported to the Government. The contractor should determine those extended Contract WBS levels that are used to trace the cost accumulations for cost control purposes. In the extensions, consideration should be given to the specific contractual, technical, and managerial requirements of the defense materiel item. The contractor has complete flexibility to extend the Contract WBS below the reporting requirement to reflect how work is to be accomplished, assuming the additional elements are meaningful product or management-oriented indentures of a higher level element. For reporting purposes, the WBS is required to be the same for CCDR, CPR, IMP, and IMS related reporting. While reporting levels may be different for each report, the WBS should be the same at the level for which it is reported. For example, when the WBS is reported at Level 4 for a CPR and IMP, and Level 5 or below for the CCDR and IMS, the WBS should be the same for the CPR, IMP, IMS, and CCDR through Level 4. Level 5 and below as reported on the CCDR and IMS should maintain a product-oriented logical decomposition of those Level 4 WBS elements that are extended.

4.3 Numbering of the WBS. In each appendix, the work breakdown structure for that commodity has been numbered for reporting purposes only. The purpose for the numbering is to provide a consistent approach to identifying and managing the WBS across like systems regardless of vendor or service. The numbering system is numeric; however, several unique issues arise across appendices which require the numbering system to be modified to accommodate the anomalies.

4.3.1. “Other” WBS Elements. All appendices contain a WBS element titled as “Other” at the subsystem, element (product) levels that are restricted for products that have not been envisioned or predicted within the defined WBS elements in the Appendix. If it is determined that the “other” WBS is not needed, this element and assigned WBS number should be deleted and not used in the WBS. If it is determined that the “other” element is needed, then each element must be defined and the word “other” replaced by the newly defined WBS element using the assigned WBS number from the appropriate appendix. The newly defined element must be approved by the Government Program Manager and the representative contracting officer. 4.3.2 (1…n) WBS Element Definitions. Several appendices identify WBS elements with (1…n) or similar to denote that one or more of that type of item may be used. Where this structure occurs, the parent WBS (e.g., 1…n) shall be decomposed to the next level and then each child WBS use the appropriate WBS title for each element as well as the WBS numbering identification. For example, if a missile system has multiple propulsion subsystems, each Propulsion Subsystem (1…n) shall have a WBS name designation (for example, “Solid Rocket Motor”), and the element Propulsion Subsystem 1 would be at the child level of the parent WBS element (Propulsion Subsystem 1…n) as would Propulsion Subsystem 2 (for example, “Liquid Rocket Engine”), and so forth. Each WBS should be detailed down to the element’s lower level (as defined in the appendices) whenever possible, and assigned the next available WBS number in sequence according to the parent child relationship as shown below.

1.1.2. Propulsion Subsystem (1…n)
1.1.2.1. Solid Rocket Motor
1.1.2.2. Liquid Rocket Engine
1.1.2.3. Backup Rocket Motor

4.4 Support for Management Activities. Within the scope of the WBS, the contractor has flexibility to use the work breakdown elements to support ongoing financial management activities. These may include EVM, cost estimating, and managing contract funds (see Figure 15).

FutureYears

FIGURE 15. The WBS is the Basis for DoD Reporting Requirements

4.4.1 Earned Value Management (EVM). Cost performance measurement involves periodic comparison of actual costs with time-phased budgets, analysis of performance variances, and follow-up corrective action. When planned tasks are captured in a WBS element structure and time-phased as they are expected to be accomplished, the budgets associated with those tasks become the performance measurement baseline for EVM. EVM is a key integrated program management process in the management and oversight of Major Defense Acquisition Programs (MDAPs) and Major Automated Information Systems (MAIS) Programs.

EVM data is reported using the Contract Performance Report (CPR). The CPR provides contract cost and schedule performance data that is used to identify problems early in the contract and forecast future contract performance. The CPR is the primary means of documenting the ongoing communication between the contractor and the program manager to report cost and schedule trends to date and to permit assessment of their effect on future performance. This report consists of the following five formats: (1) WBS, (2) Organizational Categories, (3) Baseline, (4) Staffing, and (5) Explanation and Problem Analyses. Format 1 provides data to measure cost and schedule performance by product-oriented Contract WBS elements for the hardware, software, data, and services the Government purchases.

4.4.2 Cost Estimating. Use of the WBS for cost estimating facilitates program and contract management aids the program office in planning, coordinating, controlling, and estimating the various program activities. It provides a common framework for tracking the estimated and actual costs during the performance of each contract. The data from the various program contracts support the DoD program manager in evaluating contractor performance, preparing budgets, and preparing program life-cycle costs.

The WBS also provides critical structure for cost reporting. The DOD 5000.04-M-1, CSDR Manual, relies upon the WBS to enable effective reporting of cost and software data on MDAPs. The requirements for cost reporting provided in this Standard are mandatory for all contracts within ACAT I programs regardless of contract type. Consequently, the guidelines for WBS construction specified in this Standard become directive in nature. This Standard also provides guidance for mandatory software reporting on ACAT I programs with significant software development content. Detailed guidelines for the Contract WBS are provided in Data Item Description DI- MGMT-81334C. This data item is invoked in the CDRL of the RFP and contract.

Cost estimating data is reported through the CCDR. The purpose of the CCDR is to collect historical program cost data in a joint service environment and use that data to estimate the cost of ongoing and future Government programs. The WBS, as the cornerstone of the cost estimating process, provides a logical breakdown of tasking necessary to accomplish program objectives. The WBS for ACAT I programs is approved using the CSDR Plan and data reporting uses the following CCDR reports based on the WBS: Cost Data Summary Report, Functional Cost-Hour Report, and Progress Curve Report, and a Software Resource Data Report.

4.4.3 Contract Funds Status. The purpose of the Contract Funds Status Report (CFSR) is to supply funding data by Line Item/WBS to the DoD program manager and the Contracting Officer’s Technical Representative (COTR) for: 1) updating and forecasting contract funding requirements, 2) planning and decision making on funding changes in contracts, 3) developing funding requirements and budget estimates in support of approved contracts, 4) determining funds in excess of contract needs and available for deobligations, and 5) obtaining rough estimates of termination costs.

4.5 Summary. After contract award, at each point in the acquisition cycle, the Contract WBS continues to provide the framework for delineating the areas of responsibility and defining task requirements of the contract. The need for consistent program data must be satisfied in any further decomposition of the product-oriented Contract WBS developed by the contractor and should meet DoD needs for reasonably consistent program data. The Contract WBS format should be used as a starting point for continued tailoring. However, the same WBS will be utilized for the IMP, IMS, CPR, and CCDR as applicable.

5. NOTES SECTION

5.1 Intended Use. This Standard is directed primarily at preparing a WBS for a defense system program. This includes all systems, materiel items, or major modifications established as an integral program element of the Future Years Defense Program or otherwise designated by the DoD component or the Under Secretary of Defense (AT&L).

The Standard is appropriate for use with any WBS developed for the Pre-Systems Acquisition (Materiel Solution Analysis, Technology Development) and Systems Acquisition (engineering and Manufacturing Development, Production and Deployment) life cycle phases. The Sustainment Phase (Operations and Support) is addressed only as it is included during the Systems Acquisition Phase. The Standard focuses on identifying how a WBS is developed and maintained throughout the Pre-Systems Acquisition and Systems Acquisition phases.

This Standard clearly delineates the overlapping responsibilities of DoD program managers and contractors relative to the execution of WBSs.

5.2 Associated Data Item Description

DID NUMBER DID TITLE

DI-MGMT-81334 (Current Version) Contract Work Breakdown Structure

5.3 Supersession Data. This Standard supersedes MIL-HDBK-881A dated 30 July 2005 and MIL-STD- 881B dated 25 March 1993.

5.4 Subject Term (keyword) Listing. Aircraft Systems Automated Information Systems (AIS) Contract Funds Status Report (CFSR) Contract Work Breakdown Structure (WBS) Contractor Cost and Software Data Reporting (CSDR) Contract Performance Report (CPR) Control Accounts Cost Estimating Reporting Earned Value Management (EVM) Electronic Systems Engineering Data Integrated Master Plan (IMP) Integrated Master Schedule (IMS) Launch Vehicle Systems Life Cycle Cost Missile Systems Ordnance Systems Planning, Programming, Budgeting, and Execution (PPBE) System Program Management Program WBS Request for Proposals (RFP) Risk Management Schedule Sea Systems Software Space Systems Surface Vehicle Systems Systems Engineering System of Systems (SoS) Unmanned Air Vehicle (UAV) Systems Unmanned Maritime System (UMS) Work Package

5.5 Changes from Previous Issue. Marginal notations are not used in this revision to identify changes with respect to the previous issue due to the extent of the changes.

NOT MEASUREMENT SENSITIVE

DEPARTMENT OF DEFENSE STANDARD PRACTICE

WORK BREAKDOWN STRUCTURES FOR DEFENSE MATERIEL ITEMS

Contents

1. GENERAL INFORMATION

2. GOVERNMENT PROGRAM MANAGEMENT INSTRUCTIONS

3. CONTRACTOR INSTRUCTIONS

4. IMPLEMENTATION OF CONTRACT WORK BREAKDOWN STRUCTURE

5. NOTES SECTION

1. GENERAL INFORMATION

2. GOVERNMENT PROGRAM MANAGEMENT INSTRUCTIONS

NOTES: 1. WBS LEVELS IN PARENTHESES INDICATE RELATIVITY TO PRIME MISSION SYSTEM (PMS).

3. CONTRACTOR INSTRUCTIONS

4. IMPLEMENTATION OF CONTRACT WORK BREAKDOWN STRUCTURE

5. NOTES SECTION

DID NUMBER DID TITLE