A lot has been written lately about risk and how to address it from an IT perspective. Once you've identified risks, prioritized the risks considering 'likeliness to occur” and 'impact to your project”, and decided which risks are worth addressing and which ones you deem not critical enough or likely enough to occur to even worry about, then it's time to decide your strategy on dealing with the risk list you have left.

Risk Strategy

You're an IT consultant - either leading a team of skilled resources on an engagement or you're part of that skilled team as a critical expert technical resource. Either way, you're going to be involved in the risk planning, identification, and strategy process.

The scenario should go like this You brainstorm with your team members and hopefully your customer on what potential risks loom that can doom or seriously affect your project. Now you have a list that is far too long to deal with in detail, so you must prioritize the risks weighing them usually on two combined rankings - likeliness to occur and impact to the project.

This is the only way to draw your line in the sand as to where your comfort level is on these risks. This is the line above which your team feels there is a definite need to address and create some sort of action plan.Below which you deem them not worth worrying about - at least from a cost/benefit standpoint.

I usually compare this to buying car insurance. When buying insurance, you must make a decision on the size of your deductible. It's based on a comfort level you have on how much you're ok with paying in the rare event of an accident that is your fault. You aren't likely to go with the lowest deductible possible, but you're also not likely to go with the highest either. You'll find your comfort point somewhere in between.

Once you've arrived at that list, with that 'special” line, then you're ready for risk strategy. There are generally two main types, Risk Mitigation and Risk Avoidance. Let's look at each.

Risk Mitigation

Risk mitigation is the act of working to minimize the risk impact should the risk actually occur. Working to mitigate risk means that you come up with a plan to lessen the impact on your project or your customer should the risk event actually happen.

An example of this may be to recommend that a data centre moves from weekly backups to daily backups to ensure that the client never loses more than 24 hours worth of data in the event of a disaster or crash. By taking this action you've not eliminated the risk, but you've potentially greatly reduced its impact should the risk event be realized.​​​

Risk Avoidance

Risk avoidance is the act of taking some sort of action or putting plans in place that will greatly reduce the likelihood of the risk event even happening, not just reducing its impact. This, of course, is not always possible. But on the risks that it is possible for, it can mean a great deal to your overall bottom line on a project. In the backup example above, let's assume the data you have is extremely critical and highly sensitive possibly financial in nature. And it is for high-dollar, high-visibility projects. No one can really afford to take a hit on that type of data loss.

By moving into risk avoidance mode on this by, say, using clustered data storage technology, you've now virtually eliminated the risk altogether.albeit at a considerably greater implementation cost. But if it's critical enough to avoid, then it may well be worth it. You've spent more on the process and technology, but you've eliminated the worst-case scenario of 24-hour data loss in the risk mitigation example.