U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.9.4 Risk Management



Risk management achieves a proper balance between risk and reward. It seeks to understand and avoid the potential cost, schedule, and performance risks to a project. It takes a proactive and well-planned role in anticipating problems and responding to them if they occur. There are uncertainties involved in any project. The only certainty is that, in at least some small way, things will not go as planned. Risk management anticipates and controls these risks.


Risk management starts early in the project, by identifying the full range of potential risks. Analysis selects the most critical ones to mitigate or to plan for. The process continues throughout the project with the monitoring of these potential risks and a well-planned response to correct problems as they occur.


Shows the flow for cross-cutting activity Risk Management Process.  Summaries are described for inputs, constraints, and enablers into the task;  activities of the task; and outputs from the task.  The flow is described in detail in the accompanying text.



Project Plan needs to be examined for potential risks.

Goals and objectives drive the assignment of prioritizing risks.


SEMP defines the systems engineering process.


Stakeholder involvement and outside experts and help identify and prioritize risks.

Program metrics are used for tracking risks.

Decision gates are structured opportunities to check risk levels and mitigate risk.


Risk Management Planis the plan on how risk management will be performed.

Risk Matrix is the graphical representation of the relative probability and consequence of each risk. Risk data may also be represented in tabular form.

High priority risks are the most important risks to monitor.

Risk monitoring is the ongoing process of tracking symptoms of risks.

Risk management is the ongoing process for correcting any impending problems. The process may use descriptive and inferential, parametric and non-parametric techniques.

Process Activities:

Plan Risk Management

Develop a risk management plan as part of the Project plan/SEMP. The plan should include risk assessment, mitigation, and resolution approaches for the project.

Identify potential risks

Stakeholders, project participants, and outside experts first brainstorm to identify potential risks to project's success. These should cover all possible obstacles. It is important to get a broad sample of inputs, since the team faces the greatest risks in areas in which they are not familiar. [See the checklist below for potential risk areas.] Collect "lessons learned" from previous projects to help identify potential risks.

Assess risks

There are two components to risk: the likelihood that an undesirable event will occur and the consequences if it does occur. Likelihood is expressed quantitatively [as a probability percentage] or qualitatively [in terms of categories, such as likely, probable, improbable, and impossible]. Consequences may be expressed quantitatively, in terms of dollars or performance metrics, or qualitatively, in terms of categories, such as catastrophic, critical, marginal, and negligible.

Analyze and prioritize risks

Risk is the expected value of a potential loss, based on reasoning under uncertainty. Qualitatively, risk is represented by positions in a risk matrix. The risk matrix is useful in both types of analysis. The columns represent the likelihood, and the rows the consequences. Anything that falls in or near the "likely/catastrophic" box is high risk. Start in that corner and select the top risks of concern. [See Tip below]

Define approaches to handling the top risks

Identify and evaluate alternatives for handling the top risks. Before the monitoring indicates a problem, there are steps that can be taken to control the high-priority risks, such as: changing things to eliminate them, reducing their likelihood, or reducing their impact. One example is eliminating requirements that carry a high risk but are of marginal value. Another is parallel development. Plan contingencies for the remaining highest priority risks before starting. Then, monitor them regularly.

Monitor risks

Identify metrics for each of the selected top risks. As a management tool, these are the triggers that release contingency funds to address a problem. These metrics must be easy to track and signal a potential or imminent problem. Cost and schedule are always risks. Their metrics are spending and performance to schedule [see 3.8.5]. Set up a schedule and procedure to track the metrics on a regular basis.

Respond per plan, if necessary

If the monitoring indicates a problem, responses should performed quickly, since there is a plan in place. This avoids the common problem of poor decisions and project redirections under the pressure of the moment.

Illustrates where Risk Management occurs in the Vee Development Model.  Risk management planning begins in the Systems Engineering Management Plan section.  Risk management consisting of risk identification, risk assessment, risk monitoring and risk mitigation occurs at the Concept of Operations; System Requirements; High-Level Design (Project Architecture) Subsystem Requirements; Component Level Detailed Design; Software Coding Hardware Fabrication; Unit Testing; Subsystem Verification; and System Verification and Initial Deployment sections.

Where does risk management take place in the project timeline?

Is there a policy or standard that talks about Risk Management?

FHWA Final Rule does not specifically mention general risk management practices to be followed. CMMI provides some best practices in this area.

Which activities are critical for the system's owner to do?

  • Participate in risk identification
  • Review and approve the identified key risks
  • Ensure ongoing risk monitoring
  • Participate in mitigation activities
  • Lead the development of the risk plan

How do I fit these activities to my project? [Tailoring]

The level of each activity should be appropriately scaled to the size of the project. For example, a small project may consider only a few risks and prioritize them qualitatively. The level of intensity of monitoring and mitigation should be appropriate for the project risk. A project that is technically and organizationally similar to previous ones may need only to monitor cost and schedule.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

  • Number of potential risks in each of the higher risk categories [e.g., frequent/catastrophic]
  • Risk monitoring metrics as established in each step

On the project management side:

  • Completion of documentation of risks and their priorities
  • Number of high priority risks with a documented resolution plan

Checklist: Are all the bases covered?

check Is the risk management plan included in the Project Plan/SEMP?
check Have all sources of risks been identified?
  – Technical [e.g., new detectors do not perform as expected]
  – Institutional [e.g., agency data sharing, new regulations, public opposition]
  – Funding [delays or cuts]
  – Environmental [e.g., temperature levels for outdoor field equipment, restrictions on building]
  – Personnel [e.g., loss of key personnel, substandard performance]
  – Commercial [e.g., vendor does not deliver COTS product]
check Were experts and stakeholders queried in all the areas of risk to develop a broad list of credible risks?
check Are the risks prioritized and the most critical ones identified?
check For each high priority risk, are there ways to eliminate the risk? Or, reduce its likelihood and/or impact?
check For each high priority risk, have the symptoms of the problem and a means for monitoring them been identified?
check Are the high priority risks regularly monitored throughout the project?
check For each high priority risk, is there a risk resolution plan?

Are there any other recommendations that can help?

All useful systems incur some risk. The goal is a balance between system performance and risk. That is why the focus is on only the most critical risks. Lesser risks will and should be accepted.

From a management viewpoint, there are four ways to handle risk.

1] Mitigate the risk by allocating contingency funds to its resolution if it becomes necessary

2] Accept a risk that cannot realistically be mitigated, such as an earthquake

3] Avoid the risk by changing the requirements or design

4] Transfer the risk [e.g., to an insurance company or to a developer under a fixed price contract].

Even if a dedicated risk management team is in-place, everyone on the team must be encouraged to identify potential risks. A "shoot the messenger" atmosphere will only allow hidden risks to grow out of control.

Uncertainty is what makes risk management both difficult and essential. There are statistical techniques such as probabilistic decision theory for reasoning under uncertainty. The most basic technique is expected value. Risk is computed as the probability of occurrence multiplied by the consequence of the outcome. Probability is between 0 [minimal] and 1 [certain]. Consequence is expressed in terms of dollars, features, or schedule. Multiplying probability of occurrence and consequence [impact analysis] together gives a risk assessment value between 0 [no risk] and 1 [definite and catastrophic].

Tip.When exact data is not available for expected costs and probabilities. One can get reasonably good results simply by rating risks qualitatively relative in three to five categories in each of impact and likelihood. Below is an example of the matrix used for such an evaluation. The numbers are the order in which the risks are to be considered. Anything that is in the box labeled "1" is the highest priority. In fact, any risk that is both catastrophic and likely indicates a serious system problem requiring a change in requirements or design.

0.4 to 0.7
0.0 to 0.4
0.9 to 1.0
1 3 6  
0.7 to 0.9
2 4 8  
0.4 to 0.7
5 7 10  
0 to 0.4
9 11 12  

A closer look at definitions and examples of consequence and probability ratings

Here are definitions to firm up the consequence levels used in the matrix [from INCOSE Systems Engineering Handbook]. Here the "mission" is the purpose of the system such as traffic management.

Catastrophic: Failure would result in project failure meaning a significant degradation/non-achievement of technical performance.

Critical: Failure would degrade system performance to a point where project success is questionable, for example: a reduction in technical performance.

Marginal: Failure would result in degradation of secondary system functions, a minimal to small reduction in technical performance.

Negligible: Failure would create inconvenience or non-operational impact. No reduction in technical performance.

Here are examples of some of the characteristics that would impact the probability of failure [adapted from INCOSE Systems Engineering Handbook].


  • Existing system, probability is 0.1
  • Minor redesign, 0.3
  • Major change [feasible], 0.5
  • Complex design [technology available], 0.7
  • State of the art [some research done] 0.9


  • Simple design, 0.1
  • Minor increase in complexity, 0.3
  • Moderate increase in complexity, 0.5
  • Significant increase in complexity, 0.7
  • Extremely complex, 0.9

Note that if there are multiple risks. The overall probability will be at least as high as the highest of them. Often it will be even higher.


Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000