# How is a countermeasure influencing the total risk score?

I'm just setting up a risk management for a project, and I have to admit, that I'm not used to it. That's my table so far.

``````--------------------------------------------------------------------------------
|Identification         |Analysis            |Prevention           |Final Risk |
--------------------------------------------------------------------
|ID|Name |Desc |Reasons |Possibility |Impact |CounterM |Monitoring |           |
--------------------------------------------------------------------------------
``````

I will give scores for the `Possibility` of an occurrence and the `Impact` on occurrence. Placing the risk on a matrix, will show me the raw severity of the risk. I also will define `Countermeasurments` in case of an occurrence and `Monitoring` methods to avoid an occurrence. Both of them, especially `Countermeasure` will logically influence the `Total Risk`. I think about a formula like

Is this reasonable? How would I calculate the Countermeasure value?

## 4 Answers

Codegnome's law states that you should always solve the problem before you automate the solution. You're creating a formula before you define the terms. I recommend that you define countermeasure first, and then think about what formula you want.

You're exploring the notion of inherent and residual risk - Inherent risk is P*I - what is the risk if you do nothing. Residual risk is the risk that remains after you mitigate the risk. This is, quite frankly, more sophisticated than most people's risk management practices. (as far as I can tell). I commend you for the ambition. I'd advise some caution - the chief value of risk management is the discussions it drives, not the sophistication of the modelling. My first two risk programs were elegant, but died because they didn't drive discussion, decisions or actions. I later learned to make my risk management model as simple as the corporate culture would accept.

Sorry - I got more preachy there than I intended. Let me return to your question.

How do you calculate a value for countermeasure? The same way you calculate the values for Probability and Impact. I've done this a couple of different ways; I prefer to use the P & I values. There are some risks that are best attacked by reducing the probability - by manipulating the chance that the event will occur. There are other risks that are best attacked by manipulating the consequence - even if the event does occur, we can reduce the effect.

So I estimate the inherent P & Inherent I and record those. Then I consider my options for manipulating the P & I values and select a set of mitigations/countermeasures and record the residual P&I values, and the resulting residual risk.

One other note - Sometimes it is prudent to record the urgency of a risk - a high risk that I cannot act on for 3 quarters may be less significant than a low risk that I can control this week. I normally record the urgency of risk so that I can identify the actionable risks in the register. I've thought about formally modelling that (PIU), but I've never implemented the notion; my corporate culture isn't ready for that.

Fascinating comment that I will capture to reduce the potential impact of deletion. ". . . As I understand, it theoretically is helpful if I would calculate the residual risk, but if I do this, the risk might be also easier accepted/ignored by the project contributors, due an effective countermeasure. This again would increase the probability of it and distort the analysis"

The probability of an event's occurrence should not be affected by whether the risk has been accepted or not. I'm not entirely sure I understand a situation where acceptance affects probability. Probability should be estimated based on whether the event will occur or not, and residual probability should be assessed on whether the event will occur given the implemented mitigations. If there is a 50% probability that team X will slip schedule by Y days, then logical mitigation is to apply a financial penalty, which will reduce the probability to 20% - if my management is willing to accept a slippage of Y*0.20, that should not affect the behavior of team X.

I'm confused by how acceptance could affect probability - the only way I can imagine this is if the schedule slippage is dependent on what the team thinks they can get away with. In such a case, the risk description should be revised, and a different countermeasure should be chosen - in this case the issue isn't really schedule risk - the risk is that the team is not engaged with the project and if the impact on schedule is controlled, it will come out in quality or cost or some other factor. Although there are ways I could document that in the risk register, in truth, I'd have a private conversation with the relevant manager.

But that is merely a conjecture formed on a puzzling case. I think the general case is a post hoc ergo prompter hoc problem. Study of an event should not affect the probability of that event.

• Thanks a lot for your advice! As I understand, it theoretically is helpful if I would calculate the residual risk, but if I do this, the risk might be also easier accepted/ignored by the project contributors, due an effective countermeasure. This again would increase the probability of it and distort the analysis. Oct 13, 2017 at 10:29
• @HerrDerb A control (what you're calling a "countermeasure") generally has a non-zero cost. So while there may be some cognitive bias to discount a risk that has a potential mitigating control, the reduction in risk only happens if the control is actually implemented. To some extent, it is your job to present the case that Risk X is only reduced by 50% if the project's budget is increased by 25% to cover the costs of the mitigation. Senior management can ignore the data in either case, but it's still your job to communicate the information as accurately as possible. Oct 17, 2017 at 14:02

## TL;DR

Formal risk assessment is both a science and an art, and overly reductive models lead people astray. For example, consider this variation of a loss-expectancy risk model:

Risk models can be arbitrarily complex, and often rely on higher math to model a large set of possible events and controls. There is an entire field of study and a career path involved with formal risk assessment; I would argue that anything beyond the basics is out of scope (except as a possible input) to project management unless there's a defined phase for formal risk assessment along with sufficient subject-matter expertise assigned to the project. Lacking that, the KISS principle applies.

Focus on risks to the budget and schedule. Other risks, unless part of your charter, are generally out of scope.

## Invalid Modeling of Controls

Possibility * Impact - Countermeasures

Your formula is inherently wrong. What you're looking for us something more like a modified model of annualized loss expectancy such that your mitigations reduce both your annualized rates of occurance (ARO) and your single-loss expectancy (SLE) by reducing your exposure factor (EF).

However, as @MarkCWallace has already pointed out, unless you are in a formal audit or risk-management role, the benefits of this complexity are often vastly outweighed by the project manager's core need to document and communicate risks to the project. Simply identifying the risk, and perhaps adding a gut-feel score, is often sufficient (from a project management viewpoint) as an artifact. It is then up to senior management to determine what strategic actions they want to take about the identified risks, including totally ignoring them.

## A More Accurate & Comprehensible Formula

Since you can craft mitigating controls that independently impact ARO, SLE, asset value (AV), and EF, a more realistic risk model looks more like:

Residual ALE = Residual ARO x Residual SLE

Another way to think about this formula is:

``````Residual_Risk =
(ALE - Applicable_Controls) =
(ARO - Applicable_Controls) *
((AV - Applicable Controls) * (EF * Applicable_Controls))
``````

In other words, you can apply controls to almost any piece (and often more than one) of your risk model, and any risk left over is residual risk that you can choose to mitigate, accept, or transfer.

## Forget Everything But Costs & Schedules

From the project management perspective, the central benefit of identifying and capturing risks is to manage risk to the project's budget and schedule, and to hedge against the risk of delivering the wrong thing. Consider the following contrived example.

On a purely pragmatic basis, the risk that John Doe (who is the project's sole source of expertise on embiggening widgets, and has a heart condition) might become suddenly unavailable to the project is a much bigger risk to the schedule than the calculated annualized loss expectancy. The risk that Jane Doe (who has twenty years of experience, but through entrenched sexism is paid \$0.60 on the dollar compared to her male colleagues) might leave the project to work for a company that doesn't discriminate against women is a tangible risk to your budget.

These sorts of risks can be quantified, but the qualitative risks are often easier to discern and much more visceral. It's still not the project manager's job to do more than hoist the risk flag so senior management can ameliorate the risks, but at least you're now focusing attention on risks that have a more tangible set of mitigations. For example, senior management can reduce risks to cost and schedule by adding resources, building cross-functional teams, or increasing the budget to pay people what they're worth.

As a project manager, you can (and generally should) suggest pragmatic controls when you can identify them. However, the choice to implement the controls belong to senior management. If management breaks the project, they get to keep both halves.

If you are defining countermeasure as something you do after impact, which is your contingency plan, then it does nothing to your exposure of your original threat. A spare tire is a countermeasure to a spontaneous tire failure. It sitting in your trunk does nothing to mitigate the failure. Rotating your tires, keeping them inflating to the proper pressure, driving gently, are mitigators that reduce your threat of a tire failure.

Mitigation of a threat would reduce your exposure by either or both reducing probability and / or impact. So it does not make sense to have a formula of P x I - M = exposure. M would become an artificial value instead of a true value reducing either P or I or both. Most risk programs simply reassess the exposure over time, as the mitigation plays out.

In addition, this P and I analysis is a very simple, not very accurate way of showing exposure. In most cases our threats are more a range of impact with a probabilistic curve that sits on top of that range.

Take a heart attack as an example. The range of impact is from no heart attack to very mild, to mild, to medium, to severe, to catastrophic. There is a probabilistic curve that sits on top of that range and it looks different for each of us based on our age, family predisposition, how well we take care of ourselves, etc. Our mitigation does not really change the range of impact but might alter the curve a little bit, making it fatter over the zero and mild part of the impact range.

The P * I = exposure does not really get to this probabilistic analysis and subtracting mitigation from it does not help, either.

Taking your definition into account, countermeasures can not influence risk because when you use countermeasures, there is no risk anymore, it’s a new situation.

But activities taken to reduce the risk influence or probability influence risk (mitigations?). Therefore you usually simply show the risk impact without and with the action.

Risk assessment is often based on goof judgment. Don’t put to much math in it to show science where often just a feeling gives an initial value.

Have a look on qualitative risk assessment. I assume your question targets this (in compare to quantitative risk assessment).