Communicating Risks: a 3-Part Statement

Each week in the Tech Exec: The Week That Was newsletter I share my thoughts on a topic that I've worked on or discussed with a client, colleague, or within the CTO community. In issue 2023#05 we look at how to communicate risks in a clear, concise, and consistent format.

Stating risks in a clear, concise, and consistent manner enables more effective communication and risk prioritization.

Why Care?

How many times have you tried to explain a risk and for it not to be understood? How many times have you had to listen to someone talk for many minutes (or more!) to try to grasp the issue that they are trying to tell you? When you are sharing risks with people from outside of your area of expertise this only gets more difficult. Time is wasted and risks are not understood. Imagine if there was an easier way…

The 3-part statement

Formatting the risk into a consistent statement not only forces you to really clarify what the risk is, it also greatly improves its consumption by others.

Because of <a cause>

There is a risk that <an event will occur>

Resulting in <a consequence>

The Single Responsibility Principle (SRP)

Yes, the SRP is one of the SOLID principles, but it is equally valid for many other situations, including communication of risks.

Each risk statement should only be concerned with one thing. This makes it clearer to reason with, prioritize, and mitigate.

The Cause

What is the reason that something could happen?

There are many ways to identify both known and unknown causes, and we will cover that in another article. Just try to be as specific as you can. A couple of examples:

• Because of our use of the third party library X…
• Because of our storage of PII in our production db…

The Event

What is the thing that could happen?

A given cause can lead to many different events, and so many risk statements. This is good! Don’t try to consolidate them, and at this point don’t try to prioritize or remove statements. Also, you could have the same event occurring from different causes. Again, capture them all as they may have different priorities and mitigation strategies.

Examples of potential events for the cause “Because of our use of the third party library X…”:

• there is a risk that there will be dependency issues…
• there is a risk that the library will be removed…
• there is a risk that security vulnerabilities exist…

The Consequence

What will the result be if the event occurs?

Again, any given event could result in multiple consequences, so these should become separate risk statements.

Examples of potential consequences for the cause and event “Because of our use of the third party library X, there is a risk that there will be incompatible dependencies…”:

• resulting in an inability to upversion
• resulting in an inability to use other libraries
• resulting in an inability to access all features

Next Steps

With a clear and consistent risk statement format it is now much easier to prioritize which risks to tackle and identify mitigation strategies for them. We’ll look at effective ways to do this in a future article.

The bottom line

Because of unclear, verbose, and inconsistent risk communication,

there is a risk that your most critical risks are not shared, understood, or prioritized,

resulting in severe damage to your business.

What have been your experiences in communicating and prioritizing risks? Please share your thoughts in the comments below, and subscribe to Tech Exec: The Week That Was to get notified when the next article drops.

If you would like to discuss exec coaching or fractional CTO services contact jonathan@knowledge.supply.