Risk Identification is the activity that examines each element of the program to identify associated root causes that can cause failure, begin their documentation, and set the stage for their management. It begins as early as possible in successful programs and continues throughout the program. The Program Management Office (PMO) should develop and employ a formalized risk identification procedure, and all personnel should be responsible for using the procedure to identify risks. The intent of risk identification is to understand what can go wrong by [1]

• Looking at current and proposed staffing, process, design, supplier, operational employment, resources, dependencies, etc.,
• Monitoring test results especially test failures (readiness results and readiness problems for the sustainment phase),
• Reviewing potential shortfalls against expectations, and
• Analyzing negative trends.

Risk Examination

Examination of risks to a program is accomplished through decomposition into relevant elements or areas. To identify risks and their root causes, Risk Integrated Product Teams (IPT) should break down program elements to a level where Subject Matter Experts (SME) can perform valid identification by Work Breakdown Structure (WBS) or Integrated Master Schedule (IMS) line item number. Risks are determined by examining each WBS element and process in terms of causes, sources, or areas of risk. During decomposition, risks can be identified based on prior experience, brainstorming, lessons learned from similar programs, and guidance contained in the program office Risk Management Plan (RMP). The examination of each element and process against each risk area is an exploratory exercise to identify the critical root causes. The investigation may show that risks are interrelated. [1]

See: Risk Identification Procedures

Risk Root Causes

Root causes are identified by examining each WBS product and process element in terms of the sources or areas of risk. Root causes are those potential events that evaluators (after examining scenarios, WBS, or processes) determine would adversely affect the program at any time in its life cycle. [1]

An approach for identifying and compiling a list of root causes is to: [1]

• List WBS product or process elements
• Examine each in terms of risk sources or areas
• Determine what could go wrong
• Ask “why” multiple times until the source(s) is discovered

Risk Sources

Typical Risk Sources include: [1]

• Concurrency
• Cost
• Funding
• Industry Capability
• Logistics
• Management
• Manpower
• Modeling and Simulation
• Production/Facilities
• Requirements
• Schedule
• Technical Baseline
• Test and Evaluation
• Threats

Risk Identification Procedures

The risk identification procedures outlined below help the Risk Integrated Product Team (IPT), Program Manager (PM) and Systems Engineer identify project risks throughout the life of a project. Procedures include:

1. Risk Integrated Product Team (IPT) identifies a list of potential risk items.  There are various methods of identifying risks. Risk can be identified from:
   • Lessons Learned
   • Subject Matter Experts (SME)
   • Prior Experiences
   • Technology Readiness Level (TRL) determination
   • Programmatic Constraints
   • Brain Storming
   • Work Breakdown Structure (WBS)
2. Risks are determined to be acceptable or not. Not all risk items identified in step 1 are accepted.
3. Accepted risks should be recorded and put into a Risk Register
4. Identify root causes for each identified risk
5. Risk analysis should examine each identified risk to refine the description of the risk, isolate the cause, determine the effects, and aid in setting risk mitigation priorities. (Risk Reporting Matrix)
6. Risk Mitigation Planning should address each risk with action items and due dates.
7. Risk Integrated Product Team (IPT) meets regularly (every 2 weeks) to assess risks and add new risk items, if necessary.
8. Risks are closed when all the actions to close the risk have been taken. Some risk items are closed quickly; others are open for a long time. Some are considered watch items and the action plan doesn’t kick in until certain negative events happen.
9. Closed risks remain in the database for future learning.

Common Risk Identification Methods

• Objectives-based risk identification: Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk.
• Scenario-based risk identification: In scenario analysis, different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk.
• Taxonomy-based risk identification: The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.
• Common-risk checking: In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation.

AcqTips:

• For a more detailed explanation on risk, visit the DoD Risk Issue and Opportunity Management Guidance for Defense Acquisition Programs – June 2015.

AcqLinks and References:

• DoD Risk Issue and Opportunity Management Guidance for Defense Acquisition Programs – June 2015
• [1] DoD Risk Management Guidebook – Section 3.0 – Aug 06 (Outdated)

Updated: 7/20/2021

Rank: G10