CRM Project Risk Management: What it is & why it’s important

by Iain Wicks
2 January 2018

General, CRM Project

The first thing to say is that all projects have risks. There might be a risk of not completing the project on time, a risk of never realising the expected benefits because the scope and requirements keep changing or simply because they weren’t defined clearly enough in the first place.

Risks can take multiple forms and it’s a good idea to try to work out what the risks are for each particular project at the beginning so that you can plan for ways to take action either before or when those risks occur. When people talk about risk management in CRM projects, they often get confused between risks and issues. Although they are linked they are actually different things.

Risks are uncertain events that could happen and if they do they will have an effect on the project. An example may be going to Wimbledon to watch the tennis; there is a chance you may get wet if it rains.
Issues are events that have actually happened that have an effect on the project. An example is watching the tennis at Wimbledon and it is pouring with rain and you are getting wet.

We will look at Issue Management on a future blog post.
It’s easy to see that in a lot of cases better risk management will result in less issue management. An example is going to Wimbledon to watch the tennis you would probably look at the weather forecast first and then take appropriate action according to the predictions. Such as taking an umbrella or a sun hat and sunglasses.

What is a project risk?

We usually think of risks as being something negative. Examples are:

Inaccurate date being imported into CRM that leads to a delay while it is sorted out.
Low user adoption of the software due to the project being perceived as “optional” by users.

But in the world of projects, risks can also be seen as positive things, these are called opportunities. An example might be;
A CRM project on a tight budget has had to put a cap on some requirements due to finances. If the license costs go down then more funds will become available to spend on the capped functionality.
This is an example of a “risk” that can have a positive outcome. It’s important to consider all things that can have an effect on your project and not just the negative things.

So now we know what risks are…

What is Risk Management?

In a nutshell this comprises of three elements:

Risk Management Process

Identify: Identifying the risks and opportunities that relate to your project
Assess: What is the likelihood that this event will happen and also what impact will it have
Control: Put measures in place to respond to the risk

So, in the tennis example we saw earlier:

We identified the risk by thinking back to last year when we got soaked while watching the semi-final
We assessed the likelihood by checking the weather report
We controlled the risk of getting wet by taking an umbrella

The example of the umbrella raises the topic of the costs of managing risks. It might be that the rain that was due didn’t actually arrive. But I was happy to carry the umbrella around all day anyway just in case. This is an example of me weighing up the “costs” of putting measures in place and making a decision that the cost of carrying an umbrella around was an acceptable one. This is the same reason we pay money for car insurance.

How do we identify Risk?

It is a good idea to gather risks with the project team at the beginning of the project before any work takes place, but also to keep an eye on risks throughout the project.
There are various techniques that can be applied when identifying risk in your CRM project.
• Brainstorm with your project team
• Look at your past projects for clues
• Ask your boss
• Consult with your CRM partner. They will be very familiar with common risks in CRM projects.
• Go through a detailed breakdown of everything that needs to happen on your project and try to visualise anything that can happen that would affect the project.
These exercises will leave you with a list of risks. Some of them may be more probable and have a bigger impact than others.

Once you have identified the risks, the next thing to do is to assess all of the risks.

How do we assess risk?

Risks are assessed based on two factors:

Impact on the project
Probability that the risk will occur

The overall score for a risk is based on a combination of the two factors. For example, a risk that is highly probable but has a very low severity may be more acceptable than a risk with medium probability and medium severity. Impact might be measured financially or in terms of time which effectively causes a delay to the project. How you measure impact is dependent upon what is important in your project.
One good way to draw this out is to use a matrix for risk profiles with Probability on one side and severity on the other. The idea is that you plot where the risk falls onto both axis. The area on the top right of the matrix is where the highest and top priority risks are located.
What you then do with that information is up to you and your project team. You may decide that any risks that fall within the top 6 or 9 boxes should have a proper plan in place to deal with them and that anything else you will deal with if it happens.

This risk matrix is an easy way to get a good overview of your project risks and is a useful graphical tool for communicating the risks to your team and to project sponsors.

How do we control risk

You control risks by planning responses to the risks. The objective here is to reduce any threats to your project and perhaps exploit the opportunities. Some responses will cost more than others so you also have to weigh up whether you are prepared to “pay the price” needed to reduce the risk.
e.g. carry the umbrella around all day.
Risk Responses can fall into four main categories:

1. Avoid: This is what you do when you want to be sure that you eliminate the threat.
  Example: To avoid the risk of the system build running out of funds you allocate an unlimited budget to the project.
2. Mitigate: Trying to ensure that the risk doesn’t happen by taking appropriate action.
  Example: To mitigate the risk of the system build not being GDPR compliant you might ensure that your Data Protection Officer is involved at all levels of the design and that GDPR is considered at every design decision.
3. Transfer: This is when you share the risk with someone else such as an insurance company or other third party.
  Example: You take on a GDPR consultancy to work with you on the project to ensure GDPR compliance.
4. Accept: You accept the risk and decide that you will face the consequences if it happens.
  Example: You know from past experience that user adoption is an issue but you don’t have a change management officer nor budget to carry out a change programme so you decide to just accept the risk and hope that the new system is compelling enough that users will be excited about using it.

For positive risks, you might decide to either push for it to happen or to just wait and see. If the potential positive outcome is going to result in more work you may decide to involve a third party to help you to deal with the opportunity. New risks can arrive at the project managers door at any time during a project. This is why it’s important to review project risks on a regular basis. When presented with a risk, the project manager should add the risk to the list of project risks (the Risk Register) and then follow steps 2 and 3 of the Risk Management process.

So, you can see that whether you are organising an event, managing a large CRM project or even just going for a day out to watch tennis, there are risks inherent in everything we do. Every one of us manages risk as part of our day to day lives. The practice of Risk Management is just a way of formalising that process and making it more transparent to other stakeholders.

share with your friends