DoD_WORK_BREAKDOWN_STRUCTURES.pdf

NOT MEASUREMENT

SENSITIVE

MIL-STD-881C

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

AMSC 9213 AREA MISC

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

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

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.

https://assist.daps.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 Level Identification

1.5.6 Program WBS

1.5.7 Contract WBS

1.5.8 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

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, and 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 Intelligence Requirements and Related Costs

3.2.4 Software and Software Intensive Systems

3.2.4.1 Automated Information Systems (AIS)

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 Activities

4.4.1 Earned Value Management

4.4.2 Cost Estimating

4.4.3 Contract Funds Status

4.5 Summary

5. NOTES SECTION

5.1 Intended Use

5.2 Associated Data Item Descriptions

5.3 Supersession Data

5.4 Subject Term (key word) Listing

5.5 Changes from Previous Issue

v

FIGURE

1. The Defense Acquisition Management Framework

2. WBS Evolution

3. Capability Requirements in the Materiel Solution Analysis Phase

4. Identification of Major Subsystems and Functional Requirements

5. Program WBS Description

6. EMD Requirements

7. Work Breakdown Structure Matrix (Contract WBS)

8. Example of System Configuration Documentation

9. Relationship of Program WBS to Contract WBS

10. Relationship of Contract WBS to Subcontract WBS

11. Translation from Function to Product

12. IPT Intersection with Contract WBS

13. Linkage Between Contractor WBS and Contractor Management Systems

14. Relationship of IMP/IMS to WBS

15. The WBS is the Basis for DoD Reporting Requirements

APPENDICES

A Aircraft Systems WBS and Definitions

B Electronic Systems WBS and Definitions

C Missile Systems WBS and Definitions

D Ordnance Systems WBS and Definitions

E Sea Systems WBS and Definitions

F Space Systems WBS and Definitions

G Surface Vehicle Systems WBS and Definitions

H Unmanned Air Vehicle Systems WBS and Definitions

I Unmanned Maritime Systems WBS and Definitions

J Launch Vehicle Systems WBS and Definitions

K Automated Information Systems WBS and Definitions

L Common Elements WBS and Definitions

CONCLUDING MATERIAL

vi

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.

PROPOSED

PROGRAM

WBS(s)

MATERIEL

SOLUTION

ANALYSIS

APPROVED/

PROPOSED

PROGRAM WBS APPROVED/

UPDATED

PROGRAM

WBS

#1 CONTRACT

WBS AND

EXTENSION

#2 CONTRACT

WBS AND

EXTENSION

OTHER

CONTRACT(s)

IF ANY

APPROVED

PROGRAM

WBS

#1 CONTRACT

WBS AND

EXTENSION

#2 CONTRACT

WBS AND

EXTENSION

OTHER

CONTRACT(s)

IF ANY

TECHNOLOGY

DEVELOPMENT

ENGINEERING AND

MANUFACTURING

DEVELOPMENT PRODUCTION AND

DEPLOYMENT

#1 CONTRACT

PRELIMINARY

WBS

#2 CONTRACT

PRELIMINARY

WBS

OTHER

CONTRACT(s)

IF ANY

PRE-SYSTEMS ACQUISITION SYSTEMS ACQUISITION

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

KILLTANK KILLTANK

SHOOT SHOOT

MANEUVER MANEUVER DETECT DETECT

USER NEED LEVEL - 0

SYSTEM NEED LEVEL - 1

MATERIEL SOLUTION ANALYSIS

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.

Aircraft

System

Training Air Vehicle

TECHNOLOGY DEVELOPMENT

Program

Management

Commu-nication` Navigation

Fire

Control

Equipment Services

Level 1

Level 2

Level 3 Airframe Avionics

Level 4

Level 5

Propulsion

Antenna Receiver Transmitter

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.

B

Engineering & Manufacturing

Development – Two Major Efforts

C

PDR CDR

CDD CPD

Post CDR Assessment

PDR

or

Integrated System

Design

System Capability &

Manufacturing Process

Demonstration

Post PDR Assessment

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.

1 2 3 4

AIRCRAFT SYSTEM

AIR VEHICLE

AIRFRAME

PROPULSION

VEHICLE SUBSYSTEMS

AVIONICS

FIRE CONTROL

ARMAMENT/WEAPON DELIVERY

AUXILIARY EQUIPMENT 1(4) 2(5) 3(6) 4(7) 5(8)

FURNISHINGS AND EQUIPMENT FIRE CONTROL SYSTEM

AV SOFTWARE RELEASE 1…n (SPECIFY) RADAR

AV IAT&CO RECEIVER

TRANSMITTER

SYSTEMS ENGINEERING ANTENNA

PROGRAM MANAGEMENT RADAR SOFTWARE RELEASE 1..n

SYSTEM TEST AND EVALUATION SOFTWARE PRODUCT ENGINEERING

DEVELOPMENT TEST AND EVALUATION COMPUTER SOFTWARE CONFIGURATION ITEM (1..n)

1(4) 2(5) 3(6) OPERATIONAL TEST AND EVALUATION SOFTWARE INTEGRATION, ASSEMBLY, TEST AND CHECKOUT

AIRCREW TRAINING DEVICE (ATD) MOCK-UPS/SYSTEM INTEGRATION LABS RADAR INTEG., ASSEMBLY, TEST AND CHKOUT

ATD EQUIPMENT TEST AND EVALUATION SUPPORT PLATFORM INTEGRATION

STUDENT STATION SYSTEM ENGINEERING

INSTRUCTOR OPERATOR STATION TRAINING PROGRAM MANAGEMENT

COMPUTER SYSTEM EQUIPMENT SYSTEM TEST AND EVALUATION

VISUAL SYSTEM CLASSROOM EQUIPMENT TRAINING

MOTION SYSTEM COMPUTER BASED INSTRUCTION SYSTEM DATA

DRLMS SYSTEM AIRCREW TRAINING DEVICE (ATD) PECULIAR SUPPORT EQUIPMENT

. COMMON SUPPORT EQUIPMENT

. INITIAL SPARES AND REPAIR PARTS

SYSTEM ENGINEERING ETC

PROGRAM MANAGEMENT SERVICES

SYSTEM TEST AND EVALUATION FACILTIES

TRAINING PECULIAR SUPPORT EQUIPMENT

DATA TEST AND MEASUREMENT EQUIPMENT

PECULIAR SUPPORT EQUIPMENT SUPPORT AND HANDLING EQUIPMENT

COMMON SUPPORT EQUIPMENT COMMON SUPPORT EQUIPMENT

OPERATIONAL/SITE ACTIVATION OPERATIONAL/SITE ACTIVATION

INITIAL SPARES AND REPAIR PARTS INITIAL SPARES AND REPAIR PARTS

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

2.

3. PLACEMENT OF THE SUBSYSTEM IN THE PROGRAM WORK BREAKDOWN STRUCTURE IS RELATIVE TO ITS

WBS BREAKOUT FOR CONTRACT APPLICATION

PRIME MISSION SYSTEM

AIRCREW TRAINING DEVICE

LEVEL 2 ELEMENTS (SYSTEM ENGINEERING/PROGRAM MANAGEMENT, SYSTEM TEST AND EVALUATION, ETC.) FOR SUBSYSTEMS OF THE PMS ARE CONTAINED IN (I.E., ARE SUBELEMENTS OF THE SUBSYSTEM

ELEMENT NOT THE PMS LEVEL 2 ELEMENT

FIRE CONTROL SUBSYSTEM WBS

FIGURE 7. Work Breakdown Structure Matrix (Contract WBS)

SYSTEM

CI-1 CI-2 CI-3

CI-11

HW

CI-12

PROC

CI-13

HW CI-21 CI-22

CI-31

HW

CSCI-32

SW

CI-222

FW

CI-221

HW

CSCI-213

SW

CI-212

FW

CI-211

HW

CI-122

HW

CI-121

HW

HW

(HARDWARE)

PROC

(PROCESSOR)

FW

(FIRMWARE)

SW

(SOFTWARE)

LEGEND

(CONFIGURATION ITEM)

CI

CSCI

(COMPUTER SOFTWARE

CONFIGURATION ITEM)

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…