Back to Top

Educating the Aerospace Industry

Blog Archives

Financial Management

Operating and Support Cost

Operating and Support Cost (O&S) consists of sustainment costs incurred from the initial system deployment through the end of system operations. This includes costs directly and indirectly attributable to the system (i.e., costs that would not occur if the system did not exist), regardless of funding source or management control.

Typically costs include: [1]

  • Continuing System Improvements
  • Depot Maintenance
  • Energy (Fuel, Electricity, etc.)
  • Equipment
  • General Training and Education
  • Hardware Modifications or Modernization
  • Indirect Support
  • Installation Support
  • Intermediate Maintenance
  • Maintaining
  • Maintenance
  • Manpower
  • Modifying Operating
  • Operating Equipment Replacement
  • Operating Materiel
  • Operations Manpower
  • Organizational Maintenance and Support
  • Personnel Support
  • Program Management
  • Software Maintenance and Modifications
  • Supplies
  • Supplying
  • Support Equipment Replacement
  • Support Services
  • Sustaining Engineering
  • Sustaining Support
  • System Specific Training
  • Temporary Duty Training Munitions and Expendable Stores
  • Unit Operations
  • Unit-Level Maintenance Manpower

Direct costs refer to the resources immediately associated with the system or its operating unit. Indirect costs refer to the resources that provide indirect support to the system (including its manpower or facilities).

For the Operating and Support Cost report format, see DoD 7000.14 R, Financial Management Regulation, Volume 2B, Chapter 5.

AcqTips:

  • The Training element includes training equipment and devices, training course materials, and training services
  • Supportability Analysis that defines the requirements for the logistics elements is part of Systems Engineering, and planning and management associated with the logistics elements is part of Program Management
  • Specialized facilities (fixtures, test chambers, laboratories, etc.) are considered part of the Work Breakdown Structure (WBS) element that they support.
  • Specialized contractor support is considered part of the WBS element that it supports. Contractor support associated with the service, maintenance or launch of prime mission systems is part of the Operational/Site Activation element

AcqLinks and References:

Updated: 7/20/2017

Financial Management

Funding – Program Management Administration (PMA)

Funding for Program Management Administration (PMA) is the cost of mission essential office operations in direct support of a program and its program management office (PMO).  It’s budgeted on an annual basis and reflected in the fiscal year during which the requirement is projected to execute. PMA costs are charged to the appropriation funding the task being supported and normally executed in the first year of availability.

PMA costs include:

  • SPO Travel,
  • contract services in support of program office
  • operations (including Advisory & Assistance Services (A&AS) contracts),
  • computer support,
  • unique communication expenses,
  • printing,
  • supplies, and
  • initial program specific training

PMA costs do not include: 

  • Civilian pay or overtime pay,
  • Standard base or installation operating support,
  • Costs associated with HQ level support
  • Building repairs
  • Snow removal

AcqNotes and References:

  •  Air Force Instruction (AFI) 65-601

Updated: 7/20/2017

Financial Management

Financial Management Laws

AcqTips:  

AcqLinks and References:

Updated: 7/20/2017

Financial Management

Expense Investment Threshold

DoD policy requires cost definition criteria that can be used in determining the content of the programs and activities that comprise the Defense budget. Costs are categorized as either expenses or investments. Purchases (i.e., obligations) of non-centrally managed items with a unit cost of $250,000 or less, are considered expenses funded from appropriations available to DoD for operation and maintenance. Costs budgeted in the Operation and Maintenance (O&M) and Military Personnel appropriations are considered expenses. Purchases of non-centrally managed items with a unit cost greater than $250,000 are investments funded from appropriations available for investments. Costs budgeted in the Procurement and Military Construction appropriations are considered investments. Costs budgeted in the Research, Development, Test and Evaluation (RDT&E), Base Realignment and Closure (BRAC), and Family Housing appropriations include both expenses and investments. If an item is centrally managed, it is always considered an investment cost regardless of the unit cost.

There is a difference between the expense/investment threshold established by the Congress and the capitalization threshold established for accounting purposes. The expense/investment threshold determines whether a DoD activity purchases an asset using O&M or procurement appropriations.

For Defense Working Capital Fund (DWCF) activities this limit determines whether an asset is purchased using the operating budget or the capital budget. For accounting purposes, the capitalization threshold determines when an activity records and depreciates an asset on the financial statement. The two criteria are not the same. Activities will establish DWCF rates using the expense/investment threshold of $100,000 for Minor Construction projects and $250,000 for all other capital assets. DWCF activities will record all items purchased using Capital Budget Obligation Authority on the balance sheet and depreciate those assets over its useful life. For accounting purposes, the capitalization threshold is $20,000 for Minor Construction and $100,000 for all other Capital Investments. If an asset meets the accounting capitalization threshold, but is less than the budget investment threshold, the DWCF activity will record this asset on the financial statements as a capital asset and depreciate it over its useful life. However, at the end of each fiscal year, activities will make an accounting adjustment to treat the gain generated by this transaction as non-recoverable for rate setting purposes. The gain is the difference between the cost of the asset and the depreciation recorded.

  • Multi-Year Appropriations: Often referred to as investment appropriations because they are available to fund investment costs (e.g., OPN, WPN, APN, PAN&MC, SCN, MILCON, RDT&EN, etc.). These funds are available for new obligations for multiple years.
  • Annual “Expense” Appropriations: Often referred to as expense appropriations because they are available to fund expense costs. These are primarily O&M accounts (e.g., O&M,N, O&M,NR, MPN, RPN, etc.). These funds are available for new obligations only for the fiscal year authorized and appropriated.
  • The question to ask is what are you buying, what is the unit cost, is the item centrally managed or non-centrally managed, is this an expense or an investment cost, and are you using the right funds that can legally finance that specific type of cost?

AcqLinks and References:

Updated: 7/20/2017

 

Financial Management

Disposal Cost

Disposal Cost consists of the expenses associated with demilitarization and disposal of a military system at the end of its useful life. Typically costs include: [1]

  • Collection/storage/disposal of hazardous materials and/or waste
  • Decontamination
  • Disassembly
  • Materials processing
  • Safety precautions
  • Transportation of the system to and from the disposal site

The intent of the use of the disposal cost category is to ensure that design and other decisions made early in the program consider their effects on the specific long-term disposal costs that can be logically attributed to the program. Disposal costs may be estimated and presented using the following categories, subject to tailoring for the circumstances unique to each program: [1]

  • Removal from Active Service
  • Demilitarization
  • Removal and Disposal of Hazardous Materials
  • Reclamation of Parts
  • Storage Final Disposal or Salvage

AcqTips:

  • Disposal costs of a more general nature, such as the removal of unexploded ordnance at a training range, would normally not be attributed to a specific aircraft program that in the future may participate in training exercises at that range.

AcqLinks and References:

Updated: 7/20/2017

Financial Management

Contract Finance Payments

Contract financing payments are authorized Government disbursement of monies to a contractor prior to acceptance of supplies or services by the Government. They are based upon Firm Fixed Price (FFP) contracts. The specific methods of Government contract financing payment liquidation include:

  1. Commercial advance and interim payments
  2. Progress Payments
  3. Performance-Based Payments

1) Commercial Advance and Interim Payment (Subpart 32.2)
A commercial interim payment is given to the contractor after some work has been done. These payments are contract financing payments. Commercial interim payments and commercial advance payments may be made under the following circumstances:

  1. The contract item financed is a commercial supply or service;
  2. The contract price exceeds the simplified acquisition threshold;
  3. The contracting officer determines that it is appropriate or customary in the commercial marketplace to make financing payments for the item;
  4. Authorizing this form of contract financing is in the best interest of the Government (see paragraph (e) of this subsection);
  5. Adequate security is obtained (see 32.202-4);
  6. Prior to any performance of work under the contract, the aggregate of commercial advance payments shall not exceed 15 percent of the contract price;
  7. The contract is awarded on the basis of competitive procedures or, if only one offer is solicited, adequate consideration is obtained (based on the time value of the additional financing to be provided) if the financing is expected to be substantially more advantageous to the offeror than the offeror’s normal method of customer financing; and
  8. The contracting officer obtains concurrence from the payment office concerning liquidation provisions when required by 32.206(e).

2) Progress Payments (Subpart 32.5)
Progress payments may be customary or unusual. Customary progress payments are those made under the general guidance using the customary progress payment rate (80%), the cost base, and frequency of payment established in the Progress Payments clause, and either the ordinary liquidation method or the alternate method as provided in subsections FAR 32.503-8 and FAR 32.503-9. Unusual payments are authorized in accordance with subsection 32.501-2.

3) Performance-Based Payments (Subpart 32.10)
Performance-based payments are contract financing payments that are not payment for accepted items. They are liquidated by deducting a percentage or a designated dollar amount from the delivery payments. The Contracting Officer must specify the liquidation rate or designated dollar amount in the contract. The method of liquidation must ensure complete liquidation no later than final payment.

  • If the contracting officer establishes the performance-based payments on a delivery item basis, the liquidation amount for each line item is the percent of that delivery item price that was previously paid under performance-based finance payments or the designated dollar amount.
  • If the performance-based finance payments are on a whole contract basis, liquidation is by pre-designated liquidation amounts or liquidation percentages.

Performance-based payments shall not be used for:

  • Payments under cost-reimbursement line items;
  • Contracts for architect-engineer services or construction, or for shipbuilding or ship conversion, alteration, or repair, when the contracts provide for progress payments based upon a percentage or stage of completion; or
  • Contracts awarded through sealed bid procedures.

Definitions
Delivery Payment: means a payment for accepted supplies or services, including payments for accepted partial deliveries. Financing payments are liquidated by deductions from these payments.
Invoice Payment: means a Government disbursement of monies to a contractor under a contract or other authorization for supplies or services accepted by the Government.
Liquidate: means to decrease a [delivery or invoice] payment for an accepted supply item or service under a contract for the purpose of recouping financing payments previously paid to the contractor.

AcqLinks and References:

Updated: 7/20/2017

Major Reviews

Alternative Systems Review (ASR)

 

Major Reviews


An Alternative Systems Review (ASR) is a technical review that assesses the preliminary materiel solutions that have been developed during the Materiel Solution Analysis (MSA) Phase.  The review ensures that one or more proposed materiel solution(s) have the best potential to be cost effective, affordable, operationally effective and suitable, and can be developed to provide a timely solution to at an acceptable level of risk to satisfy the capabilities listed in an Initial Capabilities Document (ICD).

Checklist: ASR Risk Assessment Checklist

A successful ASR is predicated on the review team’s determination that the operational capabilities, proposed solution(s), available technologies, and program resources (funding, schedule, staffing, infrastructure, and processes) form a satisfactory basis for proceeding into the Technology Development (TD) Phase.  An ASR should provide information to the Milestone A review before proceeding into the TD Phase.

Completion of the ASR should provide the following: [1]

  1. An agreement on the proposed materiel solution(s) (including the corresponding product support concept) to take forward into the milestone decision and subsequent Technology Development phase.
  2. Hardware and software architectural constraints/drivers to address all Key Performance Parameters (KPPs)
  3. An assessment of the full system software concept to include conceptual definition of the complete deliverable/non-deliverable software, scope, and risk.
  4. A comprehensive rationale for the proposed materiel solution(s), based upon the Analysis of Alternatives (AoA) that evaluated relative cost, schedule, performance (hardware, human, software), and technology risks.
  5. A comprehensive assessment of the relative risks associated with including Commercial off-the-Shelf (COTS)  items in the program, with emphasis on host platform environmental design, diagnostic information integration, and maintenance concept compatibility.
  6. A comprehensive risk assessment for the Technology Development (TD) phase.
  7. Results of Trade Studies/technical demonstrations for concept risk reduction.
  8. Joint requirements for the purposes of commonality, compatibility, interoperability, and integration.
  9. Refined thresholds and objectives initially stated as broad measures of effectiveness and suitability (e.g., Key Performance Parameters (KPP) / Key System Attributes (KSA)).
  10. Completed, comprehensive planning for the Technology Development phase (hardware, software and human systems), including critical components to be developed, prototyped, and demonstrated, their cost, and critical path drivers. This planning could include an Integrated Master Plan (IMP) and Integrated Master Schedule (IMS).
  11. Initial planning for the Engineering and Manufacturing Development (EMD) phase.
  12. A draft System Requirements Document (SRD)  if one does not already exist. (This is a high-level engineering document that represents the customer/user capability needs as system requirements.) This systems requirement document should include a system level description of all software elements required by the preferred system concept.

AcqTips:

  • The ASR risk assessment checklist is designed as a technical review preparation tool, and should be used as the primary guide for assessing risk during the review.

AcqLinks and References:

Software Management

Example Statement of Work

The Statement of Work (SOW) is a document that enables offeror’s to clearly understand the government’s needs for the work to be done in developing or producing the goods or services to be delivered by a contractor.  The following are some examples of software related SOW that can be used.

Example: SOW Examples

  • The contractor shall establish the Computer Software & Support (CS&S) architecture within the context of the overall system including selection of processor types and architecture, and software architecture and major interfaces, in accordance with applicable Open Systems guidance. As applicable, the SOW should describe which architecture evaluation steps are the supplier‘s responsibilities, and which are to be performed jointly by the acquirer and the system supplier.
  • The contractor shall generate a specification, SOW, Work Breakdown Structure (WBS) in accordance with the Contract Data Requirements List (CDRL), Integrated Master Plan (IMP), Integrated Master Schedule (IMS), and Software Development Plan (SDP) sufficient to describe the software development processes to be employed on the program.
  • The contractor shall design, fabricate, integrate, test, and evaluate the hardware, software, facilities, personnel subsystems, training, and the principle items necessary to satisfy program requirements, and to support and operate the system. This includes the requirements analysis, design, coding and unit testing, component integration and testing, and Computer Software Configuration Item (CSCI) level testing for software. This also includes system development and Operational Test and Evaluation (OT&E), software quality, Configuration Management, and support for software.
  • The contractor shall define a Software Development Approach appropriate for the computer software development and integration effort to be performed under this solicitation.
  • The contractor shall document the software development approach in a SDP, shall implement the SDP requirements, and shall maintain the SDP.
  • The contractor shall use Earn-Value Management (EVM) to manage, determine the status of, and report on the software development effort.
  • The contractor shall implement selected Software Metrics to provide management visibility into the software development process and progress. The contractor shall apply core software metrics, as a minimum. The selected metrics shall clearly portray variances between actual and planned performance, shall provide early detection or prediction of situations that require management attention, and shall support the assessment of the impact of proposed changes on the program. The contractor shall provide the program office routine insight into these metrics.
  • The contractor shall define, manage, track, and verify computer resources (hardware/software) growth and reserve capacity requirements as defined in the system and subsystem specifications. This includes reserve capacity for memory, throughput, I/O, and network.
  • The contractor shall perform a growth analysis for each functional area considering historical experience and risk, software size control activities, planned technology refresh upgrades to computer resources hardware based on predictions, and qualification of hardware necessary to support growth provisions.
  • The contractor shall include software processes, tasks, reviews, and events in the IMP and IMS. The contractor shall ensure the  Integrated Master Plan (IMP), Integrated Master Schedule (IMS), and Software Development Plan (SDP) include the processes, events, and criteria to manage the technical performance characteristics and associated margins and tolerances of the hardware and software.
  • The contractor shall address computer systems and software as part of technical reviews and audits.
  • The Government intends to establish and achieve full organic maintenance capability for the system and separately contract for Training Systems development & procurement. Successful establishment and achievement of this capability requires the contractor and subcontractors to compile, control, maintain and deliver various engineering design disclosure data including computer software in varying media forms and methods in accordance with {specific Contract Line Item Number (CLINs) and contract clauses}.
  • The contractor shall implement procedures to ensure early identification of all asserted restrictions on all technical data and computer software (both commercial and noncommercial), including restrictions asserted by subcontractors and suppliers, and to manage the use of proprietary technologies.
  • The contractor shall prepare and provide Software Resources Data Reports (SRDRs). SRDR requirements, in accordance with DoD 5000.04-M-1, shall apply to the prime and be flowed down to any lower tier contractor that will have an SD&D contract for software effort valued at more than $25M.
  • The contractor shall establish and maintain a hardware-in-the-loop, software/system integration lab (SIL). [Note: may not be applicable/required for all weapon system programs.]
  • The contractor shall implement a program to provide quality assurance of software processes and deliverables. Develop and maintain a Software Quality Assurance Plan which details the subsystem and system level processes used to insure software products are tested and validated in accordance with the systems engineering requirements decomposition. Major events within the Software Quality Assurance Plan shall be reflected in the IMS. Major events include, but are not limited to, Software Quality Audits, Software Configuration Audits, and Software Qualification Testing. Software Quality Assurance shall be flowed to vendors and subcontractors that produce software products used in meeting program requirements.

AcqTips:

AcqLinks and References:

Updated: 7/19/2017

Software Management

Example Statement of Objectives

The Statement of Objectives (SOO) identifies the broad, basic, top-level objectives of the acquisition and is used as a focusing tool for both the Government and offeror’s.  The following are some examples of software related SOO that can be used. [1]

  • An efficient development program that balances risk, cost, schedule and performance.
  • Phased development via incremental software/hardware development approaches.
  • A comprehensive Systems Engineering Process to specify, design, develop, integrate, test, produce, deliver, verify, validate, document, and sustain the system/software that:
    • Satisfies all System Requirements Document (SRD) / Capabilities Development Document (CDD) threshold requirements.
    • Supports rapid, cost effective development/modification of the operational system, training system, and support components to meet System Requirements Document (SRD) thresholds and as many objectives as are affordable.
    • Includes the ability to easily and inexpensively upgrade existing equipment and/or insert new technologies as they become available.
    • Mitigates the risks associated with technology obsolescence, proprietary technologies, and reliance on a single source of supply over the life of the system.
    • Ensures interoperability with the Global Information Grid (GIG) systems and ground processing infrastructures.
    • Reduces system life cycle cost and logistics footprint by addressing required quality attributes, such as reliability, maintainability, supportability, safety, security, and human factors.
    • Supports rapid, cost effective modification/upgrade/technology insertion.
  • An effective system/software development and integration process that uses a modular open systems architecture approach.
  • Timely deployment of initial training components.
  • Use of contractor management processes, procedures, systems, internal metrics, and performance measures unless their use conflicts with contract requirements or does not allow contract requirements to be completely met.
  • Timely, cost effective transition to organic support that ensures access to all required technical data and computer software, and associated license rights.

AcqTips:  

AcqLinks and References:

Updated: 7/19/2017

 

Logistics & Supply Management

Standardization – Supply Management

Standardization is the process of developing and implementing technical standards.  The process establishes common agreement for engineering criteria, terms, principles, practices, materials, items, processes, and equipment parts and components. An organization can benefit from standardization because it: [2,4]

  • Enables mass production
  • Enables customization
  • Improves supplier coordination
  • Improves quality
  • Enables simplification
  • Enables delayed differentiation
  • Lowers inventories

Standards provide recommended processes to apply within an organization, describe expected tasks and outcomes, and describe how the processes and tasks integrate to provide required inputs and outputs. Standards are meant to provide an organization with a set of processes that, if done by qualified persons using appropriate tools and methods, will provide a capability to do effective and efficient engineering of systems. [1]

Some recognized systems engineering process standards: [1]

  • ISO/IEC 15288, Systems and Software Engineering-System Life Cycle Processes
  • ISO/IEC 12207, Systems and Software Engineering -Software Life Cycle Processes
  • ISO/IEC 26702, Application and Management of the Systems Engineering Process
  • ANSI/EIA 632, Processes for Engineering a System (available for sale)

The DoD Standardization Program (DSP)
The DSP is in charge of standardization throughout DOD to reduce costs and improve operational effectiveness.  The documents they develop include DoD or federal specifications or standards, military specifications, military standards, military handbooks, commercial item descriptions (CIDs), qualified product lists (QPLs), qualified manufacturers lists (QMLs), guide specifications, Joint Service Specification Guides (JSSG), Data Item Descriptions (DID), and other documents used in the Defense Standardization Program, such as international standardization agreements and DoD notices of adoption of non-Government standards.  The following websites are databases for Mil-Standards, Specifications and other standardization documentation. [3]

AcqLinks and References:

Updated: 7/19/2017