RMPR001
Risk Management Procedure
26 September 2012
Risk Management Procedure
Systems Engineering Discipline:
Risk Management
Description:
Risk Management addresses future uncertainties that could endanger achievement of program
objectives and identifies potential problems before they occur so that risk-handling activities may
be planned and implemented to mitigate adverse impacts should a risk be realized.
Risk must be captured within individual programs and initiatives as well as an integrated systems
perspective. Risks may have dependencies to other programs within the Directorate or outside
the organization.
This procedure documents the organization’s enterprise risk management strategy and provides
the details necessary to support the execution of a disciplined and effective risk management
program within the Directorate.
Entry Criteria:
Complete the following before beginning this procedure:

Risk Management Stakeholders Identified
Procedure Steps: (These steps are not always performed sequentially.)
Although the Program Manager is ultimately responsible to ensure risk management activities
are performed throughout the life cycle of any work effort, key roles are identified below as the
lead for certain steps or activities.
1. Program Manager: Plan risk management activities.
1.1. Document the program risk management strategy.
A program unique Risk Management Plan (RMP) is recommended for all programs/projects.
Refer to the Risk Management Plan Template in Attachment 2 of AFMCPAM 63-101, Life
Cycle Risk Management. However, if a program does not prepare a RMP, a documented
strategy or plan for how risk management activities will be conducted throughout the life
cycle of the program must be incorporated into the program’s Life Cycle Management Plan
or Systems Engineering Plan. To be complete, this strategy should, at a minimum, document
the following:
 The specific roles and responsibilities of program team members in the risk
management process.
 The processes used to identify, capture, analyze, handle, and monitor risks within the
program.
 The tools that will be used to execute the risk management strategy.
 The frequency of risk management activities (meetings, reviews, customer briefs,
etc.).
1.2. Resource the Risk Management Plan.
1
RMPR001
Risk Management Procedure
26 September 2012
To be successful, risk management activities must be started early and performed
continuously throughout a program’s life-cycle. The Program Manager should:
 Formally designate a Program Risk Manager
 Establish a battle rhythm of risk management workshops/reviews
 Provide a mechanism for team members to present risks or updates outside of
scheduled reviews
2. Program Team: Identify risks.
2.1. Program Team: Identify risks.
Any Program Team member or stakeholder may identify risks.
2.1.1. Determine risk sources.
Risk sources are the common areas where risks may originate. Risk sources can be
internal or external to the program and in some cases may be both. Additional risk
sources may be identified throughout the program life cycle. Early identification of
sources leads to early identification of risks, and early mitigation plans may preclude
occurrence of or reduce consequences if they occur. Listed below are some typical
examples of risk sources:
 Requirements (i.e., unclear operational needs, attributes, constraints, technology,
or design processes; change frequency, etc.)
 Technical Baseline (infeasible or incomplete design)
 Schedule (unrealistic schedule estimates and/or allocation, concurrency)
 Manpower (inadequate staffing and/or skills)
 Cost/Budget (uncertainty of estimates, funding issues)
 External Factors (facilities, infrastructure, subject matter expertise, etc.)
2.1.2. Identify risk categories.
There are three designated risk categories. These categories identify risks associated with
cost, schedule, or performance. Risks should be examined during all phases of the life
cycle to the extent they impact program objectives. Listed below are the main categories
of risks and some examples:
2.1.2.1. Financial Manager: Identify cost risks.
Identify risks associated to the program’s cost. Examples include:
 Development costs
 Product acquisition costs
 Cost of spare or replacement products
 Product disposition costs that have design implications
 Funding levels, estimates, or distributed budgets
2.1.2.2. Program Manager: Identify schedule risks.
Identify risks associated to the program’s schedule. Examples include:
 Planned activities and interdependencies
 Key events and reviews
 Milestones
 Contract performance (dates and deliverables)
 Human resource availability
2
RMPR001
Risk Management Procedure
26 September 2012
2.1.2.3. Lead Engineer: Identify performance risks.
Identify risks associated to the program’s performance. Examples include:
 Requirements
 Interface and interoperability complexities
 Infrastructure limitations
 Data Conversion
 Analysis and design
 Application of new technology
 Technical performance and operation such as throughput
 Verification and Validation
 Development and Test Environments
 Information Assurance/Security
2.1.2.4. Program Manager: Identify other risks.
Identify any other risks that fall into the cost, schedule, or performance categories.
Program Teams should review all elements of their work breakdown structure to
ensure that all aspects of the work effort have been considered.
For example, the Contracting Officer should lead the identification of any risks
associated with:
 Acquisition strategy
 Contract management
 Competition
In another example, the Customer should lead the identification of any risks
associated with operational suitability or funding availability.
2.2. Program Risk Manager: Document program risks.
It is important to be thorough in this step of the process. One of the keys to writing good risk
and issue statements is to focus on a tangible, measurable event that may occur rather than a
vague statement. Once a risk has been identified, the following minimum information should
be captured:
2.2.1. Identifier: <Program Abbreviation>-<Risk No.> (e.g., ABC-001)
2.2.2. Title: Use a short, meaningful title so that the risk can be easily identified in tables
and standard reporting systems.
2.2.3. Owner: Identify the individual best suited to manage the risk.
2.2.4. Description of the risk: Teams should use the "If, then" logic when documenting
their risks remembering that the “If” is the cause and the “Then” is the effect of the risk
on the project.
2.2.5. Phase: Identify the phase of the acquisition life cycle the risk may impact.
2.2.6. Category (program area): Use this element to place risks into the categories
identified above (cost, schedule, performance, other).
2.2.7. Source: Identify the most relevant source of the risk associated to the root cause
indicated (budget, manpower, requirements, schedule, technology, etc.).
3
RMPR001
Risk Management Procedure
26 September 2012
2.2.8. Initiation Date: Insert the date the risk was identified.
2.2.9. Next Review Date: Insert the date of the next anticipated review.
3. Program Team: Analyze and evaluate risks.
This step answers the question “How big is the risk?”
3.1. Program Team: Analyze risks.
Analyzing risks is a key part of risk management and should involve the entire Program
Team. It includes maintaining a database of program risks so that the most important risks
can be prioritized based on the judgment of the Program Team.
3.1.1. Just as the identification of certain types of risk is the responsibility of the
functional team member that leads that program area, the thorough analysis and
evaluation of those identified risks also remains the responsibility of those functional
leads.
3.1.2. Each risk is evaluated and scored in accordance with the defined risk parameters
identified below. The goal is to identify the highest-priority risks and focus risk handling
resources on them as the program evolves over time. As risk handling steps are put into
place, risk parameters may change over time and therefore frequent adjustments may be
required.
3.2. Program Team: Score risk parameters.
To ensure consistent and rigorous execution and reporting, all programs, without deviation,
must use the standard 5x5 risk matrix, likelihood criteria and consequence criteria to analyze
program risks (see below). Realizing that every risk may have multiple consequences
(performance, cost, and schedule) to be assessed, the matrix should depict the consequence
with the most severe impact. Risk handling plans will be prepared for all Medium (Yellow)
and High (Red) program risks. Parameters for evaluating, categorizing, and prioritizing risks
include the following:
3.2.1. Likelihood.
Likelihood is the current estimate of probability that the risk will occur over the impact
time frame. It is measured in percent and based on professional judgment or historical
data. Chapter 12 of AFPAM 63-128, Guide to Acquisition and Sustainment Life Cycle
Management, identifies values that range from 5% (extremely unlikely) to 99% (almost
certain). The likelihood value will likely change over time as the risk is actively
managed. Use the ratings in Figure 1 below as a guide in assigning the likelihood
ratings:
Rating
5
4
3
2
1
Probability of Occurrence
81 – 99 %
61 – 80 %
41 – 60 %
21 – 40 %
5 – 20 %
Likelihood
Near Certainty
Highly Likely
Likely
Low Likelihood
Not Likely
Figure 1: Likelihood Rating Criteria
3.2.2. Consequence.
4
RMPR001
Risk Management Procedure
26 September 2012
Consequence is an undesirable event or impact which would negatively affect the
program should the risk materialize. Consequence is a subjective ranking made by the
Program Team using past experience, historical data or comparison to other systems.
The primary purpose of the consequence value is to help rank program risks. This value
may change over time as the risk is actively managed. Use the Standard AF
Consequence Criteria for each category of risk (cost, schedule, and performance), as
described within Chapter 12 of AFPAM 63-128, Guide to Acquisition and Sustainment
Life Cycle Management, to assign a consequence value to each risk. See Figures 2, 3,
and 4 below as a guide in assigning consequence levels:
Level Standard AF Consequence Criteria – Cost
5
 For Milestone A-B Programs: >20% increase from MS A approved cost estimate
 For Post-Milestone B & Other Programs: >=10% increase in PAUC/APUC from
current baseline estimate (danger zone for significant cost growth and NunnMcCurdy breach), or last approved program cost estimate
4
 For Milestone A-B Programs: >15% to 20% increase from MS A approved
estimate
 For Post-Milestone B & Other Programs: 5% but <10% increase in PAUC/APUC
from current baseline estimate, or last approved program cost estimate
3
 For Milestone A-B Programs: >10% to 15% increase from MS A approved
estimate
 For Post-Milestone B & Other Programs: >1% but <5% increase in PAUC/APUC
from current baseline estimate, or last approved program cost estimate
2
 For Milestone A-B Programs: > 5% to 10% increase from MS A approved
estimate
 For Post-Milestone B & Other Programs: <=1% increase in PAUC/APUC from
current baseline estimate, or last approved program cost estimate, with potential
for further cost increase
1
 For Milestone A-B Programs: 5% or less increase from MS A approved cost
estimate
 For Post-Milestone B & Other Programs: limited to <=1% increase in Program
Acquisition Unit Cost (PAUC) or Average Procurement Unit Cost (APUC) from
current baseline estimate, or last approved program cost estimate
Figure 2: Standard AF Consequence Criteria – Cost
Level
5
4
3
2
1
Standard AF Consequence Criteria – Schedule
Cannot meet key program or project milestones.
Changes required to the program or project critical path.
Schedule slip; impacts the ability to meet key dates (e.g., PDR, CDR, etc.)
Schedule slip; does not impact the ability to meet key dates (e.g., PDR, CDR, etc.)
Negligible schedule slip
Figure 3: Standard AF Consequence Criteria - Schedule
Level Standard AF Consequence Criteria – Performance
5
Severe degradation in technical/supportability threshold performance; will
jeopardize program success; or will cause a KPP Threshold not to be met.
5
RMPR001
4
3
2
1
Risk Management Procedure
26 September 2012
Significant degradation in technical performance or major shortfall in supportability
with a moderate impact on program success. Technical performance is unacceptably
below the goal; or, no technical design margins available and system performance
will be below threshold values.
Moderate shortfall in technical performance or supportability with limited impact on
program success. Technical performance will be below the goal, but approaching
unacceptable limits; or, technical design margins are significantly reduced and
jeopardize achieving the system performance threshold values.
Minor reduction in technical performance or supportability, can be tolerated with
little impact on program success. Technical performance will be below the goal or
technical design margins will be reduced, but within acceptable limits.
Minimal consequence to technical performance but no overall impact to the program
success. A successful outcome is not dependent on this issue; the technical
performance goals or technical design margins will still be met.
Figure 4: Standard AF Consequence Criteria - Performance
3.2.3. Impact dates.
These dates differ from the date the risk was first identified (initiation date) and the
review dates which were previously documented.
 Document the earliest date the risk could impact the program
 Document the latest date the risk could impact the program
3.2.4. Target Resolution.
Document the date by which the risk is expected or desired to be mitigated or resolved
3.3. Program Risk Manager: Prioritize risks.
The current priority ranking of a risk is relative to all other risks and based on the analysis
performed as calculated using the probability and consequence. Rank 1 is the highest
priority; rank 2 is next, and so on. Risk ranking must always be carefully maintained.
4. Program Manager: Handle risks.
This step answers the questions, “What is the approach for addressing this potential unfavorable
consequence?” and “How do we implement that approach?”
4.1. Program Team: Develop risk handling plans.
Develop a risk handling plan for each risk. A handling plan for a given risk includes
techniques and methods to be used to avoid, reduce, and control the likelihood of occurrence
of the risk, the extent of damage incurred, or both.
4.1.1. Determine handling strategy.
This activity identifies, evaluates, selects and implements options in order to set risk at
acceptable levels given program constraints and objectives.
4.1.1.1. Accept/Assume: assume the level of risk and continue with the current
program.
4.1.1.2. Monitor: take no immediate action, but watch for changes.
4.1.1.3. Research: collect additional information needed for a decision or reduce
uncertainty surrounding risk estimates.
6
RMPR001
Risk Management Procedure
26 September 2012
4.1.1.4. Transfer: shift the root cause elsewhere.
4.1.1.5. Mitigate/control: apply methods aimed at eliminating the risk, or reducing
the likelihood and/or consequence of the risk.
4.1.1.6. Avoid: Eliminate the root cause of the risk (e.g., not performing an activity
that may drive risk).
4.1.2. Develop detailed risk handling steps.
The risk handling plan will describe the approach that will be taken to reduce the
likelihood or consequence of occurrence thus reducing overall risk exposure. Producing
good handling steps requires planning out the following details for each step in your plan.
 Descriptions
 Priority
 Start and due dates
 Potential costs
 Deliverables
 Target Score: the new likelihood and consequence should this response plan be
successful.
4.1.3. Develop contingency plan (fallback plan).
A contingency or fallback plan is a set of actions to take in the event critical risks
materialize. The contingency plan should include, at a minimum, alternative courses of
action, work-arounds, and fallback positions, with a recommended course of action. All
High (Red) risks require a contingency plan (fallback plan).
4.2. Program Manager: Report and Escalate Risks
For all risk reporting, Programs will use the standard 5x5 Risk Matrix and Details Table as
shown in Figures 5, 6, and 7 below.
5
HIGH
Likelihood
4
3
MEDIUM
2
LOW
1
1
2
3
Consequence
7
4
5
RMPR001
Risk Management Procedure
26 September 2012
Figure 5: Standard 5X5 Program Risk Matrix
Rank
Risk Description
Figure 6: Risk Descriptions
Rank
Risk Description
Handling / Mitigation
Target Date
POC
Figure 7: Risk Details Table
Program Managers and Division Directors will follow the criteria depicted in Figure 8 below
to determine when conditions warrant the escalation of program risks to higher authority.
Document the escalation strategy in your Risk Management Plan.
8
RMPR001
Risk Management Procedure
Directorate RMB
26 September 2012
YELLOW
RED
(By Exception)
Division RMB
RED
YELLOW
Program Manager
RED
YELLOW
GREEN
Risk Originator
RED
YELLOW
GREEN
Initial Risk Generated
Figure 8: Risk Escalation Criteria
4.3. Implement risk handling activities.
Implement the risk handling steps as approved by the Program Manager.
5. Program Manager: Manage and track risks.
This step answers the question “How are things going?” The Program Manager must be
proactive and monitor these risks throughout the program’s life cycle.
5.1. Assign responsibility.
Document the name of the person responsible for tracking or managing each risk.
5.2. Monitor risks.
Monitor the status of each risk throughout the program's life cycle.
5.2.1. Update Status.
Systematically review initially identified and baselined risks. Analyze them to determine
their status. Archive risks when they are no longer present or have been closed.
5.2.2. Update handling step progress.
5.2.3. Update contingency plan (fallback plan).
5.2.4. Maintain risk history.
Maintain a historical events log on each risk. This log is the recording of events about
the risk that might be useful in evaluating its importance or in justifying specific actions
that were taken. For instance, external events might occur that caused a change to the
9
RMPR001
Risk Management Procedure
26 September 2012
impact or probability of the risk. It can serve as a repository of thoughts and decisions
that affect how the risk was perceived, mitigated, and/or retired.
5.2.5. Report Status to Management.
Program Managers must perform periodic reviews of program risks. The Program
Manager is responsible for briefing senior management and senior functional staff
members to provide visibility into the program’s overall risk exposure.
5.3. Monitor and control the risk management process.
Include all members of the Program Team in monitoring and controlling risks. Implement
corrective actions or mitigation actions as required. Use metrics to help in monitoring and
controlling risks. Recommended metrics may include the following:
 Number of risks identified, managed, tracked, and controlled; include a breakdown
based on priority
 Risk age; risk growth within the program
 Risk exposure and changes to the risk exposure for each assessed risk
 Change activity for the risk mitigation plans (e.g. processes, schedule, funding)
 Impact timeframes/dates (initiation date, trigger dates, expiration dates, target
resolution dates, etc)
 Occurrence of unanticipated risks
 Risk categorization volatility
 Comparison of estimated vs. actual risk mitigation effort and impact
5.4. Continuously identify new and potential risks.
As the program progresses, new risks will become a threat to its success. When they do,
follow this procedure to identify, document, analyze, mitigate, and track those risks.
Exit Criteria:
The following are a result of completing this procedure:



Risk Management Plan or Documented Risk Management Strategy
Updated Risk Management Tool:
o Identified, analyzed, and documented program risks
o Handling plan steps for all documented risks
o Contingency/Fallback plans for all High (Red) risks
Escalated Risks (as appropriate)
10