To print a PDF copy of this article, click here.
Risks, issues and opportunities are programmatic hurdles for many acquisition personnel. For example, program offices deal with technical risks in the form of technologies that are not mature enough or are unable to provide the same capability in production that was achieved in development. They also deal with cost risks such as an insufficient budget or budgetary cost overruns and program efforts that take longer than scheduled due to requirements growth.
The basics of risks, issues and opportunities will be tackled in this article. But, first, let’s define them.
Risks are those future events that can negatively impact a program either through cost, schedule or performance. We manage risks by developing and implementing a sound, well-coordinated risk management plan and then track risks by plotting them on a 5-by-5 risk assessment matrix (see Figure 1). An important aspect of risk management is prioritizing risks to show where each additional dollar spent on mitigation would make the most sense and give the biggest return. These funds come from within the program budget and thus are extremely limited. We have several options in handling the risk in a program, and these include “buying down” risks with funds to purchase mitigation efforts that lower either likelihood or consequence. A risk has three main parts: a future root cause, a likelihood and a consequence.
Figure 1. Risk Reporting Matrix Format
The future root cause is determined through root cause analysis, which is the most important part of any risk management effort.
Root cause analysis gets to the heart of the risk. Why does the risk exist? What is its nature? How will the risk occur? What should be done about it? All of these questions assist in identifying the root cause. Risk identification and analysis should be done early in the risk management process. In these steps, we determine what could go wrong, the likelihood of the problems, and how bad the consequences could be. The easiest way to determine the root cause of a risk is to break down the system being analyzed into lower-level components and then, based on what has happened before, ask what could go wrong with those components.
For example, let’s say you are developing a previously nonexistent kind of unmanned ground vehicle (UGV). If you break it down into its components, you will find that you have a lot of background information for performing analysis based on the individual components and their histories. If the UGV has armor, you can analyze the armor type and material to determine what types of risks might be caused. If the UGV has a remote control, you can analyze the radio transmitter and receiver components and user input and control functions to determine the risks associated with those types of subsystems and components.
Root cause analysis is about predicting the future likelihood and consequences of a particular cause based on the data that exist about previous, similar cause-and- effect relationships. If there have been similar, earlier causes with similar consequences, we can use various statistical and cause-and-effect analyses to determine the likelihood of those causes recurring and producing a similar effect. This is why gathering data about the performance of a system and its components is so important throughout a system’s life cycle.
Issues are simply risks that have a likelihood of 100 percent. They are no more or less important than risks. This is important because, once it is understood, you can treat risks and issues in similar fashion and prioritize them using the same criteria rather than arguing over whether a risk is an issue or vice versa. For example, you may have a risk that has a 50 percent likelihood based on past years in which your budget was cut by 15 percent. Based on the June 2015 Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, this would be a red, or high, risk with a likelihood rating of 3 and a consequence rating of 5. On the other hand, if you had an issue that meant your schedule definitely will slip by 2 weeks, this would be a green, or low, issue because it would rate a likelihood rating of 5 (for 100 percent likelihood) and a consequence rating of 1. Based on this situation’s analysis, it would make more sense to spend time and money mitigating the budget risk instead of the schedule issue.
Handling Risks and Issues
There are four approaches to risks and issues. They are: avoid, assume, transfer and mitigate. Of these, the most common form is mitigation.
Avoiding a risk or issue involves avoiding the root cause of the risk or issue. For example, if using a certain type of fuel has toxicity risks, then redesigning the engine so that particular fuel type would not be used would avoid the root cause and thus the risk. This is most common when a risk has an extremely high consequence and/or high likelihood.
Assuming the risk or issue involves allowing the potential risk or issue to occur because most likely the consequence is low or acceptable. For example, it would make more sense to assume a risk of which the consequence was $1,000 and the mitigation would cost $50,000. It does not make sense to spend $50,000 to save $1,000.
Transferring the risk or issue involves shifting the consequence to another party or component by shifting the root cause to that party or component. For example, if you had a very high-risk requirement due to a low technical maturity of the components needed to achieve that requirement, you could shift the requirement to the next increment of development to allow time for the technology to mature. There are caveats about transferring risks and issues, in my opinion. I believe that you cannot transfer risk without transferring responsibility. Because of this, it is very difficult to transfer risk to the developing contractor. I believe you can share risk with the developing contractor through contract incentives and warranties. But without transferring the responsibility, you cannot fully transfer the risk.
Mitigation of risk or issue is the method I have seen most often used to handle risks and issues. For mitigation, we take funding from the program and use it to produce opportunities to counteract the root cause of the risk or issue. It is most important that the mitigation counters the root cause and not the symptom of the risk or issue. Otherwise you will be spending funds to plug one hole in a sieve. Mitigation is important to tackle throughout a program’s life and requires being proactive with risk management early in the system life cycle. Mitigation can be used to “buy down” the risk to a lower level such as red to yellow and then possibly green. It is important to try to lower and not try to negate the risk with mitigation.
It also is important to ensure that your mitigation has time to succeed. For example, if you usually leave for work at 7:30 a.m. to arrive at work by 8 a.m., but your car often fails, you may use the bus to mitigate lack of a ride to work (as opposed to servicing your vehicle). If the bus that would get you to work by 8 a.m. leaves at 7:10 a.m., you would need to prepare to drive to work by 7 a.m. to allow enough time to catch the bus if your car fails—not prepare to leave at 7:30 as you would if the car were dependable. You need to plan and schedule for your mitigation strategy to allow it time to succeed.
Let’s now discuss opportunities, which are the positive view of planning whereas risks and issues constitute the negative view. Opportunities are dealt with in a similar fashion to risks: We still use root cause analysis to plan for them. We look at opportunities for positive events to occur and the root causes of those future positive events and prioritize them on a 5-by-5 matrix focusing on likelihood and benefits (instead of consequences). The opportunity matrix allows for prioritization of opportunities so that they can also be handled for future potential benefits.
Opportunities are handled through three main ways: pursue, reject, and re-evaluate. These are the types of possible action for each opportunity. Pursuit of an opportunity means that you accept that the potential for a future benefit is likely enough to warrant spending funds to achieve it.
Rejecting an opportunity means that you have analyzed the return on investment potential for the future benefit and found that it does not warrant the expenditure. This could mean either that the return on investment or that the likelihood of success is too low. Either way, it would be a bad investment.
Re-evaluating an opportunity requires focusing on continually evaluating the potential for success over time. It means allowing more data to be gathered and allowing the likelihood for success to grow over time until the return on investment looks worthy of funding and success seems achievable.
I think there are many exciting ways to deal with risks, issues and opportunities for programs today. The methods are sound when approached responsibly. It is up to every member of a program office to support the risk, issue and opportunity management processes and learn from the Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, as well as the best practices and lessons learned in other programs.
Conroy is a professor of Systems Engineering (Test and Evaluation) in the Capital and Northeast Region of the Defense Acquisition University at Fort Belvoir, Virginia. He holds a doctorate of education.
The author can be contacted at email@example.com.