Project Scope and Risk Treatment methods
Risk Responses
Avoidance
“Risk avoidance is a risk response strategy whereby the project team acts to eliminate the threat or protect the project from its impact. It usually involves changing the project management plan to eliminate the threat entirely.” (PMBOK guide, Fifth Edition, p343).
This means changing the project plan (e.g. the scope statement, the schedule, etc) so that a particular risk can’t happen.
For example, your company is developing a Web application that will run on all versions of Microsoft Explorer. But after some investigation you discover that it is very difficult catering for IE versions before V6, and so there is a significant risk that it will not work them. You consult with the clients and ask if they really need support for early versions of Explorer. The clients say they don’t have any computers with versions of Explorer earlier than V6. So with management approval you change the scope of the project to remove support for the earlier versions, and now this risk has been avoided, it can no longer happen.
Mitigation
“Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk. It implies a reduction in the probability and/or impact of an adverse risk to be within acceptable threshold limits.” (PMBOK guide, Fifth Edition, p345).
It means taking action to reduce the likelihood and/or the impact of an identified risk.
Transference
“Risk transference is a risk response strategy whereby the project team shifts the impact of a threat to a third party, together with ownership of the response. Transferring the risk simply gives another party responsibility for its management—it does not eliminate it.” (PMBOK guide, Fifth Edition, p343).
This usually means paying someone to take the risk on your behalf. For example you get another company to manufacture a risky part of the project deliverable (referred to as “outsourcing”). But it is vital to realise that the risk still exists, it is only the responsibility that you have attempted to transfer. Although be aware because now there is a (secondary) risk that:
· The other company may be late to deliver, or deliver unacceptable quality.
· You might end up in litigation with the other company over product scope arguments, or
· The other company may become bankrupt and unable to produce the component and unable to refund your money, or
· The other company may become bankrupt and sue you for bad business practices (unfair contract, etc).
As you can see, you have not “removed” the risk from the project (that would be avoidance), you have simply changed the “owner” of the risk.
Another common method of risk transference is purchasing insurance (which is why threats are also known as “insurable risks”).
Acceptance
“Risk acceptance is a risk response strategy whereby the project team decides to acknowledge the risk and not take any action unless the risk occurs. This strategy is adopted where it is not possible or cost-effective to address a specific risk in any other way.” (PMBOK guide, Fifth Edition, p343).
You simply decide that you will accept the consequence of the risk if it occurs. This may be because you think:
There’s virtually no chance of it happening (e.g. a major earthquake in London), or
The impact would be negligible,
It is too expensive to deal with (e.g. the cost of insurance may be more than the impact of the risk event), or
You simply have no idea what you would do
Some of the risks are going to materialise as the project progresses, so you will need a monitoring system to warn you of risk “triggers”, and you’ll need a Risk Management plan so that you’ll know what to if the risks occur.
You can’t plan for everything, so usually the organisation creates special budgets (called reserves) to deal with risks for which you have not planned.
