Skip to main content
Blog

A Brief Introduction to Risk Management

4-5min Read
Should you? Or Shouldn't You?
A Brief Introduction to Risk Management

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 a project. We then consider whether our project is 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 all of the world's project stakeholders (for all projects in the world), we'd have to ask three questions: 1) In terms of threat - has this ever happened before?, and if so what is the distribution or frequency of this threat? 2) In terms of vulnerability - if the threat were realized, would they really take our stakeholders? and 3) In terms of impact, what would be the consequences for the project if this threat was realized. For now, we're probably okay with saying that the threat distribution in this case 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, and so perhaps it's worth including in something we'll call 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 or mitigate 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?".

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.