Sitting at a computer or in meetings doesn’t really sound like a risky job, does it? However, the job of an IT Leader is full of things that might go wrong: decisions that may backfire, projects that don’t work, or vendors that cause problems. Technology can fail, security can fail, backups can fail.

We don’t have infinite time or money to mitigate all these risks. We have to accept some.

How should IT leaders think about risk?

Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.

We can’t manage risk if we don’t understand it. In order to understand it, we need to quantify it. Borrowing from the medical & aerospace world, the basic evaluation categories for each risk are:

• Likelihood: how likely is it that the risk will happen? Remember that risks are future possibilities you are considering, not events that have happened.
• Severity: if it happens, how bad will it be?
• Detectability: if it happens, how likely will someone detect it?
• Risk Factor/Risk Score: Multiply the above three numbers together.

Use a simple 1 (good), 3 (medium), and 5 (bad) scale for each of the first three numbers. Mitigate the risks that have a Risk Factor above some threshold. For a deeper explanation, read the Risk Management section in The I.T. Leaders’ Handbook.

You are already familiar with many mitigations: testing, logging, alerts, redundancy, etc. Hopefully you are using them.

By thinking about mitigations through the lenses of Likelihood, Severity, and Detectability, you can make better choices with the limited resources you have.

Here are some examples that might be helpful.

• When dealing with people issues, for example, insufficient business help on a project, you might reduce the likelihood simply by having the conversation at the beginning and communicating regularly about it.
• When faced with a decision between multiple options, apply risk management to improve your decision making. For example, if there are two ways of implementing a project, run a risk comparison.
• Detectability is more useful than you might think. If you can detect a problem before it causes any damage, you might not need to mitigate the likelihood or severity. Use a monitoring tool to watch for problems that can happen anywhere on your network.
• By listing and evaluating the risks (a.k.a. things that can go wrong), you may reduce the worry. When team members raise a concern, make sure it is on the list and being addressed.

The IT world is full of risk mitigation. While you rarely will need the formal method, having a good understanding of the concepts will improve your decision making and help you apply your limited people and money more effectively to mitigate the risks that really matter.