Risk Treatment

Organizations managing risks follow many different protocols for treating risks. Depending upon positive risks and negative risks and the extent of risk response planning, there are various ideas. The following identifies a few good practices that are applicable regardless of the industry or the product. With in the context of SpiraPlan, this article focuses on two major elements. This involves how we are treating the risks with mitigations available in SpiraPlan and how effectively we are monitoring the risks treated as part of the risk monitoring and control. 

Good Practice 1 - Treatment Options by the Risk Status

When risks are analyzed, evaluated, and are listed as open, they need to be treated. Having risks in these stages without adequate risk treatment options means we are not taking risks seriously. So, one of the easiest and fastest way to track risk treatment is by looking at the number of risks in each stage of the risk management lifecycle and count the number of risk treatments available within these stages. 

Treatment Option Evaluation SQL Query

Given below is the SQL Query. 

select 
  rs.name, 
  count(r.risk_id) as RISK_COUNT,  
  count(rm.risk_mitigation_id) as TREATMENT_COUNT
from 
  SpiraTestEntities.R_RiskMitigations as RM
right join SpiraTestEntities.R_Risks  as R on 
  r.risk_id = rm.risk_id
join SpiraTestEntities.R_RiskStatuses as RS on 
  r.risk_status_id = rs.risk_status_id
where 
  r.project_id = ${ProjectId} and 
  r.is_deleted = False and 
  rs.name not in {'Identified', 'Closed', 'Rejected'}
group by 
  rs.name
order by  
  rs.name

Query Explanation

  • In this select clause, we are counting the number of risks as risk count and the number of mitigations available as treatment count within each risk stage that are filtered in the where clause
  • We apply right join on risks to bring risks identified that may not have risk mitigations identified
  • We bring the risk status in the next join so that we can eliminate risks by named statuses in the where clause
  • The criteria applied in the where clauses are straightforward
  • Please note that we eliminate "identified" as risks identified may not have been completed analyzed or evaluated for risk mitigations; but, we do not exclude analysis as some smaller organizations include evaluation as part of the analysis; but, we exclude rejected and closed that does not require the monitoring required on treatment options

Query Output and Graph

Given below is the data and graphical output. 

Risk Treatment Good Practice 1 - Risk and Treatment Counts

Graph Interpretation

  1. The analyzed has 3 risks with risk mitigations. For a start, this is good to begin with. Since don't have the risk exposure evaluation as part of the mitigations put in place, this graph gives time to think through these risks based on their risk exposure.
  2. The evaluated has 1 risk with 1 risk mitigation. This may require more attention because risks that are evaluated to be important will most likely have more than one risk treatment options. 
  3. The open risk warrants more attention as it does not have any treatment option at all. If time is critical, then, this risk will be pressing.
  4. Please use the "Risk Summary" widget, which represents the risk heatmap, in the product dashboard to dig deeper based on risk exposure score

 

Good Practice 2 - Watching Risk Monitoring Anti-Patterns

As part of monitoring risks, there are numerous things that a risk manager or anyone involved in monitoring the risks can check. This can involve a number of anti-patterns such as the following.

  1. Mitigations Not Updated in 2 Weeks
  2. Mitigation Review Unaligned with Risk Review
  3. Mitigations with Past Review Date
  4. Risks without Control Tasks
  5. Risks with Unassigned Control Tasks

Risk Monitoring Anti-Pattern Query

select RMP.ITEM, RMP.ITEM_COUNT from 
((select "Mitigations with Past Review Date" as ITEM, count(RM.RISK_MITIGATION_ID) as ITEM_COUNT
from SpiraTestEntities.R_RiskMitigations as RM
join SpiraTestEntities.R_Risks as R on R.RISK_ID = RM.RISK_ID and R.IS_DELETED = False
where RM.REVIEW_DATE < CurrentDateTime() and RM.IS_DELETED = False and R.PROJECT_ID = ${ProjectId})
union
(select "Mitigations Not Updated in 2 Weeks" as ITEM, count(RM.RISK_MITIGATION_ID) as ITEM_COUNT
from SpiraTestEntities.R_RiskMitigations as RM
join SpiraTestEntities.R_Risks as R on R.RISK_ID = RM.RISK_ID and R.IS_DELETED = False
where DiffDays(RM.LAST_UPDATE_DATE, CurrentDateTime()) > 14 and RM.IS_DELETED = False and R.PROJECT_ID = ${ProjectId})
union
(select "Mitigation Review Unaligned with Risk Review" as ITEM, count(RM.RISK_MITIGATION_ID) as ITEM_COUNT
from SpiraTestEntities.R_RiskMitigations as RM
join SpiraTestEntities.R_Risks as R on R.RISK_ID = RM.RISK_ID  and R.IS_DELETED = False
where RM.REVIEW_DATE > R.REVIEW_DATE and RM.IS_DELETED = False and R.PROJECT_ID = ${ProjectId})
union
(select "Risks without Control Tasks" as ITEM, count(TK.TASK_ID) as ITEM_COUNT
from SpiraTestEntities.R_Risks as R
left join SpiraTestEntities.R_Tasks as TK on TK.RISK_ID = R.RISK_ID and TK.IS_DELETED = False
where R.IS_DELETED = False and R.PROJECT_ID = ${ProjectId} and TK.TASK_ID is null)
union
(select "Risks with Unassigned Control Tasks" as ITEM, count(TK.TASK_ID) as ITEM_COUNT
 from SpiraTestEntities.R_Risks as R
join SpiraTestEntities.R_Tasks as TK on TK.RISK_ID = R.RISK_ID and TK.IS_DELETED = False
where R.IS_DELETED = False and R.PROJECT_ID = ${ProjectId}  and TK.OWNER_NAME is null)) as RMP
order by RMP.ITEM

Query Explanation

  • In the first subquery, we check for the current project's risks with their risk mitigations where both the risk or risk mitigations are not deleted and the risk mitigation review date is past due from current date
  • In the second subquery, we reuse the first query's logic except that we check if the risk mitigation has not been updated for more than 2 weeks
  • In the third subquery, we evaluate the if any of the risk's review date is older than the review date of any of the risk's mitigations
  • In the fourth subquery, we evaluate if there are any risks that do not have a task associated for controls
  • In the fifth subquery, we evaluate if the any risk has a control task without an assigned owner

Output and Graph

Risk Monitoring AntiPatterns Good Practice Graph and Output

Graph Interpretation

All these patterns indicate work that are not clearly done as part of the product development or project management. The ITEM description is descriptive enough to indicate what needs to be done. The tighter these mitigation and controls are, the better the risk management process will be and its impact on project management or product development.