Response Strategies
The literature on risk management documents the following risk response strategies:
Avoid | Take actions to eliminate the risk or remove its causes entirely. For example, if a project team identifies a high-risk activity that could lead to schedule delays, they may decide to avoid the activity altogether - e.g. to push the implementation of a risky feature to a future release. |
Mitigate | Take actions to reduce the likelihood or impact of the risk. This may include implementing preventive measures, enhancing project controls, or developing contingency plans to address potential threats. |
Transfer | Shift the risk to a third party, such as an insurance provider or subcontractor, through contracts or insurance policies. This strategy is commonly used for risks that cannot be avoided or mitigated effectively by the project team. |
Accept | Acknowledge the risk and its potential impact on the project, but choose not to take any specific action to address it. This strategy is appropriate for risks with low likelihood or impact that are deemed acceptable within the project's risk tolerance. |
Opportunities (sometimes called “positive risks”) are similar to risks, in that a project may take measures in response to them. In this case, the measures are not designed to lessen the impact of the risk but rather to increase the benefits of the opportunity. The literature documents the following opportunity response strategies:
Exploit | Take actions to maximize potential benefits. This may include reallocating resources, adopting innovative approaches, or leveraging external partnerships to capitalize on identified opportunities. |
Enhance | Take actions to enhance the likelihood or impact of the opportunity. This may include investing additional resources, developing new capabilities, or expanding the scope of the project to realize the potential benefits of the opportunity. |
Share | Collaborate with external parties to distribute or transfer the benefits and opportunities associated with an opportunity. This strategy is typically applied when the organization or project can't fully capture the benefits on its own or when sharing the opportunities with external entities enhances overall success. |
Accept | If the benefits or the probability are very small, the opportunity can just be accepted without taking any actions to increase its probability or benefits. |
Modelling Response Strategies in Jira
The following sections present different ways of modelling Risk and Opportunity Response Strategies. The advantages and disadvantages of each are presented. Three of the models suffer from a common drawback resulting from a limitation in the Jira Query Language (JQL).
The models are based on the assumption that there are two issue types, “Risk” and “Opportunity”. Associated with them are two issue types for measures, “Risk Measure” and “Opportunity Measure”.
1) Modelling responses with a custom field on the measure issue types
The solution here is very simple: Single-select custom fields are created with names like “Risk Response” and “Opportunity Response”. They are associated with the Risk and Opportunity issue types. The options for the custom fields are specified according to the above tables. When a Risk Measure or Opportunity Measure is created and linked to an associated Risk or Opportunity, the appropriate value for the custom field is set.
A big advantage of this model is the ease of implementation. Another plus is that it lends itself to simple queries. For example, to identify, say, risk mitigation measures, one can use the simple JQL query: "Risk Response" = Mitigate.
Another advantage is that measures with different responses can be linked to the same risk or opportunity. For example, in the initial stage of analysis, it may be unclear if the correct response is to avoid or mitigate. So two measures can be created with different responses and linked to the same risk.
A disadvantage of the model is that one and the same measure cannot be associated with different risks or opportunities with differing responses. For example, we cannot represent that a measure mitigates one risk while it avoids another risk. (It is not clear if there is a compelling need to handle this situation.)
Another disadvantage of the model is there is no way to query for risks according to the response. This is because the response information is not in the risk but in the measure: For example, a risk that is to be mitigated is a risk that is linked to a measure whose response is mitigation. But the only JQL construction to query by linked issues is the JQL function LinkedIssues(), which has two significant limitations: 1) It requires an issuekey as parameter. This means it is only useful for finding linked issues for a given issue. It is not a general way to query for issues according to their links. 2) It does not provide any means to check for conditions on the linked issues - e.g., that the Risk Response of the linked measure is Mitigate.
2) Modelling responses using different measure issue types
This is similar to solution #1, except that instead of using custom fields we use different measure issue types, one for each response: Risk Avoidance, Risk Mitigation, etc. While this is a simple solution, and has the same advantages and disadvantages as #1, the required number of issue types (eight in all) would not be a normal use of Jira and the model will not be considered further. It should be recognized that issue types are global in a Jira installation, meaning that any user that creates an issue sees a drop down containing all issue types. To expand this list by eight issue types, all devoted to one specific use case, is unlikely to be acceptable.
3) Modelling responses with a custom field on the risk and opportunity issue types
The solution here is similar to solution #1, except that the custom fields are associated with the Risk and Opportunity issue types, not with the Risk Measure and Opportunity Measure issue types.
One significant disadvantage of this model is that it is impossible to associate measures with different responses to the same risk or opportunity. This is an advantage of solution #1.
The model also has an analogous problem with querying as #1, due to the limitation of the JQL function LinkedIssues(). In the case of #1, we can’t query for risks according to response, while in the case of this model we can’t query for measures according to response - i.e. that the Risk Response of the linked risk is Mitigate. It is probably more useful to be able to query for measures according to response than to query for risks or opportunities according to response.
4) Modelling responses using link types
Instead of using custom fields or multiplying issue types, we can model response strategies using different link types. For example, we create a link type “mitigation” with the outward description “is mitigated by” and the inward description “mitigates”. That is, we say that a given risk is mitigated by a given measure, while the measure mitigates the risk.
This solution is very attractive at first appearance. Users need to link measures to risks or opportunities anyway. So, if by simply selecting the appropriate link description, they can at the same time indicate the response strategy, it seems like a way of saving time. It also allows measures to be shared by different risks or opportunities with different responses. For example, by linking a measure to two different risks, a user could indicate that the measure mitigates one risk while at the same time it avoids another risk.
The model also solves the problem of how to query for measures or risks/opportunities according to the response. This can be done using the JQL pseudo-field issueLinkType. To query for risks being mitigated, the following JQL can be used: issueLinkType = "is mitigated by".
However, similar to the case of model #2, it would not be a normal use of Jira to have so many link types. Link types are also global, so a user adding a link to an issue will be confronted by a drop down containing all link types. To expand this list by eight link types, all devoted to one specific use case, is unlikely to be acceptable.
Recommendations
Model #1 is likely to be the best solution unless the limitation on querying is felt to be decisive. In this case, model #4 would be a good solution, despite the inconvenience of having so many link types.