Project Risk Management: Responding to Project Risks
- June Tucay
- Mar 30, 2017
- 7 min read
Common risk responses
All the risk analysis in the world will do you no good if you don't ultimately have a plan to address your risks so the impact on your project is minimal. The fact is however, that most project managers don't fully consider all the risk response alternatives available to them. To ensure you don't fall into the trap of considering only a single solution, and moving on before you should, here are the most common risk response types, all of which should be considered for each important risk on your project.
Avoid the risk. Taking steps to eliminate risk altogether. Maybe you remove it from scope. Or you engage in alternative activity to end specific exposure to risk. Maybe you change the timing of an action so that you dodge the risk.
Transference. You move the risk to someone else. You acknowledge that the risk might happen but you are transferring the responsibility to the other party. You don’t totally eliminate the impact and the impact to your project is something you'd still have to deal with. So the impact of the risk isn’t zero, however, it is significantly reduced. Typically with transference you get some relief from the transferee.
Mitigate the risk. You take steps to reduce the adverse effect to your project.
Acceptance. If the risk event occurs you just absorb the impact because it is not worth the time and cost to address it.
The important thing about any risk response is that you go through your options carefully. By responding to risks you’re enhancing the opportunities and reducing the threat to the projects objectives
Determining the appropriate response
After considering the 4 risk response, you can further refine your response strategy by considering three other factors in choosing the appropriate response strategy.
1. Consider the trade-off between your triple constraints of time, scope, and cost.
For example, if time is your number one driver you may use costs to get around the time constraints. This could involve using additional resources to make sure activities are done on-time; or you can reduce the scope or functionality of your products to make sure you deliver your project in the desired time-frame.
If scope is the number one priority, you may have to incur additional costs or consider adding time to your schedule. You should consider trading other than the risk impacted triple constraints element to determine the best alternatives.
2. Consider if your risk response actually adds other risks, and if so are they manageable?
For example, as a means of ensuring you get the right skills when you need them, you may contract with two specialized technical skill providers. Adding a second vendor may reduce your risk of getting skills on time, but may add other risks, such as contract management risks, if you have never worked with that vendor before.
The fact to the risk response adds other risks are not uncommon. You just have to be sure you evaluate the nature of any new risks you may introduce to your project with your risk responses.
3. Consider when you have to make the decision to execute that strategy.
For example, Let’s say risk response option A is going to take you two months to put in place, and will cost $4000 to execute. You will likely have to decide to execute this response strategy long before you can tell for certain that the risk will come to fruition.
In contrast, risk response option B will cost $4500 but you can execute it immediately before the risk occurs.
If both of these response options have an equal chance of reducing the impact of the risk, you might choose option B over A. This is because option B although slightly more expensive gives you a greater chance of spending nothing at all on a risk response, if you can determine if the risk won’t come to fruition at all and not need a response. It gives you the advantages not having to play your cards to early.
4. Consider the speed with which you can get permission to execute response strategy.
If two options are similar in their cost and effectiveness to reduce the risk it is usually best to choose the response action you can execute more quickly. This gives you more flexibility in determining if and when a responses is needed to a given risk. You can take more time to be more decisive, or collect more data before spending additional funding.
Financials are not the only consideration when choosing your risk response strategies. Considering other factors that allow you more management flexibility or the ability to trade-off less sensitive project constraints to help others is a great way to demonstrate your prowess in considering alternatives for treating your project risks
Building a risk-response plan
So, with all of this work on risks and appropriate responses how do you ensure it doesn't fall through the cracks when the day-to-day pressures of deadlines, heaps of email and stakeholders wanting attention flocked to your desk.
The answer is, you create a risk response plan. A document that not only captures your risks and analysis you perform, but actually informs your actions going forward.
Let’s talk about the fundamental items you should put into your risk response plan:
1. The risk response plan list your risks, including identified risk causes, descriptions and potential impacts, along with the triple constraints element or elements affected should the risk occur.
2. Include your qualitative and quantitative analysis results and your risk response plan for each risk. You may include a primary and secondary risk response plan if more than one is being considered.
3. If executing your risk response plans includes leveraging contingency reserves, or are they include contract related actions you'll need to take with your vendor's, you should note these as well.
After these fundamentals are compiled in your risk response plan, these additional elements can turn your risk response plan into a powerful control document.
The most significant item to add to each risk in the response plan is the timing for when you want to either:
A. assess the status of the risk or
B. execute a response action.
These can then be added as tasks in your project schedule and assigned to specific individual. Let’s say you have two technical experts who are due to start work at a certain point in your project, and they are currently working on another project. You see the possibility of your experts other project running long and have noted this as a risk. In this example, you should note two timing critical actions against that risk.
when to check the status of the other project to determine if your technical experts will be available,
And when you need to go to the marketplace to contract other experts, because the ones you planned on won’t be available.
The next significant item to have in your risk response plan, are status dates for your vendor's or to check on products from areas not under your control.
Building a risk response plan is going to take some work on your part. But the last thing a project needs is a weak on monitor risk response plan. By ensuring your plan is robust and helps you track the actions required to monitor and execute responses against risks you can dramatically reduce the impact of risk in your project
Understanding risk triggers
To protect your project you have to keep an eye on the landscape looking for signs of trouble. These signs are called Risk Triggers. Risk Triggers are early warning sign that indicate a risk is about to come to fruition. It's a sign that you should be preparing to take action.
Common types of project risk triggers:
1. The one that gives you an immediate indication that a risk is happening. In your project environment you may have technical experts that are going to join your project at some point downstream. You request these technical experts to start attending status meetings one month before they are due to start, so they can hit the ground running, and know what is happening on the project. The time for them to appear comes around, you remind them of their commitment and they don't show for this status meeting. This is a likely risk trigger that other priorities might put the expert’s participation in your project at risk.
2. Forward indicators risk triggers are signals something is going to happen at some period of time in the future.
Risk triggers can be varied and typically involve people's behavior, unexpected schedule changes, or task deadline failures.
No matter the type or variety, here are some hints for determining and leveraging risk triggers:
1. do some research. Potential sources for risk triggers includes:
Past risk log
Post implementation reviews
And risk and issue log from past projects.
2. Once you've determine reasonable risk triggers, empower your team to search for them. The reality is that while you have to keep your eye on things you can’t be everywhere at once. You have to empower your project team so they understand the risk triggers too. After all there often a subject matter experts who were living and breathing this every day. So get them to staff the watchtowers and look for smoke along with you.
3. Plan on what you are going to do when you spot a risk trigger. The whole idea of utilizing risk triggers is to enable you to react quickly and decisively. Involve your sponsors and key stakeholders in the risk trigger process, so they know what you're going to do should some nasty smoke appear on the horizon
By understanding risk triggers, communicating them to your team and your stakeholders you can spot and react to risks much more quickly. Rapid and decisive responses to risk triggers means you will be more effective in the management of risk in your project environment
For other articles in Project Risk Management, see also:
If you are looking for even more information on managing risk, I encourage you to check out some very insightful books:
Risk Management: Concepts and Guidance by Carl Pritchard is a great book that addresses risk concepts that can be applied to any project.
Here are good references for handling IT-based projects.
Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister
Managing Risk: Methods for Software Systems Development by Elaine M. Hal
Comentários