Risk Strategies and the Project Manager

Risk is that ugly four-letter word that we as project managers need to pay attention to but often look upon it like taking out the trash at home. Planning for the management of it should happen, it needs to happen…but let’s do it later. Right now let’s get started on the real work. Right?

The reality is that every project you manage is much more likely to succeed if you put a decent amount of effort into the risk planning and management process – and make sure it is mapped out in your project schedule. Then, 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 or project manager or project team professional – 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.

Planning for risk is like 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 to your project or your customer should the risk event actually happen.

An example of this may be to recommend that a data center move 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 it’s 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.


By all means avoid risks whenever possible. The end result will be the least amount of impact to the project (usually) both in terms of time and money. But not all risk can be avoided…we all know that. Mitigation is certainly the next best thing. But if you’re always surprised by these risky events actually happened because you haven’t bothered to plan for them, then your projects will always be hit like California earthquakes and you’ll have no one but yourself to blame. And your customer will have no confidence in your ongoing ability to plan and deliver.
Brad Egeland

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>