# Presentation: 900685

## Risk Based Acquisition Management (RBAM)Training 

## What This Training Includes

- Definitions
- Why we do RBAM
- Relationship between RBAM and the Procurement
- The RBAM process
- Risk Acceptance
- For further assistance ...

## Definition

- What Is RBAM?
- Risk Based Acquisition Management (RBAM) is an organized and methodical process for managing risks associated with procurements.

## Definition

- Risk
- Risk, for our purposes, is a combination of the probability and severity of an undesirable event occurring during a process, program, or project (in this case, a procurement).

## About RBAM

- 	The purpose of RBAM is the management of risk
- 	The purpose of this training is to help with that risk management
- 	This training provides a tool for, and illustrates the application of NASA’s standard risk management practices to procurement

**Notes:**
Now, What does this mean in English?

Every Program has risks, and they don’t begin after a contract is awarded.  Many programs are continuations of research activities, or previous Engineering Services Contracts.

So obviously, we have some knowledge of Risks that are associated with a contract, but our fallacy has been not identifying these risks to our contractors.  This allows risks to become “problems” without giving the opportunity to proactively mitigate those risks.

## Why We Do RBAM

- To reduce the risks associated with a procurement, thereby increasing the chances of success of the procurement
- Risk Management is a lot of what managers do
- Various regulations, policies, and guidelines require it

## Agency Risk Management Requirements

- NPG 7120.5B, NASA Program and Project Management Processes and Requirements, provides basic risk management requirements and guidance
- NPG 8000.4, Risk Management Procedures and Guidelines, provides additional information for applying risk management to programs and projects as required by NPG 7120.5B
- NASA FAR Supplement 1807.105 requires discussion in the Acquisition Plan of project/program risks and actions taken to manage those risks.

**Notes:**
The major Agency RM documentation sources are:

NPD 7120.4 – PM Management Systems

NPG 7120.5 – Section 4.2 (Risk Management)

NPG 8705.XX (DRAFT) – Amplifies NPG 7120.5

##  Risk Management Requirements

- 	Fundamental Risk Management Requirements
- 	Program and project decisions shall be made on the basis of an orderly risk management effort, and Project/Program Management has overall responsibility for risk management
- 	Risk management planning will be developed during the project/program formulation phase, included in project/program plans, and executed during the implementation phase
- 	Risk management includes identification, assessment, mitigation, and disposition of risk throughout all phases of the project:
**Requirements Development, Acquisition Strategy Development, Solicitation Development, Source Selection, Post-Selection**

**Notes:**
When you review these documents in detail, they essentially boil down to five (5) RM requirements:

Orderly RM Process
Continuous for all project phases 
Formulation
Approval
Implementation
Disposal
Project Manager has overall RM responsibility
RM Planning is required early (and documented in RM Plan)
Current lists of prioritized risks

## Risk/Project Management Relationship

**Notes:**
Many people feel that Risk Management is:

A one-time, check the box activity
An add-on to the Project Management process

In fact, this chart shows that Project Managers are concerned (manage) risks in all kinds of areas that relate to their projects:

Cost, Schedule, Technical Performance
Safety
Security
Management Factors

In essence, Project Managers are RISK MANAGERS!

## The Risk Management Process

- Identify hazards and concerns
- Analyze hazards
- Probability, severity, risk classification, time frame
- Plan hazard controls
- Accept, mitigate, or “redesign” to eliminate
- Track (and pass on to COTR if implementation risks require action during the term of the contract)
- Control and verify (follow through on the above steps)
- This is an iterative process.  Repeat as necessary throughout the acquisition.

**Notes:**
Now, What does this mean in English?

Every Program has risks, and they don’t begin after a contract is awarded.  Many programs are continuations of research activities, or previous Engineering Services Contracts.

So obviously, we have some knowledge of Risks that are associated with a contract, but our fallacy has been not identifying these risks to our contractors.  This allows risks to become “problems” without giving the opportunity to proactively mitigate those risks.

## Apply Continuous Risk Management

- Needs sometimes change/evolve
- New issues are recognized or added
- Old Requirements may disappear or be resolved
- Document and move on
- Periodically review what you have done, and update if required.

## Hazard Identification

- Use past experience
- Use existing risk lists
- Brainstorm
- During other functions, if hazards are identified, add them to the hazard list so they don’t get overlooked.

**Notes:**
We have used the work RISK several times

There are many definitions of risk

The first definition is probably a good starting point.

The NPG 7120.5 definition (used in projects) is how we approach project risks at KSC

## Hazard Documentation 

- Effective Risk Management requires documentation and tracking of hazards.
- A spreadsheet format is provided with this training to assist in documenting, evaluating, and tracking hazards to closure.
- Refer to the companion Excel Spreadsheet
- This spreadsheet may be tailored, thinned, supplemented, or otherwise modified to suit your specific procurement.

**Notes:**
Now that we have established how the CRM process works, let’s talk about how this involves the acquisition process 

Procurement Notice 97-46 (Risk Management) is currently published in the Federal Register as an interim rule to the FAR Supplement

Requires risk management consideration during the acquisition phases

## Hazard Evaluation

- Look at the hazard matrix on the spreadsheet
- Evaluate and modify as required the hazard assessment codes for non-personnel hazards
- Estimate the severity of the hazard
- Estimate the probability of the hazard occurring
- Consider when you need to deal with the hazard
- Put it on the schedule, if need be

**Notes:**
Here are some quotes from some people who think it is smart to assess risk earlier in a Program’s life cycle, the first is the Mars Program Independent Assessment Team

The second is from Dan Goldin, who I personally  had a chance to hear first hand a couple of weeks ago at Wallops express his concern.

## Risk Mitigation

- After hazard evaluation, determine whether mitigation is appropriate (Consider the hazard level, the level of sign-off required, and the various costs associated with the decision.)
- If appropriate, determine the preferred mitigation
- Plan how this will occur, and document the process or pat forward.
- If mitigation is being applied, then re-evaluate the hazard for probability, severity, etc.
- Determine whether you have done enough

## Hazard Acceptance

- If the determination is to accept the hazard:
- Determine the required acceptance level for the hazard
- Get the required sign-off early (these don’t always get approved)
- Consider getting early buy-in from required signatory before going to far.

## Tracking

- Each hazard should have an assigned “owner”
- Track all hazards using the hazard spreadsheet provided, through closure and project completion
- Hazards cannot be forgotten until the project is complete; they may be affected by other changes on the procurement
- Hazards are only closed out when implementation is complete

## Verification of Implementation

- Periodically review the spreadsheet and verify as each hazard mitigation is implemented.
- Deciding on the mitigation is only the beginning.
- Assign an “owner” to each hazard, to ensure that it will be dealt with.

## Passing the Buck

- In each case you must identify the hazard and, if applicable, the mitigation,
- ...but you do get to pass the buck for implementation if:
- The hazard and its mitigation occur during the implementation phase of the procurement (operation of the contract)
- If so, turn the hazard list over to the COTR when the contract is signed, making particular note of those items that require action by the COTR.

## RBAM Responsibility

- RBAM is the responsibility of the SEB/SEC as a whole
- Performance of this responsibility generally works best if:
- The hazard list is regularly reviewed at SEB SEC meetings
- One person is assigned to maintain the hazard list, etc.
- It is done regularly, using a standard procedure
- Everyone is aware of the process for updating hazards assigned to him/her
- Responsibility for each hazard should be assigned to an individual (everyone’s responsibility is no one’s responsibility)

## Define Next Steps

- For each hazard, and for the RBAM process:
- Define what still needs to be completed after each session (SEB/SEC meeting, or RBAM working session)
- Establish dates for next steps
- Determine responsibilities of project team members

## If You Need Further Assistance

- Your instructor for this course, or
- Owen Greulich, Chief, System Safety and Quality Assurance Division, X44117