How to formulate risks well for risk analysis?

Question

If I have to formulate goals for a project there's the well established S.M.A.R.T. paradigm. It helps to have goals at the end, from which necessary actions can be easily deduced. It prevents from having goals which can be interpreted differently thus causing a lot of problems with stakeholders and sponsors.

I wonder if there are similar paradigms for formulating risks when doing a risk analysis. I often find myself searching for risks by just mindmapping them over every topic which comes to my mind or doing that together with a team. The amount of theoretical situations and constellations posing risks is often overwhelming. Within an hour of a meeting we wrote down and counted 60 terminal nodes on a mindmap representing some sort of risk in different areas and points of view. I think we are not bad in "risk identification".

The thing is, those "risks" found by mindmapping tend to overlap and are often formulated in a way that they describe sometimes the risk itself, sometimes the cause and sometimes a failed mitigation and mixed cases from all that.

e.g. if I try to assess the risks of cleaning my bathroom (of course so I can skip that this week to reduce overall risk) I find a lot of opportunities where i can stumble on slippery surfaces. I can use inapproriate detergents which are corrosive to my bathtub as well as to my skin, eyes and aspiratory system and even exacerbated by inadvertedly mixing them together. But if I want to break down the "inappropriate detergent" which is maybe more a cause for a risk than a risk itself I get a lot of overlapping risks, because i can harm my skin with different chemicals but those might or might not ruin my bathtub's enamel. That's what I want to name "overlapping risks".

I hope you get my point. I think you can't asses risks in a reliable way if you can't formulate them well. I'd like to have some kind of a touchstone to check, if a risk is well formulated. Same as there is for goals.

Answer 1

You are struggling with the level of abstraction when trying to capture the risk. There is no easy format to resolve this because, and I hate to write this, it depends. The level of abstraction depends on to whom you need to escalate the risk and how you intend to treat or handle it. If the level of abstraction is too high, like driving your car can cause bad things to happen, then the question becomes, how do you handle it in terms of mitigation?

If you take it down too low, like looking at every component of the car that can go bad and then cause some adverse event to happen in your life, then your mitigation would easily overlap.

Your risk statements can be structured like: IF-THEN; CONDITION-CONCERN; AND CONDITION-EVENT-CONSEQUENCE. These are good formats; however, it does not help your level of abstraction. Essentially, you are going to have to draft the risk you think there is, and then move to the next step to analyze it and come up with a handling strategy. I think what you will find is that, as you go through the next steps, you'll discover if you have to break the risk down and create two or more risks from the one or you could collapse two or more risks into one as you discover they have the same mitigation strategy.

This is the art of risk management. No easy answer but I think it gets easier if you don't overthink it and make it simple. At the end of the day, risk management is about navigating rough waters, not about how cool your risk log looks.

Answer 2

preface: David Espina's answer is correct and is the best first option. This is a hard problem; there are so silver bullets/simple answers. At least to my mind, this is where risk managers (should) earn their money. Simply listing risks and entering them into a risk register is OK, but in my opinion both the value and the satisfying intellectual challenge of risk management is the analysis to understand the nature of the risks. In my opinion, the value of risk management isn't actually the risk register or the risk mitigation; the value of risk management is the additional understanding of the business processes that emerge from the risk analysis.

In my experience, some of the overlap can be eliminated through structure and triage. As you begin to record risks in a register (particularly if you structure the risks as @DavidEspina recommends) you'll recognize similarities and reduce overlap. You'll also begin to calibrate internal, instinctual thresholds about which risks are likely to be actionable - which need formal analysis, and which can be tabled for the future. Those are side effects of the kind of disciplined analysis mentioned by Mr. Espina. (I've actually never been fond of categories - many swear by them, but I find them to be an anti-pattern that inhibits thorough thought.)

You may wish to take a look at FAIR (Factor Analysis of Information Risk) - fair is specific to information risk management, not project risk management, but they do address the "overlap" problem - not perfectly, but reasonably well. FAIR has a lot of factors, but the hierarchy allows you to concentrate on the most general factors, and to ignore the lower level factors that don't manage the overlap.

Answer 3

You are mixing two different processes in the overal risk management super-process: Risk Identification and Risk Analysis. I'd recommend you my book but it's in german so probably not useful to you. In very short:

In Risk Identification you systematically assemble all the risks that face your project, system or other subject of risk management. This is an unsolved problem in both information security (my field) and project management. There are a number of approaches to help you, such as SWIFT (Structured What-If Technique) or in more narrow fields there are threat catalogs and asset mappings. But the short is that no one has yet found a systematic approach that guarantees completeness. Some people (including me) are working on various ideas towards that goal, but for the moment your approach to finding the risks seems no worse than any others.

Risk Analysis is the step of quantifying (ideally, don't be a moron, do quantitative analysis, see Hubbard's excellent two books on the subject) or otherwise dissecting the risk to understand how risky it actually is. Your question is towards the beginning of this process:

Before you can put numbers to a risk, you need to express it. Since you have multiple risks, you need to find a consistent, abstract, unified expression that can describe all your risks in a way that allows comparisons. FAIR (already mentioned in another answer) is one approach to do that, there are many others.

In information security, we have a few standard "descriptors" - confidentiality, integrity, availability. Or the Parkerian Hexad. Or any other variation. You want to find a similar set of descriptors for your field to describe qualitatively what the impact of a risk is.

For your bathroom that might be "health risk", "furniture damage" or "accident risk". A risk could fall into multiple categories.

For a project risk, you could have categories such as "delivery delay", "quality reduction", "employee motivation", "customer satisfaction", etc. Again, a risk could fall into multiple categories.

This covers your "overlap" problem. You can now assess the impact in the various categories to prioritize your risks.

It is normal that a risk has more than one kind of impact. In FAIR where everything is summed up towards a business impact in money, we anyways identify how much a risk impacts productivity, or reputation, or causes response costs, etc.

The change I would recommend to your process is to identify your categories or descriptors first and then match your risks into those categories instead of collecting the risks and then somehow trying to find overlaps or commonalities. If you know what you're looking for, you will find it relatively easy to categorize the risks you find. And if something doesn't fit into any category, you can always expand your categories.

Answer 4

As others have pointed out, this is a difficult subject and few people get it right all of the time. I won't go into the theory as others have expressed it far better than I could, however from a practical perspective I suggest the following.

A framework that we used in a large financial institution was to document risks in the format:

• There is a risk that.... (something happens)
• Caused by.... (a specific item)
• Leading to.... (an impact to the project or the business)

So in your example

• There is a risk that the bathtub will be damaged
• Caused by chemical damage from the cleaning products used - individually or in combination with each other
• Leading to costs being incurred to repair or replace the bathtub to make it usable again

Then you can develop a risk mitigation strategy to accept, reduce, or transfer the risk based on your risk appetite and the likelihood and impact of the risk.

If you can't express them using the agreed format, you should look again at the proposed risks, and decide whether the "risks" from your analysis are genuine risks, or outcomes in the event of the risk crystallising, or just fears and concerns.

I would suggest that you avoid being too specific in your initial statement of the risk (for example, don't list all of the potential cleaning products), although you should then record the details and mitigating factors as part of the ongoing analysis of the risk.