A Brief Introduction to Risk Management

4-5min Read
Should you? Or Shouldn't You?
An illustration of a rocket ship trying to avoid astroids

Defining Risk

In classical risk management, risk is defined as follows:

risk (r) = threat (t) * vulnerability (v) * impact (i)

... and so performing a risk assessment starts by attempting to measure or rank threats, vulnerabilities, and impacts for specific scenarios.

For threats, we consider the 'threat landscape' by asking whether there are events that could occur that would have a negative impact on our project. We then consider whether we're vulnerable to those threats i.e., could they be realized in our particular case? And then we consider the impact those threats would have if realized.

If any of the values in that calculation are 'zero' — then there is no risk.

So for example, if we decided we wanted to calculate the risk of aliens landing on earth and abducting a large number of project stakeholders, we'd have to assess these three areas:

  1. Threat: In terms of threat - how likely is this to happen? Has it ever happened before?, and if so what is the distribution or frequency of this threat?
  2. Vulnerability: In terms of vulnerability - are we specifically vulnerable to this threat? Would they really take our stakeholders?
  3. Impact: In terms of impact, what would be the consequences for us if this threat was realized?

For now, we're probably okay with saying that the threat distribution is calculated at zero, and therefore risk (r) is zero as well.

What about this one. Have key personnel ever left a project? What would happen to the project if a key stakeholder, or senior project team member left? So the question is - what's the threat distribution of this event? Have key personnel ever left any project in the world? Is there a risk that key personnel would leave our project? What would be the impact to the project if they left? This one is starting to look a little more plausible in terms of threat distribution, vulnerability and impact, and so perhaps it's worth including in something we'll call a 'risk register'.

A Risk Register

A risk register is a simple table of risks. Basically, we describe a series of threats, vulnerabilities, and impacts, each on a single row in the table. And we give each entry a score and calculated 'r' value and then sort the table in descending order based on 'r' values (i.e. the greatest risks at the top of the table). And then for each item in the risk register, we describe what action we'll take, either at the time, or in advance in order to manage the risk.

In systems — web or application development, content solutions, etc., we tend to subdivide and group the risks in our risks register into three broad categories, namely:

  1. Requirements risks including political risks, risks in requirements analysis, expectations etc.,
  2. Resource risks including finance, human resources, and skills risks and,
  3. Technological risks.

The biggest risks in the type of projects we participate in are usually requirements and resources risks. In addition to our early questions about capacity and expectations, our initial assessment of these risks usually starts with very basic questions like, "have all of the project team members' holiday schedules or other commitments been taken into account in the project plan?".

And Then What?

With a basic understanding of risk management and your `risk register` to hand, it's time to decide what to do. In risk management, there are three broadly agreed strategies for dealing with items that appear in your risk register and they are:

  1. Avoid: In this case, you simply avoid doing whatever it was that generated the risk 'r' value. Stop doing it, remove it, or do whatever it takes to get the risk item out of your register without any major commitment of resources or effort.
  2. Transfer: In this case, you transfer to risk to another organization, team or third-party that is better able or qualified to manage the risk. The classic example in this case is taking out an insurance policy. Insurance is all about calculating and managing risk under 'what if' scenarios. Another example is transferring the risk of handling sensitive payment data to a payment processor, as opposed to trying to manage this data yourself (along with all of the associated risks).
  3. Mitigate: In this last case, you decide to 'own' the risk, which means putting in place controls, or measures that reduce the 'r' value of the risk item to an acceptable level. Or in other words, reduce the likely impact of the risk if it was realized. Installing anti-virus and anti-malware software is a good example of attempting to 'mitigate' the risks associated with malicious software. Realistic project scheduling that takes into account holidays, annual leave, and the availability of key staff is a simple approach to mitigating project planning risks.

It's not rocket science, and all it takes is a little time at the beginning of any project to attempt to measure risks in order to put a project on its best possible trajectory for success.