B08 - Attachment 4 - MIL-STD-881F.pdf

MIL-STD-881F

13 May 2022

SUPERSEDING

MIL-STD-881E

6 October 2020

DEPARTMENT OF DEFENSE

STANDARD PRACTICE

WORK BREAKDOWN STRUCTURES

FOR DEFENSE MATERIEL ITEMS

AMSC 10316 AREA MISC

NOT MEASUREMENT

SENSITIVE

Source: http://assist.dla.mil -- Downloaded: 2024-07-12T17:41Z Check the source to verify that this is the current version before use.

(THIS PAGE LEFT INTENTIONALLY BLANK)

i

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 Operation of the Adaptive Acquisition Framework dated

January 23, 2020. This Standard supersedes MIL-STD-881E, dated 6 October

2020, titled Work Breakdown Structures for Defense Materiel Items. MIL-STD

881F is based on the cooperative efforts of the military services with assistance from industrial associations.

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 designated by (b) Defense Acquisition Executive or

Component Acquisition Executive or otherwise designated by the (c) Under

Secretary of Defense (Acquisition and Sustainment). This Standard is mandatory for all Acquisition Category (ACAT) programs. The most significant changes for this revision are the following:

a. Appendix L - Converted from an “information only” appendix which identified the relationship between MIL-STD-881E Work Breakdown Structures and the

Sustainment Cost Estimating Structure to a formal appendix which describes the process to report sustainment costs using the Cost Assessment and Program

Evaluation (CAPE) Sustainment Cost Estimating Structure (CES) for sustainment efforts.

b. Appendix K - Common Elements are only applicable for Appendices A through J and are not applicable for Appendices L or M.

4. A Work Breakdown Structure (WBS) provides a consistent and visible framework for defense materiel items and contracts which include Memorandums of

Agreement (MOA), Military Interdepartmental Purchase Requests (MIPR) and other Government and industry agreements completed to accomplish a program.

5. 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 and supporting Government entities in extending their contract (industry or Government entity executing an agreement equivalent to a contract) and Program (Government) work breakdown structures.

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 Principal Deputy Assistant Secretary of Defense, Acquisition

Enablers, Attention: Office of Acquisition Data and Analytics, 3620 Defense

Pentagon, Room 5A1066, Washington, DC 20301. Since contact information can change it may be necessary to verify the currency of this address information using the ASSIST online database at https://assist.dla.mil.

Source: http://assist.dla.mil -- Downloaded: 2024-07-12T17:41Z https://assist.dla.mil/ ii iii

CONTENTS

PARAGRAPH PAGE

FOREWORD ................................................................................................................................................................... i

1. GENERAL INFORMATION

1.1 Standard Purpose and Structure

1.2 Support Documentation

1.3 What Does a WBS Accomplish?

1.3.1 Applications

1.3.2 Benefits

1.3.3 Challenges

1.4 How is the WBS Related to Other Contract Requirements?

1.5 Definitions

1.5.1 Program Element (PE)

1.5.2 Defense Materiel Item

1.5.3 Work Breakdown Structure (WBS)

1.5.4 Common Elements

1.5.5 Additional Appendices

1.5.6 Level Identification…………………………………………………………………………………………….7

1.5.7 Program WBS

1.5.8 Contract WBS

1.5.9 Subcontract WBS

1.6 WBS Evolution

2. GOVERNMENT PROGRAM MANAGEMENT INSTRUCTIONS

2.1 Program WBS Attributes

2.2 Preparing a Program WBS

2.2.1 Developing and Documenting a Program WBS

2.2.2 Selecting Program WBS Elements

2.2.3 Determining Levels of Program WBS

2.2.4 Creating the WBS Dictionary

2.2.5 Avoiding Pitfalls in Constructing a WBS

2.2.5.1 Requirement for WBS Element Exclusions

2.2.5.2 Additional Considerations

2.3 Solicitation and Proposal

2.3.1 Contractor Management Control System

2.3.2 Acquisition Logistics

2.3.3 Planning, Programming, Budgeting, and Execution (PPBE) System

2.3.4 Life Cycle Cost

2.3.5 Procurement

2.3.6 Reporting

2.4 Contract Statement of Work (SOW)

iv

PARAGRAPH PAGE

2.5 Request for Proposals (RFP)

2.5.1 Preparing a Preliminary Contract WBS

2.5.2 RFP Solicitation Requirements

2.5.3 Extended Contract WBS

2.6 Integrated Cost, Schedule, Technical Performance, and Risk Management

3. CONTRACTOR INSTRUCTIONS

3.1 Developing the Contract WBS

3.1.1 Relationship of Program WBS to Contract WBS

3.1.2 Subcontractors

3.1.3 Contractor’s Organizational Structure

3.1.4 Control Account Level

3.2 Programmatic Issues in WBS Development

3.2.1 System of Systems (SoS)

3.2.2 Family of Systems

3.2.3 Cybersecurity

3.2.4 Software and Software Intensive Systems

3.2.4.1 Information Systems (IS)/Defense Business Systems (DBS)

3.2.4.2 Software Operating on Specific Equipment

3.2.4.3 Visibility into Software Development Processes

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

3.2.5.1 Integrated Master Plan (IMP)

3.2.5.2 Integrated Master Schedule (IMS)

3.2.5.3 IMP/IMS Linkage

3.2.6 Use of Common Elements

4. IMPLEMENTATION OF CONTRACT WORK BREAKDOWN STRUCTURE

4.1 Contract Award and Contract WBS Approval

4.2 Reporting Relationships

4.3 Numbering of the WBS

4.3.1 “Other” WBS Elements

4.3.2 (1...n) WBS Element Definitions

4.4 Support for Management and Reporting Activities

5. NOTES SECTION

5.1 Intended Use

5.2 Associated Data Item Descriptions

5.3 Supersession Data

5.4 Subject Term (keyword) Listing

5.5 Changes from Previous Issue

CONCLUDING MATERIAL

v

FIGURES PAGE

FIGURE I. Adaptive Acquisition Framework…………………………………………………………………………………...2 FIGURE II. “Major Capability” Acquisition System Development Lifecycle…...………………………………………….….8 FIGURE III. WBS evolution…………………………………………………………………………………………………….9 FIGURE IV. Identification of major subsystems and functional requirements……………………………………………… 11 FIGURE V. Program WBS description………………………………………………………………………………………...12 FIGURE VI. Work Breakdown Structure Matrix (contract WBS)……………………………………………………………. 13 FIGURE VII. Relationship of program WBS to contract WBS…………………………………………………………… FIGURE VIII. Relationship of contract WBS to subcontract WBS……………………………………………………………18 FIGURE IX. Translation from organizational to product………………………………………………………………………19 FIGURE X. Relationship of IMP/IMS to WBS. ……………………………………………………………....……………… 21 FIGURE XI. Examples of 1…n (Specify) as applied to a contract WBS…………………………………………………….. 23

FIGURE XII. Cybersecurity Test and Evaluation by phase requirements……………………………………………………198

APPENDICES PAGE

APPENDIX A: AIRCRAFT SYSTEMS

APPENDIX B: ELECTRONICS/AVIONICS/GENERIC SYSTEMS

APPENDIX C: MISSILE/ORDNANCE SYSTEMS

APPENDIX D: STRATEGIC MISSILE SYSTEMS

APPENDIX E: SEA SYSTEMS

APPENDIX F: SPACE SYSTEMS

APPENDIX G: GROUND VEHICLE SYSTEMS

APPENDIX H: UNMANNED MARITIME SYSTEMS

APPENDIX I: LAUNCH VEHICLE SYSTEMS

APPENDIX J: INFORMATION SYSTEMS/DEFENSE BUSINESS SYSTEMS

APPENDIX K: COMMON ELEMENTS

APPENDIX L: SUSTAINMENT

APPENDIX M: GOVERNMENT SYSTEM TEST AND EVALUATION

Source: http://assist.dla.mil -- Downloaded: 2024-07-12T17:41Z file:///C:/Users/nfalb/Dropbox/My%20Documents/MILSTD881%20Update/RAH%20CMO%20T&E/Update%20MIL%20STD%20881E/MIL-STD-881D_FINAL_RELEASE_20180409_Plan%20to%20Rev%20E_07_08_2020%20v11.1.docx%23_Toc45809336 vi

GENERAL INFORMATION

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 to defense contractors in their application and extension of the Program and contract WBS to report additional details associated with their agreements with

Government Program Managers. 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 (i.e., before a contract or Government performed effort has begun). 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.

Throughout this standard, the word “contract” and “defense contractor” is used to refer to both literal contracts with private industry, and to agreements between a Program Office, the awardee, and other Government organizations (e.g., test sites, depots, labs, Federally Funded Research and Development Centers [FFRDC]). This

Standard also provides WBS definitions for specific defense materiel commodity systems in Appendices A through J. Appendix K addresses WBS elements that are common to all commodities (Appendices A-J) prior to

Operations and Support activities, as well as those which use unique elements (e.g., Space Systems, Information

Systems/Defense Business Systems, Launch Systems, and Strategic Missile Systems).

Appendix L, in this version of the MIL-STD, no longer contains an overview of the relationship between the WBS and the Cost Assessment and Program Evaluation (CAPE) Cost Estimating Structure (CES). Instead, Appendix L now provides a set of definitions for all sustainment elements appropriate for inclusion in program and/or contract efforts. This is due to the unique circumstances and content of efforts within the Operations and

Support (O&S) phase, which is structured differently than the traditional acquisition-oriented, commodity-based structures in Appendices A-J.

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 were 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 “The

Defense Acquisition System” and DOD Instruction 5000.02, “Operation of the Adaptive Acquisition Framework.”

Figure I shows the Adaptive Acquisition Framework.

DoD Directive 5000.01 supports the National Defense Strategy through the development of a more lethal force based on U.S. technological innovation and a culture of performance that yields a decisive and sustained US military advantage. The acquisition system will be designed to acquire products and services that satisfy user needs with measurable and timely improvements to mission capability, materiel readiness, and operational support, at a fair and reasonable price. It 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.”

Preparing a WBS is generally discussed in the context of planning and monitoring a defense system program.

The WBS is a critical tool in ensuring all portions of the program are covered. The WBS also facilitates 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.

FIGURE I. Adaptive Acquisition Framework

DoD Instruction 5000.02 “Operation of the Adaptive Acquisition Framework” 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 break down the system into a product-oriented structure that can be used to track system design over time and between specific increments of system development. The instruction sets the requirements for Integrated Master Schedules (IMS), EVM Integrated Program Management Data and Analysis

Report (IPMDAR), Cost and Software Data Reporting (CSDR) 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 ACAT programs. Guidelines for the SEP are included in the SEP Annotated Outline (current version).

The WBS is also the basis by which actual and forecasted costs are collected on contracts pursuant to the

Cost Analysis Guidance and Procedures (DoDI 5000.73) and the Cost and Software Data Manual (DoDM 5000.04).

In addition, the purpose of the Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 5123.01H (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 support 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. Finally, 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 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 Government 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 Program WBS defines the entire program in terms of hierarchically-related, product-oriented elements and includes, for example, Program Office

Operations, Government System Engineering, Manpower, Government Furnished Equipment (GFE), and

Government Testing (i.e., System Test and Evaluation – as defined in Appendix M). It represents the entire program ranging from the Government Program Manager’s responsibilities to those elements of program that the contractor is made responsible to execute in support of the Program Manager via contract awards. There is only one Program

WBS.

The Contract (and Subcontract) 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 to execute in support of the Program Manager. It includes the contractor’s discretionary extension of the WBS to lower levels, in accordance with Government concurrence, and as required by the contract

Statement of Work (SOW) or Performance Work Statement (PWS). Depending on the program, there may be multiple Contract WBSs if there is more than one prime contractor or contract.

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 reporting level 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, high-risk, highly technical, and/or special interest, the system may be defined to a lower level of the WBS for those elements; 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 they are planning to develop, produce, and manage the system.

A secondary, but still important goal, is that 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 status of the individual elements. When appropriately structured and used in conjunction with systems engineering principles, cost estimating, EVM IPMDAR, CSDR, 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 M.

a. Aircraft Systems

b. Electronic/Avionics/Generic Systems

c. Missile/Ordnance Systems

d. Strategic Missile Systems

e. Sea Systems

f. Space Systems

g. Ground Vehicle Systems

h. Unmanned Maritime Systems

i. Launch Vehicle Systems

j. Information Systems/Defense Business Systems

k. Common Elements

l. Sustainment

m. Government System Test and Evaluation

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

a. Decomposes 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 identify the item requirements and their relationship to the WBS.

e. Provides a common thread for the Earned Value Management System (EVMS), the Integrated Master

Plan (IMP), the Integrated Master Schedule (IMS), IPMDAR, and CSDR allowing consistency in understanding program cost and schedule performance.

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 program reporting requirements. A WBS should be sufficient to provide necessary program insights for effective status reporting and risk mitigation, facilitating the Program Manager’s ability to effectively manage the program and the contractor’s ability to effectively complete its contacts.

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 valuable resource. The information gathered is critical to understanding the cost drivers and risk impact on future systems. However, the primary purpose of the WBS is to define the program’s structure based on the scope of work, while providing the contractor the ability to plan, establish, and manage the contract for which they are responsible.

The need for data should be balanced and not distort or hinder the ability for the contractor to perform their responsibilities when executing the contact.

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, integrating planning, scheduling, cost estimating, cost reporting, budgeting, contracting, configuration management, performance reporting disciplines, and others. It permits the Government and reporting entity program managers to continually evaluate progress in terms of contract performance.

The WBS forms the basis of reporting structures used for contracts requiring compliance with EIA-748 EVMS

Guidelines (current version) and reports placed on contract such as the Cost and Software Data Reporting (CSDR), Integrated Program Management Data and Analysis Report (IPMDAR) and its legacy formats, the Integrated Program

Management Report (IPMR) and the Contract Performance Report (CPR).

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 pre-acquisition and acquisition of a defense materiel item.

b. A WBS displays and defines the product, or products, to be developed and/or produced, or the services to be provided. 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 break down a product into sub-products at lower levels of detail.

c. A WBS can be expressed to any level of detail. The reporting level on any program or contract will be coordinated between the Government and the contractor or other reporting entity (e.g., awardee, test site, depot, laboratory, FFRDC). For effective management of complex programs, it may require the

WBS definition to go to lower levels. This is particularly true of items identified as high-cost, high-risk, high technical, and/or special interest. Under these circumstances, it is critical to define the product at the WBS level where this potential element appears. However, 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 for 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 included in Appendices A-J. These common elements are defined in further detail in Appendix K.3:

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/Site Activation

j. Industrial Facilities

k. Initial Spares and Repair Parts

Appendix K.4 to K.7 also contain common elements for unique application of the following:

a. K.4 Space Systems: those common elements that are not defined in K.3, and are unique to Space Systems,

b. K.5 Launch Vehicle Systems: those common elements that are not defined in K.3, and are unique to

Launch Vehicle Systems,

c. K.6 Information Systems/Defense Business Systems: those common elements that are not defined in K.3, and are unique to Information Systems/Defense Business Systems,

d. K.7 Strategic Missile Systems: those common elements that are not defined in K.3, and are unique to

Strategic Missile Systems.

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 or unmanned air vehicles designed for powered or unpowered (for example, a glider) guided flight

b. Electronic/Avionics/Generic System – Applies to electronic system capability (for example, processor, radio, electronic warfare, radar, etc.). This appendix also serves as a generic structure to use for any system or subsystem which is stand-alone or does not appear in the MIL-STD.

c. Missile/Ordnance System – Applies to a tactical missile or munition (nuclear, biological, chemical, psychological, and pyrotechnic) in an operational endo-atmospheric environment, which produces a destructive effect on selected targets and the means of launching or firing them.

d. Strategic Missile System – Applies to a missile which is capable of completing exo-atmospheric missions and is launched with the objective of delivering one or more warheads to a predetermined target, providing an orbital defense layer against hostile ballistic missiles, or may be used as an interceptor (i.e., kill vehicle) to disable or destroy a target.

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

f. Space System – Applies to unmanned Earth orbiting space vehicles (satellites) which have specific orbital placement parameters and operation.

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

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

i. Launch Vehicle System – Applies to development, delivery, and maintenance of launch vehicles or carrier rockets used to carry a payload from Earth’s surface into outer space.

j. Information System/Defense Business System – Applies to development, delivery, and maintenance of 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 are Enterprise Resource Planning systems (ERPs), Management Information

Systems (MIS), business systems, networks, or other electronic information handling systems, and associated equipment.

1.5.5 Additional Appendices. Two additional appendices are included in the MIL-STD-881F- Appendix L and Appendix M.

a. Sustainment (Appendix L) - Discusses the Cost Assessment and Program Evaluation (CAPE) Cost

Estimating Structure (CES) and its sustainment definitions, found in the CAPE Operating and Support

(O&S) Cost Estimating Structure Guide. Sustainment cost reporting is required using the Cost and

Software Data Reporting process based on the reporting requirements defined in the Cost and Software

Data Reporting Plan (DD Form 2794). DoDI 5000.73 establishes the policy, assigns responsibilities, and provides procedures for the conduct of cost estimation and analysis in the DoD, and DoDM

5000.04 provides guidance for the collection of data via Cost and Software Data Reports.

b. Government Test and Evaluation (Appendix M) - Provides the definitions for Government System

Test and Evaluation (ST&E) WBS elements, which are unique to the Defense Materiel Items defined in

Appendices A-J. All elements are specific to ST&E efforts. The purpose for these definitions is to support the Government in identifying, collecting, and reporting costs associated with Government ST&E actions and activities.

1.5.6 Level of Identification.

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 evaluation, program management and data).

c. Level 3 elements are subordinate to Level 2 major elements and include hardware, software, and services. For example, avionics, vehicle subsystems, or the Developmental Test and Evaluation

(DT&E) subordinate element of System Test and Evaluation, or equipment for instruction in Training.

d. Level 4 and 5 elements follow the same process of breakdown and are 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 to the lowest level consumable part or component as defined in the Level of Repair Analysis (LORA).

1.5.7 Program WBS. The Program WBS encompasses the entire program, including the Contract(s) WBS and the Government’s Program WBS elements (i.e., Program Office Operations, Manpower, Government Furnished

Equipment (GFE), Government Testing, etc.). It defines, at a high level, what is to be developed, procured, and sustained.

The Program WBS is used by the Government Program Manager and contractor to be extended into the Contract WBS.

It contains uniform terminology, definitions, and placement in the product-oriented family tree structure. For reporting purposes, the Program WBS serves as a consolidation mechanism for multiple subordinate contracts. This MIL-STD does not fully define a DoD Program WBS since “other Government” elements are not defined in this document.

However, Appendix M is included for the purpose of the Government Program Management Office (PMO) to identify, collect and report Government ST&E costs. The appendix contains the WBS and related definitions for Government’s

PMO efforts in supporting their ST&E activities (i.e., Developmental Test and Evaluation, Operational Test and

Evaluation, and Live Fire Test and Evaluation).

1.5.8 Contract WBS. The Contract WBS encompasses the contract deliverable WBS elements which the

Government awards to a contractor (which may include industry defense contractors, awardees, or Government entities).

It includes a complete WBS, extended to the agreed-to contract reporting level and any extensions to lower levels for reporting, which are considered high-cost, high-risk, highly technical, and/or special 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. The intent is to allow the contractor to define and manage the program elements as they see fit, for it is the comprehensive Contract WBS which forms the framework for the contractor’s management control system.

1.5.9 Subcontract WBS. The Subcontract WBS is a 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, highly technical, and/or special 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. The prime contractor should report the subcontractor costs in summary against the applicable

Contract WBS.

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 II provides an illustration of a Weapon System

Development Life Cycle.

FIGURE II. “Major Capability” Acquisition System Development Lifecycle

For example, the Major Capability Acquisition model will be used as an example of the application of the

WBS. 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 a high technology type aircraft, with 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 Maturation and Risk Reduction phase

(TMRR), the Program WBS provides the basis for the system to be broken into its component parts and support the definition of a potential Contract WBS. The purpose of the TMRR phase is to reduce technical 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 TMRR phase should have a well-

- Derived from DODI 5000.2T and DODI 5000.85 Major Capability Acquisition 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. Prior to contract award the Program WBS and draft Contract WBS(s) are 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. After contract award any change to the Contract WBS must be approved through a contract change. When integrated with the Program WBS, the extended Contract WBS forms a complete

WBS, which will be used throughout the contracts execution. Figure III below displays the 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 or a capabilities structure

—which provides the complete definition of the work to be performed by all participants and the required interfaces between them.

FIGURE III. WBS evolution

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-J. 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. 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 its relative level of placement and element definition is maintained. The Program and Contract WBS should always represent the system that is being developed, procured and/or sustained.

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. The approved Program WBS defines the approach the Government activity plans to manage, develop, produce, and deploy the system and ensure the program is properly executed. It should also include such elements as may be necessary to operate, sustain, maintain, and dispose of the system at the end of its life.

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 SOW or PWS, the Integrated Master Plan (IMP), and the Integrated Master Schedule (IMS) provides specific insights into the relationship between cost, schedule, and performance.

By following the Major Capability Acquisition Development Life Cycle (see Figure II), 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 “Destroy 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 “Destroy the Tank” must be able to detect, maneuver, and shoot. The Program WBS is not formed around these functional capabilities but is developed out of the products that are expected to satisfy these requirements.

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

The TMRR 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. As an example, using the AoA process it was 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 IV). Again, these are not WBS elements since they do not reflect a product.

TECHNOLOGY MATURATION/RISK REDUCTION

FIGURE IV. 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 V 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.

Since competitive prototyping is required to be accomplished in the TMRR phase, the TMRR units being developed and produced can be represented in the Program WBS. After appropriate approval to move forward, a request for proposals will be released with a proposed Contract WBS to each contractor developing prototypes.

Government and industry will work together during the TMRR phase to create an acquisition strategy for acquiring the technology required. 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 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 TMRR 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, highly technical, and/or special interest as well as how the program is planned and will be managed.

FIGURE V. Program WBS description

Entering EMD, the 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 VI depicts 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 K) 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.

During the Production and Deployment phase, the system is produced as defined in previous phases. The systems 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.

FIGURE VI. Work Breakdown Structure Matrix (contract WBS)

Sustainment has become a critical part of the acquisition life-cycle (specifically EMD, Production and

Deployment) due to technology advancements, a greater use of software, and quicker deployment of capabilities.

The timeframe to acquire defense materiel items has changed dramatically. With new development techniques, often requiring multiple builds over numerous contract increments, the warfighter is now getting capability faster than ever. This means that sustainment activities start earlier than they have in the past and continue into the Operations and Support (O&S) phase. The overlap between EMD and the Production and Deployment phases with the sustainment activities means both phases may be accomplished in parallel. Therefore, sustainment will be a consideration of the acquisition life-cycle even before the O&S phase has started. Appendix L of this Standard provides the basis for capturing the wide array of sustainment type activities and costs. Those looking for more detail, are referred to the OSD CAPE Operating and Support Cost-Estimating Guide, which may be used in conjunction with this Standard to develop sustainment structures.

2.2.4 Creating the WBS Dictionary. As part of developing a Program WBS, the program manager and contractor 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

Level 1 Level 2 Level 3 Level 4

Aircraft System

Aircraft System, Integration, Assembly, Test and Checkout

Air Vehicle

Air Vehicle Integration, Assembly, Test and Checkout

Airframe

Airframe Integration, Assembly, Test and Checkout

Fuselage

Empennage

Nacelle

Other Airframe Components 1..n (Specify)

Propulsion

Vehicle Subsystems

Vehicle Subsystem Integration, Assembly, Test & C/O

Flight Control Subsystem

Auxiliary Power Subsystem

Hydraulic Subsystem

Electrical Subsystem

Crew Station Subsystem

Environmental Control Subsystem

Fuel Subsystem

Landing Gear

Rotor Group

Drive Group

Vehicle Subsystem Software Release 1..n (Specify)

Other Subsystems 1..n (Specify)

Avionics

Avionics Integration, Assembly, Test & C/O

Communications/Identification

Navigation/Guidance

Mission Computing/Processing Level 1(4) Level 2(5) Level 3(6) Level 4(7)

Fire Control Fire Control System

≈ ≈ Prime Mission Product (Radar)

Other Avionics Subsystems 1..n (Specify) Antenna

Armament/Weapons Delivery Transmit/Receive (T/R) Modules/Phase Shifters 1...n (Specify)

Auxiliary Equipment Array Electronics

Furnishings and Equipment Array Structure

Air Vehicle Software Release 1..n (Specify) Gimbal Assembly

Payload/Mission System Cooling Manifold

≈ ≈ Array Power Supply 1...n

Training Antenna Software Release 1...n (Specify)

Level 1(4) Level 2(5) Level 3(6) Equipment PMP Integration, Assembly, Test & C/O

Operator Instructional Equipment Operator Instructional Equipment Radar Electronics

Prime Mission Product OTE Equipment ≈ ≈ ≈ ≈ Student Station Data PMP Integration, Assembly, Test & C/O

Instructor Operation Station Peculiar Support Equipment System Engineering

Visual System Common Support Equipment Program Management Motion System…