1-1. 1-2 1-3 1-4 1-5 Project Tasks for Mid Term Exam Provide items 1 - 9 listed below in briefing chart format. 1. Project introduction/background/orientation.

1-1

An Intermediate Level Approach to Systems Engineering based on

INTEGRATED RISK MANAGEMENT – EMIS 7303 Instructor: Dr. Joe H. Dean SMU Contact: Tammy Sherwood Lockheed Martin EMIS Dept., SMU (817) 777-6091 (w) (214) 768-1100 e-mail: [email protected] e-mail: [email protected] Office Hours: After class and by appointment Mailing Address for Exams Tammy Sherwood EMIS Department Southern Methodist University 6425 Airline Road Dallas, TX 75205 Fax: (214) 768-1112 Textbook: Instructor notes supplemented by selected government publications. Systems Engineering Fundamentals, January, 2001, and Risk Management Guide for DoD Acquisition, June, 2003 and are available at http://www.dau.mil/. Lectures: Microsoft PowerPoint files available at http://engr.smu.edu/sys/7303/ COURSE DESCRIPTION: An intermediate level approach to systems engineering from a risk management perspective. Integrated trade studies of program performance, cost, and schedule requirements are conducted with the aid of risk assessments. Topics include program planning, requirements management, risk identification and assessment, risk handling and abatement, risk impact analyses, management of risk handling and abatement, and subcontractor risk management. Systems engineering management methods, procedures, and tools are examined. COURSE REQUIREMENTS: Course grade will be based upon two equally weighted examinations. Each exam will consist of in-class open book questions and individual projects.

1-1

1-2

Course Outline

Date Topic Assignment Jun 5 Introduction and Course Development Background Part 1 of SE (1) Purpose of Systems Engineering Fundamentals Changes Impacting Systems Engineering Grading Criteria Part 2 of SE DoD 5000 Series Guidance Fundamentals Systems Engineering Process Overview Requirements Database Development Part 3 of SE Overview of Acquisition Phases & Program Reviews Fundamentals Work Breakdown Structure Integrated Program Management Work Breakdown Structure Exercise Jun 19 Conduct of Program Technical Reviews Part 4 of SE (2) Systems Engineering Master Schedule Fundamentals SEMS Development Exercise Integrated Master Plan Development Chapters 1 & 2 of Network Schedules RMG Systems Engineering Detailed Schedule Development Exercise Risk Management Overview Risk Management Process Risk Assessment Methods (Melbourne Paper)

1-3

Date Topic Assignment Jul 17 Best Practices Guide Chapter 3 of RMG (3) Concurrency Risks Chapter 4 of RMG

Requirements Analysis Determining Technical Performance Measures Requirements Tracking

Sample Trade Study Comparing Commercial and Defense Life Cycles Risk Handling Options

Decision Analysis Exercise Jul 31 Mid-Term Examination Chapter 5 of RMG (4) Establishing Cost & Schedule Impact Appendix A & B of RMG Schedule Risks Technical Content Assessment Systems Level Modeling/Simulation (Schedule Risk Presentation) Cost and Schedule Tools

Controlled Convergence Trade Studies Cost-Effectiveness Trade Studies

Comprehensive Trade Studies Trade Study Exercise

1-4

Date Topic Aug 14 Managing Risks (5) Developing a Risk Management Plan

Risk Management Best Practices Bayes’ Theorem Time Value of Money Determining Funding Levels for Risk Abatement Alternative

Technology Roadmap Development Process Review for Final Final Examination

1-5

Project Tasks for Mid Term Exam

Provide items 1 - 9 listed below in briefing chart format.

1. Project introduction/background/orientation chart. (4 pts)

2. Identification of key requirements. (6 pts)

3. Program performance measures (technical, cost, and schedule) with thresholds and objectives. (5 pts)

4. Project work breakdown structure (WBS). (6 pts)

5. Integrated master plan for the WBS element(s) of interest. (6 pts)

6. Integrated master schedule in network form with personnel needs identified. (6 pts)

7. Project risk assessment. (6 pts)

8. Risk abatement plan for highest risk item/driver. (6 pts)

9. Development progress metrics. (5 pts)

1-6

Notes On In class Exams

• A hand calculator will be useful for in class exams.

• In class exams are open book and open note.

• Exam questions will come from required texts and lecture material. Familiarity with the contents will save you considerable time.

1-7

Historically Many Large DoD Systems Have Experienced Significant Problems That Can be Traced to Development

• Low Readiness in Operational Use

• Excessive Support Costs

• Cost and Schedule Overruns in Development and Production

• Interoperability Problem

1-8

Overall Purpose of Systems Engineering...

… Is to Prevent Such Problems by Providing for the:

• Planning of All Technical Program Tasks

• Establishing a System Configuration and Size Capable of Meeting All Schedule, Cost and Performance Constraints and Objectives

• Identifying and Balancing Technical Program Risks

• Monitoring and Controlling Technical Development

• Defining of All Requirements for System Development, Test, Production, Operation, and Support in a Systematic and Timely Manner

• Verifying System Capabilities

1-9

System Engineering Integrates And Balances

•••••• •••

SystemsEngineering

Breadth

Depth

Req. AnalysisSystem Concept Dev.Trade StudiesRisk Analysis

Avonics

Propulsion

Structures

Flight

Controls

Test

&

Evaluation

Tool

Design

Tooling

Purchasing

Quality

Assurance

Assembly

Fabrication

Tech.

Manuals

Support

Equi

p.

Field

Support

Training

•••

Production SupportEngineering

1-10

How To Help Engineers Think Like Systems Engineers

CONDUCT OUR DESIGN REVIEWS AS FOLLOWS:1. Requirements

• What Are Your Requirements?• Objectives• Thresholds• Constraints

• What Are Your Assumptions and Criteria• Where Did They Come From?

• Customer• Specs• Derived• Strategy• Flow From Above/Allocated• Validated?

• What Do They Affect?• System/Subsystem Impact• Impact on Next Level (Quantified Allocations)

• How Did You Balance Your Requirements Approach & Why?• Sensitivities

1-11

How To Help Engineers (continued)

2. Design

• What’s Your Design That Meets Requirements?• Physical Description

• How Does It Work?• Functional Description

• How Well Does It Meet Requirements?• Predicted Status vs. Thresholds/Objectives

• Performance Substantiation

• Analysis vs. Test Data

• Test Data vs. Assumptions

• Where’s the Data That Shows It’s the Best Design to Meet Requirements ?

• Performance vs. Design Changes

• Trade Studies

• Where’s Your Documentation?

1-12

How To Help Engineers (continued)

3. Risks

• What Are Your Design Challenges?• Technology

• Concept

• Risk vs. Benefit or Opportunity

• What Are the Things That Can Keep Your Design From Meeting Requirements?

• Risks

• Uncertainties

• What Do You Plan to Do About It?• Risk Reduction Plan

• What’s Your Plan if It Can’t Meet Requirements?• Fall Back

• Impact on Design/Requirements

1-13

Discuss McNamara EraDoD Acquisition Environment

Discuss McNamara EraDoD Acquisition Environment

1-14

Pre-1961 Situation Analyzed

Twelve major systems were studied (ATLAS, JUPITER, POLARIS, BOMARC I, NIKE AJAX, NIKE HERCULES, 8-58, F-105, F4-H, T ALOS, NIKE-ZUES, AND SPARROW III).

Conclusions with regard to the development of these programs were:

“On the average, quality outcomes in our sample tended to exceed original predictions.

This performance was achieved, however, at the expense of:

Development time - Actual development time averaged 36% greater than predictions,

Costs - An average increase of over 200% and as much as seven times original estimates.”

1-15

What Did SEC DEF Do About This Situation?

Made costs equal in importance to performance and lead-time in the normal program, as a matter of policy.

Made elimination of “gold plating” a policy goal.

Made an increase in competition a policy goal.

Made reduction in cost-type contracts, particularly Cost Plus Fixed Fee, a policy goal.

Established a concept formulation and contract definition procedure.

Established a broad range of system analysis studies to aid the decision making process so that life cycle costing and long range force structure planning became an intimate and significant feature.

1-16

DoD Acquisition Process Changes Impacting Systems Engineering

1970 DoD 5000.1 Acquisition Guidelines Published

1974 MIL-STD-499A Establishes Standards for Engineering Management

1981 Pre-Planned Product Improvement (P3I) Incorporated

1985 Willoughby Templates Published

1988 Total Quality Management and Concurrent Engineering Introduced

1989 Air Force Systems Center Instituted an Integrated Product Development (IPT) Approach

1991 New DoD 5000 Series Acquisition Guidelines Signed-Off

1993 Draft of MIL-STD-499B on Systems Engineering

1994 Aeronautical Systems Center Announces Integrated Risk Management to Be Used on Proposals

1994 Process Action Team Recommends Defense Contractors Cease Using Military Specifications and Standards

1996 New DoD 5000 Series Signed-Off

2000 New DoD 5000 Series Signed-Off

2002 DoD 5000 Series Cancelled (presently used for interim guidance)

1-17

DoD 5000 Series Guidancehttp://www.dau.mil/

DoD 5000 Resource CenterDocuments & Changes

DoD 5000 Series Guidancehttp://www.dau.mil/

DoD 5000 Resource CenterDocuments & Changes

1-18

Present Names for Acquisition Phases

Concept & Technology Development

System Development & Demonstration

Production & Deployment

Operation & Support

1-19

Program Objectives and Thresholds

Beginning at the inception of a new acquisition program, the PM shall propose objectives and thresholds for cost, schedule, and performance, that will result in systems that are affordable, timely, operationally effective, operationally suitable, and survivable. The PM shall refine these objectives and thresholds as the program matures, consistent with operational requirements.

1-20

Program Goals shall be Identified as Objectives and Thresholds

Every acquisition program shall establish program goals – thresholds and objectives for the minimum number of cost, schedule, and performance parameters that describe the program over its life cycle.

1-21

Definition – Objective*

The objective value is the value desired by the user, and the value the Program Manager tries to obtain. The objective value represents an incremental, operationally meaningful, time-critical, and cost-effective improvement to the threshold value of each program parameter.

* Reference – DoD 5000.2-R, Chapter 1

1-22

Definition – Threshold*

For performance, threshold shall mean the minimum acceptable value that, in the user’s judgment, is necessary to satisfy the need. For schedule and cost, threshold shall mean the maximum allowable value. If performance threshold values are not achieved, program performance may be seriously degraded, and the utility of the system may become questionable. If schedule threshold values are not achieved, the program may no longer be timely. If cost threshold values are not achieved, the program may be too costly, and the affordability of the system may become questionable.


1-23

Policy on Cost-Performance Trade-Offs*

Cost, schedule, and performance may be traded-off within the “trade space” between the objective and the threshold without obtaining Milestone Decision Authority approval. Trade-offs outside the trade space shall require approval of both the Milestone Decision Authority and the Operational Requirements Document approval authority. Validated key performance parameters (KPPs) may not be traded-off without Requirements Authority approval.


1-24

See Design Considerations in Chapter 5 of DoD 5000.2-R

1-25

Systems Engineering Process Engine

Process Input

RequirementsAnalysis

Systems Analysisand Control

Design Synthesisand Verification

Process Output

FunctionalAnalysis/Allocation

1-26

Systems Engineering Process Inputs & Outputs

Control

Design

Allocation

Requirements

Inputs

• Life- Cycle Needs

• Product Objectives & Thresholds

• Cost & Schedule Constraints

• Best Practices & Standards

Outputs

• Balanced System Solution

• Decision Support Data

• Product Specifications

• Product Architectures

1-27




Process Output


Systems Engineering Requirements Analysis Activities

Process Input

• Establish/refine operational and design requirements

• Develop and refine system level functional and performance requirements and external interfaces

• Provide traceability between user and design requirements

• Establish/refine operational and design requirements

• Develop and refine system level functional and performance requirements and external interfaces

• Provide traceability between user and design requirements

1-28




Process Output


Process Input

• Define lower level functional and performance requirements

• Establish traceability of requirements to higher/lower levels

• Provide design and verification criteria to support integrated system design

• Define lower level functional and performance requirements

• Establish traceability of requirements to higher/lower levels

• Provide design and verification criteria to support integrated system design

Systems Engineering

Functional Analysis/Allocation Activities

1-29




Process Output


Process Input

Systems Engineering

Systems Analysis and Control Activities

- Evaluate and selectalternatives- Document design solutions- Implement risk management process- Maintain data and configurationmanagement- Manage external and internal interfaces- Measure progress and structure reviews

1-30

Key Systems Engineering Activities Include

1. Requirements Analysis - Throughout the acquisition process theprogram office shall work with the user to establish and refineoperational and design requirements that result in the proper balance between performance and cost within affordability constraints. Requirements analysis shall be conducted iteratively with functionalanalysis/allocation to develop and refine customer objectives and requirements, define performance objectives and requirements, and provide traceability among user requirements and design requirements.

1-31

Key Systems Engineering Activities Include(Cont.)

2. Functional Analysis/Allocation - Functional analysis/allocation shall be performed iteratively to define successively lower level functional and performance requirements, including functional interfaces and architecture. Functional and performance requirements shall be traceableto higher level requirements. System requirements shall be allocated and defined in sufficient detail to provide design and verification criteria to support the integrated system design.

1-32

Requirements Characteristics

• Unambiguous- Every Requirement Has Only One Interpretation

• Complete - Includes All Significant Requirements, Functions,Behaviors, Performance, Constraints, andInterfaces

•Verifiable - Cost-Effective Means Exist for People or Machines to Check Product Against Requirements

•Consistent - Requirements Not In Conflict

•Modifiable - Requirements Are Easy to Change Completely and Consistently

•Correct - No Error Exists That Will Affect Design

•Traceable - Origin of Requirement Is Clear

•Design Free - Design Is Left to the Designer

1-33

Words that Don’t Provide Measurable Requirements Criteria

• Fast• Should• May• Extremely

• Under Most Conditions• As Appropriate• User Friendly• Should Fail Gracefully

Notes:

1. Requirements are problem statements.

2. A requirement has three parts – function, performance level, and verification means

1-34

Sample Weapons System RequirementsDatabase (common data)

Number Type Statement Owner

Development,Manufacturing,Verification,Deployment,Operations,Support,Training, or Disposal

Text statement IPT(or name)

1-35

Sample Weapons System RequirementsDatabase (common data Cont. 1)

WBS Parent Req. Child Req.

Element Number NumberIdentifier

1-36

Sample Weapons System RequirementsDatabase (common data Cont. 2)

Related TPMs

TPM Names

AssociatedTrade Studies

Trade StudyIdentifier

Notes

Text

1-37

Sample Weapons System RequirementsDatabase (unique data by WBS)

• Development: Cost, Schedule (Hardware, Software,Facilities, Data, Materials)

• Manufacturing: Primary Technology, Alternate Technology(Availability, Cost, Risk)

• Verification: Method, Description, Date

• Operations: Performance Threshold, Performance Objective,Weight, Space, Power, Cooling

• Support: MTBF, Inspection Cycle, Spares Investment $, Support Equipment Req.

• Training: …

• Disposal: ...

1-38

Sample Weapons System RequirementsDatabase (unique data by WBS Cont. 1)

Software:- Performance (bits processed, speed, response time)- Constraints (standards, data format, language)- Interfaces (software, hardware, people)- Reliability (freq. of failure, severity of failure, recovery of failure)- Supportability (diagnostics, portability)

1-39

Key Engineering Activities Include(Cont.)

3. Design Synthesis and Verification - Design synthesis and verification activities shall translate functional and performance requirements into design solutions to include: alternative people, product and process concepts and solutions, and internal and external interfaces. Thesedesign solutions shall be in sufficient detail to enable verification that requirements have been met. The verification of the design shall include a cost-effective combination of design analysis, design modeling and simulation, and demonstration and testing. The verification process shalladdress the design tools, products and processes.

1-40


4. Systems analysis and Control - System analysis and control activities shall be established to serve as a basis for evaluating and selecting alternatives, measuring progress, and documenting design decisions. This shall include:

a. The conduct of trade-off studies among requirements (operational, functional and performance), design alternatives and their related manufacturing, testing and support processes, program schedule and life-cycle cost at the appropriate level of detail to support decision making and lead to a proper balance between performance and cost.

1-41


b. The establishment of a risk management process to be applied throughout the design process. The risk management effort shall address the identification and evaluation of potential sources of technical risks based on the technology being used and its application, risk mitigation efforts, and risk assessment and analysis. Technology transition criteriashall be established as part of the overall risk management effort.

1-42


c. A configuration management process to control the system products, processes and related documentation. The configuration management effort includes identifying, documenting, and verifying the functional and physical characteristics of an item, recording the configuration of an item, and controlling changes to an item and its documentation. It shall provide a complete audit trail of decisions and design modifications.

1-43


d. An integrated data management system to capture and control technical data and technical manuals, provide data correlation and traceability among requirements, designs, decisions, rationale, and other related program planning, status and reporting such as work breakdown structure, support configuration procedures, and serve as a ready reference for the systems engineering effort. Program managers shall use standard data definitions whenever possible.

1-44


e. The establishment of performance metrics to provide measures of how well the technical development and design are evolving relative to what was planned and relative to meeting system requirements in terms of performance, risk mitigation, and cost.

1-45

See System Life Cycle with Reviewson Page 101 of Systems Engineering Fundamentals

1-46

The “V” Model:Decomposition & Integration

Requirements Functional Design Integration Acceptance Produceanalysis allocation and verification and deploy

ASR SRR SFR PDR CDR FCA SVR PCA

Fully Integrated System Hardware, Software, Ops Procedures

Integrated HWCIs, CSCIs

Each CI

Each Component,assembly, procedure

Each unit

Systemrequirements

Systemverification

Subsystemrequirements: HWCIs CSCIs Configuration

Item Requirements

Ops and SupportHardware AssembliesSoftware Components

Hardwareparts and processesComputer SoftwareUnits

Unit integrationand verification

HW assembly and CSC integrationand verification

CI Integrationand verification

Subsystemintegration andverification

1-47

Definitions from Systems Engineering Fundamentals

System EngineeringAn interdisciplinary engineering management process that evolves and verifies an integrated, life-cycle balanced set of system solutions that satisfy customer needs.

Systems Engineering ProcessA top-down comprehensive, iterative and recursive problem solving process, applied sequentially through all stages of development, that is used to:

a. Transforms needs and requirements into a set of system product and process descriptions (adding value and more detail with each level of development).

b. Generates information for decision makers, andc. Provides input for the next level of developments.

1-48

The Work Breakdown Structure is a Productof the Systems Engineering Process

The program work breakdown structure (WBS) establishes the essential

framework for program and technical planning, cost estimating, resource

allocations, performance measurements, and status reporting. The WBS

shall define the total system to be developed or produced, display the total

system as a product-oriented family tree composed of hardware, software,

services, and data, and relate the elements of work to each other and to the

end product.

1-49

WBS Definitions

Program WBS - A program WBS shall be developed to define initially the

top three levels of a WBS for the entire acquisition cycle of the system

being acquired. A final program WBS shall be prepared by compiling the

elements of the contract WBSs with the initial program WBS.

Contract WBS - From the initial program WBS, preliminary contract

WBSs for individual contracts shall be developed to be negotiated with

the contractors involved. The contract WBS shall be extended to lower

levels by the contractor using as guidance MIL-HDBK-881.

Lecture 1

1-50JSF Requirements Alloc Process.ppt

Sample Work Breakdown Structure (WBS) Tiers for an Air System*

* Mil-Hdbk-881 will be used as a guideline for major acquisition programs (Ref. DoD 5000.2-R)

Air SystemAir Vehicle

AirframePropulsionAir Vehicle Applications SoftwareAir Vehicle System SoftwareCommunications/IdentificationNavigation/GuidanceCentral ComputerFire ControlEtc.

Systems Engineering/Program ManagementSystems EngineeringProgram Management

System Test & EvaluationDevelopment Test & EvaluationOperational Test & EvaluationEtc.

TrainingEquipment

Classroom EquipmentComputer Based Instruction SystemAircrew Training DeviceEtc.

ServicesFacilities

Peculiar Support EquipmentTest and Measurement EquipmentSupport and Handling Equipment

Common Support EquipmentOperational/Site ActivationInitial Spares and Repair Parts

1 2 3 4

Prime Mission System

Fire Control Subsystem

Aircrew Training Device

Fire ControlRadar

Electronic Subsystems 1...nRadar Applications Software

Build 1...nComputer S/W Conf. Item 1...nIntegration & Checkout

Integration, Assembly, Test & CheckoutRadar System Software

Build 1...nComputer S/W Conf. Item 1...nIntegration & Checkout

Integration, Assembly, Test & CheckoutIntegration, Assembly, Test & Checkout

Platform IntegrationSystems Engineering/Program ManagementSystem Test & EvaluationTrainingDataPeculiar Support EquipmentCommon Support EquipmentInitial Spares and Repair Parts

1(3) 2(4) 3(5) 4(6) 5(7)

Aircrew Training Device (ATD)ATD Equipment

Student StationInstructor Operator StationComputer SystemVisual SystemMotion SystemEtc.

Sys. Eng./Prog. Man.System Test & EvaluationTrainingDataPeculiar Support EquipmentCommon Support EquipmentOperational/Site ActivationInitial Spares & Repair Parts

1(4) 2(5) 3(6)

Data

1-51

Specifications shall Conform to the WBS

1. WBS elements may contain both nonrecurring and recurring effort.

2. Integrated logistics support and software shall be accommodated in theappropriate levels of the WBS in accordance with MIL-HDBK-881.

3. Functional cost elements such as engineering, tooling, quality control, andmanufacturing are not WBS elements and shall not be represented as such in the WBS.

1-52

Sample WBS Prime Items (without enablers)

System

SS-1 SS-2 SS-3

SS-11 HW

SS-12PROC

SS-13HW

SS-21 SS-22 SS-31HW

SS-32 SW

SS-121 HW

SS-122 HW

SS-211 HW

SS-212 FW

SS-213 SW

SS-221 HW

SS-222 FW

SS-2121 HW

SS-2122 SW

SS-2221 HW

SS-2222 SW

LegendSS SubsystemPROC ProcessHW HardwareSW SoftwareFW Firmware

1-53

EXERCISE #1

Background: You have recently been assigned to the IPD Team for the Peace Whey program. Peace Whey is a recently approved FMS program which will provide 20 F-16Cs to the Kurdish Air Force (KAF). The specifications for the Kurdish F-16s call for them to be equipped with the Airborne Jamming System (AJS), an electronic warfare system. Your position will be as AJS team leader responsible for the oversight of design and testing of the AJS system, for its integration into the Peace Whey aircraft, and for the AJS lab and flight testing verification. In addition, you must act as the interface between the AJS team and the other teams making up the IPD Team for the Peace Whey program, making certain that the program office is supported in its overall coordination and management tasks.

Exercise: Referring to the Statement of Customer Requirements for AJS (Part 1) which you have been provided, develop a Work Breakdown Structure (WBS) for the AJS development and production

task as a part of the overall air vehicle development task.

1-54

AJS Statement of Customer Requirements

Customer: Kurdish Fighter Program (Peace Whey)

Operational Need: Fighter aircraft operating in a hostile environment require extensive electronic countermeasures (ECM) to defeat air-launched and ground-launched threats to the survivability of the aircraft. These ECM systems must be capable of generating and broadcasting radio frequency (RF) energy at sufficient power levels and in appropriate patterns to defeat any threat encountered by the aircraft.

1-55

AJS Statement of Customer Requirements(Cont.)

Description: The AJS shall be capable of installation on a lightweight, high-speed, multi-role fighter and shall be supportable in primitive forward operating bases. The system shall be capable of transmitting radio frequency signal in the microwave frequency range at sufficient power levels and in patterns capable of successfully jamming all identified threats at the required operational range. The AJS system shall consist of the following major components:

1. Core Avionics: Shall consist of the jammer, the radar warning receiver, and the OFP software. Shall be capable of generating the required RF signal in the microwave band at required power levels and of detecting radar emissions from the threat set at the required ranges. 2. RF Switch H/I/J Band: Shall control selection of broadcast frequency bands as required.3. Fire Control Radar Notch Filter: Shall prevent interference of the Fire Control Radar (FCR) by the AJS system.4. Forward Transmit Antenna5. Aft Transmit Antenna and Raydome6. WRD-650D24 Waveguide7. Coaxial Cable

1-56

Schedule:

1. Flight Test: The Safety of Flight(SOF) unit for flight test shall be available for installation 26 months after program go-ahead.2. First Production Delivery: The first production assembly shall be delivered 36 months after program go-ahead.3. Delivery Rate: Delivery of AJS units shall be at the rate of 2 units per month.4. Total Quantity: The total quantity of AJS units shall be 20.

AJS Statement of Customer Requirements(Cont.)

Customer Priorities:1. Power Transmitted.2. Weight3. First production delivery.4. Cost not to exceed $125,000/unit (for 20 units).

1-57

See MIL-HDBK-881

1-58

Cost, Schedule, and Performance RiskManagement

The program manager shall establish a risk management program for each

acquisition program to identify and control performance, cost, and schedule

risks. The risk management program shall identify and track risk drivers,

define risk abatement plans, and provide for continuous risk assessment

throughout each acquisition phase to determine how risks have changed.

Risk reduction measures shall be included in cost-performance tradeoffs,

where applicable. The risk management program shall plan for back-ups

in high risk areas and identify design requirements where performance

increase is small relative to cost, schedule, and performance risk.

1-59

Cost as an Independent Variable (CAIV)

The acquisition strategy shall address methodologies to acquire and

operate affordable DoD Systems by setting aggressive but achievable cost

objectives and managing achievement of these objectives. Cost objectives

shall be set to balance mission needs with projected out-year resources,

taking into account anticipated process improvements in both DoD and

defense industries. This concept has become known as “cost as an

independent variable,” meaning that cost shall be more of an input, and

less of an output, in the process of acquiring DoD systems.

1-60

Cost/Performance Tradeoffs

Life-cycle cost-performance tradeoffs shall be considered in each phase

by a life-cycle cost-performance integrated product team (CPIPT). The

organization and activities of the CPIPT is based on the principle that the

best time to reduce life-cycle cost is early in the acquisition process and

that cost performance tradeoffs analyses shall be conducted before an

acquisition approach is finalized.

1-61

1-62

1-63

1-64

SEMS Interrelationships

1-65

1-66

1-67