Risk Management
Posted in Project Managment on November 8th, 2010 by Rachael
Wallace and Keil define risks as “factors that can, when present, adversely affect a project, unless project managers take appropriate countermeasures”. The likelihood and consequence of a risk occurring varies from risk to risk. Failure to identify risks can lead to massive blowouts in cost and schedule as the risks become more visible. Therefore it is extremely important to identify risks at the beginning of the project so that their likelihood of occurring and consequence can be estimated, and the risk itself can be tracked.
The first approach to risk management is using a likelihood versus consequence table can be used to rate the severity of a risk.
As seen above risks with a high likelihood and consequence are treated extremely seriously, while risks with low likelihood and consequence do not need to be concentrated heavily on. Some companies document risks by identifying their likelihood, consequence, cost and mitigation, which is what the organization needs to do to prevent the risk from occurring. By performing mitigation events throughout the project, the likelihood of a risk can decrease.
Identifying low risks does not mean that it can then be completely eliminated, and the second approach to risk management is to approach risks in 3 ways; insurance, acceptance, and transferal. Insurance is similar to the concept of mitigation; measures are in place to minimize and control the risk. Really unlikely and inconsequential risks can be accepted, meaning that no mitigation efforts are in place to reduce the likelihood of the risk. To transfer a risk simply means to outsource that particular part of the project, meaning that developers don’t need to worry about the risk anymore.
I can understand the first two approaches to risks; I believe risks can be insured against or simply accepted, however I am rather aghast at the third approach (transferal). I don’t think simply sending the workload away will reduce risks. I believe there is a further risk introduced when outsourcing occurs; the part of the project produced through outsourcing might not be complete and up to internal standards. Also, the outsourced company might simply ignore risks and not insure against them. In this instance, risks could indeed simply be transferred back to the developers who outsourced the work in the first place.
As some risks could have devastating impacts on the project, I believe it is important to have a proper process in place to identify them. I hold the first approach to risk identification and management in high regard; risks can be classified and actions can be put in place to try and minimize the risk’s likelihood.
References
Humphrey, W., S. (1989). Managing the Software Process: Addison-Wesley.
Wallace, L., & Keil, M. (2004). Software Project Risks and Their Effect on Outcomes.
Communications of the ACM, 47(4), Pages 68 – 73.
