Procurement Information Circular
April 28, 1999
PURPOSE: To provide information about a major initiative, Risk-Based Acquisition Management, being led by the Headquarters Office of Safety and Mission Assurance (SMA) and being supported by the Office of Procurement, and to discuss implications to the procurement process.
BACKGROUND: Risk Management is an organized, systematic decision making process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risk to increase the likelihood of achieving program/project goals. Risk management is an essential element of the entire acquisition process. Risk considerations affect the acquisition implementation approach, the selection of sources, the structure of incentive fees, the plan for project surveillance, and even whether or not to proceed with a project. The most important risk area to consider is safety. The Program/Project Manager must provide for continual risk management throughout the life of the program/project. The Office of Management and Budget (OMB) has recently emphasized the importance of risk management in the planning of capital asset acquisition. Furthermore, the NASA Administrator has instructed the Associate Administrator for Safety and Mission Assurance to embed the principles of risk management into project and program management.
GUIDANCE: Existing coverage on risk management in the Capital Programming Guide Supplement to Part 3 of OMB Circular No. A-11 and NPG 7120.5, NASA Program and Project Management Processes and Requirements, is provided verbatim in the enclosures. Pending revisions to the NFS will address considerations of safety, security, and risk management in acquisition strategy meetings, source selections, award fee structures, and project surveillance. Additional policy and guidance are provided in NPD 8700.1, NASA Policy for Safety and Mission Success, and NPG 8715.DRAFT 2, NASA Safety Manual Procedures and Guidelines, which is currently being circulated in draft. Center procurement personnel must become familiar with the concept of risk management as articulated in the enclosures and other references when published, and support the project/program management and SMA communities in implementing risk management throughout the acquisition process.
EFFECTIVE DATE: This PIC is effective as dated and will remain in effect until canceled.
HEADQUARTERS CONTACT: Kenneth A. Sateriale, Code HK, (202) 358-0491, email: firstname.lastname@example.org.
R. Scott Thompson
Director, Contract Management Division
Capital Programming Guide Supplement to Part 3 of OMB Circular No. A-11
Appendix Six/ 69
RISK MANAGEMENT IN THE PROCUREMENT PHASE
Risk management is an organized method of identifying and measuring risk and developing, selecting, and managing options for handling these risks. There are several types of risk an agency should consider as part of risk management. The types of risk include: schedule risk; cost risk; technical feasibility; risk of technical obsolescence; dependencies between a new project and other projects or systems (e.g., closed architectures); and risk of creating a monopoly for future procurement. Risk management is the responsibility of everyone on the IPT. It implies control of possible future events and is proactive rather than reactive. There are four elements of risk management.
1. Risk Assessment. The first step in risk management is to identify and assess all potential risk areas. A risk area is any part of a project where there is an uncertainty regarding future events that could have a detrimental effect on meeting the program goal. Risk assessment continues throughout the life cycle of a program. As the program progresses, previous uncertainties will become known and new uncertainties will arise.
2. Risk Analysis. Once risks are identified, each risk should be characterized as to the likelihood of its occurrence and the severity of potential consequences. Risk analysis will result in a "watch list" of potential areas of risk. The watch list may identify early warning signs that a problem is going to arise. As in risk assessment, risk analysis continues through the life cycle of the program; the watch list should be updated as appropriate.
3. Risk Treatment. After a risk has been assessed and analyzed, the agency should consider what to do about it. Alternatives include:
Transfer. The agency may transfer the risk to the contractor or some third party. It may be appropriate to transfer the risk to the contractor when it is in the best position to exercise effective control and manage the risk within economically reasonable bounds. At other times it may be more appropriate to transfer the risk to a third party (e.g., bonding, insurance).
Avoidance. When looking at the risks of achieving various solutions to an agency's needs, the program manager may determine that the risks of a particular solution are so great that the solution should be removed from further consideration and alternative solutions should be found.
Reduction. Another method for dealing with the risk is to take the necessary measures to minimize the likelihood that it will occur, minimize the damage to program goals should it occur (e.g., contingency plans), or both.
Assumption. The agency may chose to assume the risk if it is in the best position to exercise effective control, the probability of risk is small, or the potential damage is either minimal or too great for the contractor to bear. The decision should depend on whether the expected benefits of the project exceed the expected costs by enough to compensate the agency for assuming the risk. It may assume the risk through differing site conditions clause, or other means. As long as the program manager has done appropriate risk analysis and understands the situation, the agency may take the programmatic equivalent of an "I'll cross that bridge when I come to it" position. Effective risk management makes assumption of the risk a conscious decision rather than an oversight.
Sharing. When the risk cannot be appropriately transferred -- nor is it in the best interest of the agency to assume the risk -- the agency and contractor may share the risk. Such shared risks require extensive monitoring.
4. Lessons Learned. After encountering problems on a program, the IPT should document any warning signs that, with hindsight, preceded the problem, what approach was taken, and what the outcome was. This will not only help future acquisitions, but could help identify recurring problems in existing programs.
NPG 7120.5, NASA Program and Project Management Processes and Requirements
Chapter 4.2: Risk Management
This section will focus on the requirements for establishing effective risk management.
a. Software Engineering Institute at Carnegie Mellon University, Continuous Risk Management Guidebook, 1996, NTIS#: AD-A319533KKG, DTIC#: AD-A319 533\6\XAB, and NASA Continuous Risk Management Course, taught by the Software Assurance Technology Center, NASA Goddard Space Flight Center, NASA-GSFC-SATC-98-001.
b. NPG 8715.xx (NHB 1700.1 (Vol. 1-B)), "NASA Safety Manual Procedures and Guidelines."
As depicted in figure 4-1 (reference a), risk management is a continuous process that identifies risks; analyzes their impact and prioritizes them; develops and carries out plans for risk mitigation, acceptance, or other action; tracks risks and the implementation of mitigation plans; supports informed, timely, and effective decisions to control risks and mitigation plans; and assures that risk information is communicated among all levels of a program/project. Risk management begins in the formulation phase with an initial risk identification and development of a Risk Management Plan and continues throughout the product's life cycle through the disposition and tracking of existing and new risks.
Figure 4-1. Continuous risk management.
a. Risk Management Planning. Risk management planning shall be developed during the formulation phase, included in the Program/Project Plans (see appendices E.3. and E.4. for required content), and executed/maintained during the implementation phase.
b. Risk Management Process. Each program/project shall follow a continuous risk management process as shown in figure 4-2; this process will be iterated throughout the life cycle. The methods and tools may be tailored for each program/project, but the functional areas described below shall be addressed on a continuous basis throughout the life cycle. This process begins with risk identification and an assessment of program/project constraints which will shape the risk policy; e.g., mission success criteria (primary and secondary); development schedule; budget limits; launch window and vehicle availability; international partner participation; legal, security, or environmental concerns; human space flight safety issues; "fail ops/fail safe" requirements; technology readiness; oversight requirements; and amount and type of testing. If an IA has been performed, the program or project shall use the risks identified during the assessment as input. The risk management process continues with risk analysis, planning, tracking, and control. All risks shall be dispositioned before the delivery to operations or the equivalent for a technology program.
NOTE: Communication and documentation extend throughout all of the functions.
Figure 4-2. Description of risk management functions.
c. Risk Management Functions.
(1) Identify. State the risk in terms of condition and consequence(s); capture the context of the risk; e.g., what, when, where, how, and why.
(2) Analyze. Evaluate risk probability, impact/severity, and timeframe (when action needs to be taken); classify/group with similar/related risks; and prioritize.
(3) Plan. Assign responsibility, determine approach (research, accept, mitigate, or monitor); if risk will be mitigated, define mitigation level (e.g., action item list or more detailed task plan) and goal; execute plan.
(4) Track. Acquire/update, compile, analyze, and organize risk data; report tracking results; and verify and validate mitigation actions.
(5) Control. Analyze tracking results, decide how to proceed (replan, close the risk, invoke contingency plans, continue tracking); execute the control decisions.
(6) Communication and documentation. These are present in all of the preceding functions and are essential for the management of risks. A system for documentation and tracking of risk decisions shall be implemented.
d. Primary Risks. For each primary risk (those having both high probability and high impact/severity; e.g., a Risk Assessment Code of 1 or 2, as defined in reference b.), the program/project shall develop and maintain the following information (for program/project approval, include this information in the risk sections of the Program/Project Plans (appendices E.3. and E.4.) and, as appropriate, in the PCA (appendix E.1.):
(1) Description of the risk, including primary causes and contributors, actions embedded in the program/project to date to reduce or control it, and information collected for tracking purposes.
(2) Primary consequences, should the undesired event occur.
(3) Estimate of the probability (qualitative or quantitative) of occurrence together with the uncertainty of the estimate. The probability of occurrence should take into account the effectiveness of any implemented risk mitigation measures.
(4) Significant cost impacts, given its occurrence.
(5) Significant schedule impacts, given its occurrence.
(6) Potential additional mitigation measures, including a cost comparison which addresses the probability of occurrence times the cost of occurrence versus the cost of risk mitigation.
(7) Characterization of the risk as "acceptable" or "unacceptable" with supporting rationale. NOTE: Characterization of a primary risk as "acceptable" shall be supported by the rationale, with the concurrence of the GPMC, that all reasonable mitigation options (within cost, schedule, and technical constraints) have been instituted.