In the previous post in this series we looked at Risk Statements, where risks are broken down into manageable pieces comprising the cause, the event, and the consequence. This post looks at controlling risks.
Before considering the control actions, an assessment needs to be made into the likelihood of the risk occurring and the magnitude of the impact. Likelihood is classified on a scale of unlikely, quite likely, etc. Impact is classified as minor, major, etc. Quantifiable measures can be placed around these impacts, e.g. loss of life is catastrophic; a cost to the company of greater than $10M may be considered major. The classification of the impact levels will depend on the company and the project. The likelihood and impact determine the overall risk level as shown in the matrix below.
After the assessment is complete, we can now investigate actions to reduce the risk down to an acceptable level. We have four options: avoid, mitigate, transfer, or accept the risk.
Avoid
There will be times when the risk associated with an undertaking or change is determined to be too great and must be avoided.
On 15 January 2009, US Airways Flight 1549 suffered a bird strike after taking off from LaGuardia Airport, causing both engines to fail. In a matter of seconds captain Chesley Sullenberger assessed the risk of gliding the plane to the nearest airport. He determined the probability of not making it was too great and the consequences catastrophic if he crashed in the highly populated surrounding area. This risk was avoided. He decided to attempt a water landing in the Hudson river. Miraculously, he did just that, and without casualties.
Mitigate
Mitigation control will lessen the likelihood and/or lessen the severity of the impact. When lessening the likelihood, you will address the cause of the risk and/or the risk event.
On 2nd August 1985, Delta Airlines Flight 191 crashed on landing approach during a thunderstorm. The event that lead to the crash was an intense wind downdraft known as a microburst. The cause was the pilot’s decision to land during the thunderstorm. At the time, planes were not equipped to detect wind changes. After the crash all planes were mandated to have airborne wind shear detection and alert systems installed. The presence of these systems (mitigation) now lessens the likelihood of the risk event.
Transfer
It may be possible to transfer some or all of the impact of a risk to a 3rd party. An example is insurance where financial consequences are shared by many.
In aviation, the costs associated with damaged aircraft and injured passengers are substantial, so airlines may choose to take out insurance and lessen the financial impact in the event of a disaster.
Accept
There will be times when the likelihood or the impact of an event do not warrant proactive treatment—the risk is simply accepted. A risk level of low may mean a risk is accepted. If the cost of avoiding, mitigating or transferring a risk is greater than the benefit, it makes sense to accept it. But it is important to ensure the cost benefit analysis is thorough and any flow-on risks are considered.
In the 60-70’s, Ford Motor Company ran a cost benefit analysis to fix a defect with the Pinto model which was known to cause significant injuries and fatalities. Ford accepted the risk and determined it was more cost effective to settle with victims than to fix the cause. In this case, Ford’s acceptance of the risk resulted in it being fined far more than the profits generated by the Pinto and resulted in significant damage to company’s reputation.
Once the control action has been decided, the post control risk level is determined, and the risk is assigned an owner. The final consideration is the contingency plan. That is—if the risk still exists and becomes an issue, regardless of the control, what actions are then taken?
So, for Business Central implementations, examples of controls are:
- Avoid – An enhancement considered too costly is not implemented.
- Mitigate – Additional resources employed to allow more thorough user acceptance testing.
- Transfer – Business Central hosted in the cloud to lessen risks associated with infrastructure.
- Accept – Key users not available for training but proceeding regardless to keep the project on schedule.
In the next post in this series, we will look at how project success is defined.
