Back to Top

Educating the Aerospace Industry

Blog Archives

Risk & Safety Management

Risk & Safety Management Overview

Risk Management Process

 

Risk is a measure of future uncertainties in achieving program performance goals, requirements, and objectives within defined cost, schedule, and performance constraints. Risk can be associated with all aspects of a program (e.g., threat, System Safety, technology maturity, supplier capability, design maturation, performance against plan) as these aspects relate across the Work Breakdown Structure (WBS), Integrated Master Schedule (IMS) and Integrated Master Plan (IMP). Risk addresses the potential variation in the planned approach and its expected outcome. [1]

 

Risks have three (3) components:

  1. A future root cause (yet to happen), which, if eliminated or corrected, would prevent a potential consequence from occurring,
  2. A probability (or likelihood) assessed at the present time of that future root cause occurring, and
  3. The consequence (or effect) of that future occurrence.

Risk Management
Risk management is a continuous process that is accomplished throughout the life cycle of a system and should begin at the earliest stages of program planning. It is an organized methodology for continuously identifying and measuring the unknowns; developing mitigation options; selecting, planning, and implementing appropriate risk mitigations; and tracking the implementation to ensure successful risk reduction. Effective risk management depends on risk management planning; early identification and analyses of risks; early implementation of corrective actions; continuous monitoring and reassessment; and communication, documentation, and coordination. It’s most effective if it is fully integrated with the program’s Systems Engineering, Program Management, and Test & Evaluation processes.

 

The risk management process includes the following continuous key activities as shown above:

System Safety
System Safety is the application of engineering and management principles, criteria, and techniques to achieve acceptable risk within the constraints of operational effectiveness and suitability, schedule, and cost throughout the system’s lifecycle. System safety covers the entire spectrum of environment, safety, and occupational health (ESOH) considerations. It is an integral part of the Systems Engineering (SE) process and specific activities are required throughout the different phases of the acquisition lifecycle. [2]

 

As a Program Manager (PM), systems engineer, risk manager, or safety manager there are many areas of risk and safety management that need to be understood in order to successfully execute a program. A few of these areas include:

 

AcqTips:    

AcqLinks and References:

Updated: 8/14/2018

Acquisition Process

Acquisition Strategy

 

The Acquisition Strategy is a comprehensive plan that identifies and describes the acquisition approach that Program Management will follow to manage program risks and meet program objectives. The Acquisition Strategy guides program execution across the entire program life cycle and is updated at every major milestone and review.  An approved strategy is reviewed and approved by the Milestone Decision Authority (MDA) at Milestone A and the Development RFP Decision Point. The acquisition strategy is then updated for MDA approval at Milestone B, Milestone C, and Full-Rate Production Decision (FRPD) review. [2]

 

Acquisition Strategy Main Elements [1]

  1. Business Strategy: Address the main contracting approach, including contract types; how the competition will be sought, promoted, and sustained; source selection procedures, provisions, and sources; product support considerations; and leasing arrangements.
  2. Contracting Strategy: Explain and, to the extent necessary, provide the analysis and rationale for the contracting strategy. Justify the use of fixed-price or cost-plus vehicles. Explain why the incentives provided were chosen and why there is confidence that they will successfully motivate the contractor to provide the performance desired by the government.
  3. Major Contract(s): Identify the number and type of contracts, deliverable items, options, exit criteria, contracting plan (competitive versus sole source and future down-select options), along with any other considerations.
  4. Incentives: For each major contract, describe the contract incentives in detail. State how contract incentives are going to be employed to achieve required cost, schedule, and performance outcomes. If more than one incentive is planned for a contract, the Technology Development Strategy (TDS) and Acquisition Strategy should explain how the incentives complement each other and do not interfere with one another.
  5. Technical Data Management: The strategy for Acquisition Category (ACAT) I and II programs shall assess the long-term technical data needs for the system and reflect that assessment in both the TDS and the acquisition strategy.
  6. Sustainment: The acquisition strategy should provide an overview of the sustainment-related contract(s) and performance-based agreements, with government and industry providers describing how the integrated product support package will be acquired for the system being supported. The discussion should include the contract/agreement and length, along with major terms and conditions; performance measures being used, and the portion of the system covered with the associated sustainment-related functions, plus hardware and data covered in each contract/agreement.

Template: DoD Acquisition Strategy Template – 20 April 2011

 

Federal Acquisition Regulation (FAR) 7.1 and Defense Federal Acquisition Regulation Supplement (DFARS) 207.1 address policies related to acquisition planning and the development of written acquisition plans.

 

Requirements that must be addressed in the Acquisition Strategy include:

  • Benefit Analysis and Needs Determination
  • Consideration of Technology Issues
  • Contracting Strategies
    • Contract-Type Determination
    • Termination Liability Estimate
  • Cooperative Opportunities
  • General Equipment Validation
  • Industrial Base Capabilities Consideration
  • Intellectual Property (IP) Strategy
  • Market Research
  • SBIR / STTR

 

The Acquisition Strategy should also:

  • Provide sufficient detail to allow decision-makers and the Milestone Decision Authority (MDA) to assess whether the strategy makes good business sense, effectively implements laws and policies, and reflects management‘s priorities
  • Provide a detailed plan for successful completing of the EMB phase and Operations and Support (O&S) Phase
  • Cover development, testing, production, and life-cycle support. It should establish the requirements for each phase, and identify the critical management events.
  • Describe the Critical Program Information (CPI)
  • Describe the Contract Strategy of the program.
  • Describe the knowledge and products needed from Test & Evaluation (T&E), and their timing, to inform acquisition decisions and milestones across the life cycle
  • Define approach for Small business, including Small Disadvantaged Business, Women-Owned Small Business, Veteran-Owned Small Business, Service-Disabled Small Business, and Historically Underutilized Business Zones.
  • Define the relationship between the acquisition phases and work efforts, and key program events such as decision points, reviews, contract awards, test activities, production lot/delivery quantities, and operational deployment objectives.
  • Include a Top-Level Integrated Schedule and a summary of highlights from the Integrated Master Plan (IMP) and Integrated Master Schedule (IMS)
  • Defines the approach the program will use to achieve full capability: either Evolutionary or single step
  • Be complete enough to fully describe the planning considerations and decisions needed to balance cost, schedule, and life-cycle performance
  • Describe the treatment of interoperability requirements
  • Summarize how Human System Integration (HSI) requirements will be integrated within the systems engineering, logistics, technology development, and resource management processes, including a summary of the HSI risks and supporting mitigation plans
  • Describe the processes planned to protect the overall effort/program from threats, including adversaries, industrial espionage and threats to personal information, and including unfair competition
  • Summarize the Risk Management Process
  • Address the Technology Development Strategy (TDS)
  • Include results of industrial base capability (public and private) analysis to design, develop, produce, support, and, if appropriate, restart an acquisition program
  • Highlight the strategy for assessing industrial and manufacturing readiness.
  • Include a summary of the Programmatic Environment, Safety, and Occupational Health Evaluation (PESHE)
  • Describe signature support requirements and required funding to support program-related efforts.

 

Table of Content (Notional)

  1. Purpose and Program Description
  2. Capability Need
  3. Acquisition Approach
  4. Tailoring
  5. Program Schedule
  6. Risk Areas and Design Considerations
  7. Business Strategy
  8. Cost and Funding
  9. Resource Management
  10. International Involvement
  11. Industrial Capability and Manufacturing Readiness
  12. Life-Cycle Signature Support
  13. Military Equipment Valuation
  14. Test Strategy
  15. Identification of Participants in Acquisition Plan Preparation

 

AcqTips:

  • The Defense Acquisition Guidebook, Chapter 2, provides more detail about what should be covered in the Acquisition Strategy.

AcqLinks and References

Updated: 3/18/2020

Software Management

Software Management Overview

 

Software Management is the art and science of planning and leading software projects. It’s the Program Manager (PM) and Software Engineers job to manage the development of software and should use standard project management techniques to managing a software project. In the DoD, software management is called Software Acquisition Management. It includes the management and execution of software activities throughout the lifecycle of a program. These software activities include:

Other tasks in Software Management include:

 

Checklist: Software Activity Map

Handbook: USAF Weapon Systems Software Management Guidebook – 15 Aug 2008

 

Software System Safety
It is essential to perform System Safety Engineering tasks on safety-critical systems to reduce safety risk in all aspects of a program. These tasks include software system safety activities involving the management, design, code, test, independent verification and validation (IV&V), operation and maintenance, and change control functions within the software engineering development and deployment processes.

 

Software maturity strategy should be discussed in the Acquisition Strategy.

 

 

AcqLinks and References:

Updated: 6/7/2018

Requirements Development

Requirements Development Overview

Requirements Overview

 

Requirements development is a process that consists of a set of activities that produces requirements for a product. The systems engineering standard [EIA 632] defines “requirement” as “something that governs what, how well, and under what conditions a product will achieve a given purpose.” Requirements define the functions, performance, and environment of the system under development to a level that can be built:

In the Department of Defense (DoD) the requirements process is governed by the Joint Capabilities Integration and Development System (JCIDS) Process. The JCIDS Process ensures the capabilities required by the DoD are identified and their functional and performance requirements are developed. The main engineering disciple that develops and controls requirements development is Systems Engineering (SE). Requirements development is Step One: Requirements Analysis of the Systems Engineering Process. The four (4) main requirements documents that are produced on a typical DoD program during a specific Acquisition Phase are:

Actual Requirements Development
There is no set standard way to develop requirements but they are normally developed follow the same basic six (6) steps. These requirements development steps don’t really change depending on which SE model is used. All models are similar in their approach but they just usually depict the step differently graphically. The main model that is used is the Systems Engineering “Vee” where requirements development is depicted on the left side. Below is a list of the basic steps of requirements development.

Other topics that Stakeholders, Program Manager (PM), and Systems Engineers need to know about Requirements Development are:

AcqLinks and References:

Updated: 2/12/2020

Program Management

Program Management Overview

DAU Program Managers Toolkit

DAU Program Managers Toolkit

 

Program Management is the discipline used by the Department of Defense (DoD) and Aerospace Community for controlling the cost, schedule, and performance of a project or group of projects to achieve a stated goal. According to the Project Management Institute (PMI), “A Program is a group of related projects managed in a coordinated manner to obtain benefits and control not available from managing them individually.” Program Management is focused on: [1]

 

The DoD acquisition system represents the processes that are used to procure, develop and utilize products for the DoD. The system consists of three (3) individual processes (Acquisition, Requirements, and Funding) that provide the policies, principles, and laws that govern the management of DoD programs. The three individual processes are:

 

A Program Manager (PM) is the actual title of the individual who is responsible for the cost, schedule, and performance of a specific project. The PM must understand and manage multiple discipline areas in order the successfully execute a project. In the DoD, the PM has the authority to accomplish program objectives for the development, production, and sustainment of systems to meet the user’s operational needs and is accountable to the Milestone Decision Authority (MDA). In order to accomplish these goals and meet objectives, the PM must integrate and understand:

 

A Program Manager (PM) should have the “big picture” perspective of their project, including in-depth knowledge of the interrelationships among its elements. An effective program manager:

  • Is a leader and a manager, not primarily a task “doer”;
  • Understands the requirements, environmental factors, organizations, activities, constraints, risks, and motivations impacting the program;
  • Knows and is capable of working within the established framework, managerial systems, and processes that provide funding and other decisions for the program to proceed;
  • Comprehends and puts to use the basic skills of management-planning, organizing, staffing, leading, and controlling-so people and systems harmonize to produce the desired results;
  • Coordinates the work of defense industry contractors, consultants, in-house engineers and logisticians, contracting officers, and others, whether assigned directly to the program office or supporting it through some form of an integrated product team or matrix support arrangement;
  • Builds support for the program and monitors reactions and perceptions that help or impede progress; and
  • Serves both the military needs of the user in the field and the priority and funding constraints imposed by managers in the Pentagon and military service/defense agency headquarters.

 

Integrated Product and Process Development (IPPD) is the DoD management technique that simultaneously integrates all essential acquisition activities through the use of Integrated Product Teams (IPT) to optimize design, manufacturing, and supportability processes. IPPD facilitates meeting cost and performance objectives from product concept through production, including field support.

 

AcqLinks and References:

Updated: 3/17/2021

Logistics & Supply Management

Acquisition Logistics Overview

Mil-HNDBK Acquisition Logistics

Mil-HNDBK Acquisition Logistics

 

Acquisition Logistics is a multi-functional, technical management discipline associated with the design, development, test, production, fielding, sustainment, and improvement modifications of DoD systems. The majority of a system’s life-cycle costs can be attributed directly to operations and support costs once the system is fielded.  The three (3) principal objectives of acquisition logistics are to ensure:

  1. That support considerations are an integral part of the system’s design requirements
  2. The system can be cost-effectively supported throughout its life-cycle
  3. Product Support elements necessary to the initial fielding and operational support of the system are identified, developed, and acquired.

 

The Program Manager (PM) and Product Support Manager (PSM) is responsible for accomplishing these principal program objectives across the life-cycle of a system, including the Operating & Support (O&S) Phase. Employing Performance-Based Life-Cycle Product Support tied to Sustainment Metrics is the overarching DoD acquisition logistics concept for providing Materiel Availability, Supportability, and readiness to the user. [1]

 

Acquisition logistics activities are most effective when they are integral to both the contractor’s and Government’s System Engineering Process and addressed early in the Acquisition Processes.  The main elements of Acquisition Based Logistics are:

 

A number of the tasks associated with acquisition logistics include:

 

AcqLinks and References:

Updated: 3/16/2020

PPBE Process

Budget Exhibits

 

Budget Exhibit’s are prepared by the DoD Components to support requests for appropriations from Congress and help justify the President’s Budget.  Appropriation decisions are based on the content of budget exhibits:

  • How well do the exhibits tell your program’s story?
  • Confusing, inaccurate, and/or inconsistent exhibits will cause programs to lose funding.
  • Well-prepared exhibits make the program more defensible against cuts.

 

Budget Exhibit’s supporting requests for an appropriation are called:

 

Procurement and RDT&E budget exhibits are among the most important documents prepared in support of acquisition programs because they essentially “tell the story” of the programs to the DoD Components, the Office of the Secretary of Defense (OSD), and members of Congress and their staffs.   If this story is incomplete, inaccurate, confusing, or inconsistent, an acquisition program may have its structure and/or budget significantly altered by any of these decision-makers.

 

AcqTips:

  • They are also called Doc’s instead of Forms

AcqLinks and References:

Updated: 5/30/2018

Earned Value Management

Work Packages

 

Work Package (WP) is a natural subdivision of a Control Account (CA). A work package is simply a task/activity or grouping of work and is the point at which work is planned, progress is measured, and earned value is computed. It can be translated into different terms in different companies and functions. It can be a design job, a tool design package, a build-to-package, a shop order, a part number, a purchase order, or any other definable task/activity at whatever level of control is normal for program management within the company. Below are topics that address work packages.

 

Planning Packages (PP)
A logical aggregation of work, usually future effort that can be identified and budgeted, but which is not yet planned in detail at the work package level.

 

Integrated Master Schedule (IMS)
Contains all the detailed discrete work packages and planning packages (or lower level tasks/activities) necessary to support the events, accomplishments, and criteria of the IMP (if applicable). [1]

 

Program Critical Path
A sequence of discrete work packages and planning packages (or lower level tasks/activities) in the network that has the longest total duration through the contract or program that is calculated by the schedule software application.  Discrete work packages and planning packages (or lower level tasks/activities) along the critical path have the least amount of float/slack (scheduling flexibility) and cannot be delayed without delaying the finish time of the entire work effort.

 

Budgeted Cost for Work Scheduled (BCWS)
The sum of the performance budgets for all work scheduled to be accomplished with a given time period.  This includes detailed work packages, planning packages, AE, plus Level of Effort (LOE) packages. [1]

 

Budgeted Cost for Work Performed (BCWP or Earned Value)
The value of completed work expressed as the value of the performance budget assigned to that work.  This is equal to the sum of the budgets for completed work packages, completed portions of open work packages, AE earned on the base accounts, and the value of LOE activities. [1]

 

AcqLinks and References:

Updated: 6/15/2018

Business & Marketing

Wide Area Workflow

Wide Area Workflow-Receipt & Acceptance (WAWF-RA) is a secure web-based system for electronically processing invoices, receipts & acceptance documents being deployed by the Defense Finance and Accounting Service (DFAS).

 

Webpage: Wide Area Workflow – Home Page

 

The eleven (11) general steps that a vendor must accomplish and follow to use the WAWF (website):

  1. Register with the Central Contractor Registry (CCR)
  2. Establish an Electronic Business (EB) Point of Contact (POC) in CCR
  3. Register for Electronic Document Access (EDA) (not required)
  4. Ensure CAGE Code is added to WAWF Group Structure
  5. Establish an Organizational Email Address
  6. Designate a Group Administrator Manager (GAM)
  7. Determine if batch feeds for data input is necessary
  8. Set up PCs to Access WAWF
  9. Self-Register GAM
  10. Have all users for the CAGE Code(s) self-register on the WAWF website for one of the available vendor roles
  11. Practice using WAWF

 

In the traditional DoD business method, three documents are required to make a payment – the contract, the receiving report and the invoice. Each of these may arrive at the payment office separately – if they are paper. They are processed individually as they arrive. Information is then manually keyed in to the payment system. Using WAWF, electronic documents are shared, eliminating paper and redundant data entry. Data accuracy is increased and the risk of losing a document is greatly reduced. [1]

 

 

The contract is available through a seamless interface with an application called Electronic Document Access (EDA). Contractors have electronic options for submitting invoices and receiving documents. They can submit documents on the Web, through FTP, or through EDI. [1]

 

WAWF supports DoD’s efforts to reduce unmatched disbursements in the DoD receipt, acceptance, entitlement and payment process through data sharing and electronic processing. The benefits to DoD are global accessibility of documents, reduced need for re-keying, improved data accuracy, real-time processing, and secure transactions with audit capability. For vendors, benefits include the capability to electronically submit invoices, reduction of lost or misplaced documents, and online access to contract payment records. [1]

 

AcqLinks and References:

Updated: 6/22/2018

Business & Marketing

Warranties

 

A Warranty is an express or implied promise from the seller that certain facts about the items or services being sold are true. It provides a buyer with the legal assurance that the seller is providing an item or service that will perform as represented before the purchase transaction was complete. The concept of “warranty” also refers to certain promises, made by the Government, of future events or conditions (such as availability of a construction worksite) needed for the supplier to perform the contract. [1]

 

There are two (2) broad categories of warranties: [1]

  • Express: According to the Uniform Commercial Code (UCC), “Any affirmation of fact or promise made by the seller to the buyer which relates to the goods and becomes part of the basis of the bargain creates an express warranty that the goods shall conform to the affirmation or promise.”
  • Implied: This type of warranty revolves around the concepts of fitness for use and merchantability. Implied warranties become part of commercial contracts even though they are not written, unless specifically excluded. Federal Acquisition Regulation (FAR) Part 12 (Acquisition of Commercial Items) has integrated implied warranties into contracts when the clause at FAR 52.212-4 is included. The Government’s post-award rights contained in 52.212-4 are the implied warranty of merchantability, the implied warranty of fitness for particular purpose and the remedies contained in the acceptance paragraph. Government contracting officers should consult with legal counsel prior to asserting any claim for a breach of an implied warranty.

 

The Federal Acquisition Streamlining Act of 1994 (FASA) requires contracting officers to take full advantage of commercial warranties. To the maximum extent practicable, solicitations for commercial items must require offeror’s to offer the Government at least the same warranty terms, including offers of extended warranties, offered to the general public in customary commercial practice. Solicitations may specify minimum warranty terms, e.g., minimum length of warranty coverage, appropriate for the Government’s intended use of the item(s). [2]

 

Typically, warranties are on system or component reliability. The procedures for processing warranties should minimize impact on the user, particularly at the organizational level. Warranty provisions should enable the user to make warranty claims without delaying essential maintenance needed to restore system availability. [1]

 

AcqLinks and References: