8 Example Risk Register Categories, classifying your types of risk

One of the things often asked within project teams is how to categorize risk.

While the process of managing risk is one well-travelled and one which of course you’ll be following, categorizing risks within a risk register does have some benefits whether that’s for reporting or management purposes. Through categorizing your risks the result can be a highly effective communication tool with business leadership.

Within risk management you might have different teams managing different risk categories; you might apply specific mitigation to certain subsets.

So then if there are benefits to doing so, what categories should you look to incorporate?

Below we’ve listed 8 Risk register categories that are commonly used together with some description about what they mean.  Note – this isn’t meant to be definitive.  You may well have certain categories that might be specific to certain industry or project types but the following examples should give you a steer in what you could look to use. These are just examples and you may have mileage in developing your own but here’s ours.

1/ Strategic risk

E.g. There is a risk that the desired results of the project are not met and the company’s strategy is less effective as a result.  This could be due to project performance issues or that the impact of the deliverable has been over-estimated.

2/ Compliance risk

Compliance issues are increasingly important.  Does your project impact compliance in any way?  Are there areas of your project that depending on the outcome could impact it? Remember compliance doesn’t have to be as a result of existing rules/legislation.  What’s the risk that new rules are introduced during your project that impact your ability to meet regulations?

3/ Operational risk (organizational, human factors etc.)

Again – this is one where many businesses can be overly optimistic.  Let’s look at the role out of a new IT system; this can be led very much by operational risk.  For example, let’s look at training and user take up of new systems.  There is usually a risk that users struggle with new systems and training is under-estimated.  Human Factors training can extend into many other areas such as risks over roles & responsibilities, Constraints over things like Health & Safety or corporate policies and procedures.

4/ Financial risk

Perhaps the most common project risk.  The financial requirements are underestimated and/or the financial upside of project delivery has been over-estimated.  These affect almost all projects and are usually the first place project teams look at when developing their risk register.

5/ Reputational risk

Whilst you might be surprised, reputational risk within projects is very real, just look at adverse press companies can get when IT systems roll outs that effect clients go wrong. The media revel in issues like this can the downside can be substantial impact to company’s reputation.  This can also adversely affect corporate sponsors/backers and shouldn’t be underestimated.

6/ Schedule risk

Along with financial risk one of the more common project risk categories.  “my project is running late” – how many times have you heard that. In mitigation terms it’s vital to understand the key drivers behind the risk rather than looking at it from a high level.  Usually there’s supporting elements like funding or resource that drive it and despite its apparent simplicity it can be complex to get to the bottom of.

7/ Environmental

External factors can also add to project risk, environmental risks might include Security or natural hazards.  Bad weather can for example impact projects where required deliveries are impacted – we’ve all seen stories of business affected by adverse weather conditions such as heavy snowfall.  These factors can increase depending on the type of project your running (for example if your project includes use of hazardous materials/goods.

8/ Technical risk

Technical risk includes facets such as poor design, over-complexity, unclear expectations and technical failures. Again this risk is common.  Most projects include an element of design work and the risk is that if this doesn’t aid the deliverable this can have both significant schedule and financial impacts.  Where the project deliverable is highly complex the project team can be sometimes in the dark in terms of levels of risk and this can be problematic in uncovering early enough to deploy satisfactory mitigation steps.

So there are our thoughts on risk categories.  Have some of your own you’d like to share?  Feel free to use our comments section below.