
There are four steps to assessing and managing risk. These are:
This is generally done through brainstorming. The objective is to find as many things as possible that could cause problems on the project. These problems can occur both during the project itself (a technical challenge that may not be overcome, a lack of funding, etc.) and after implementation (the system doesn't work, people don't have access to the tools to use the system, etc.).
Some ideas to get started when looking at risks are these frequent causes of project slippage:
There are several methods available to quantify the severity of a problem, ranging from a simple scale to precise dollar values. In IRT, we use a three value scale based on the dollar value of the impact or how many people would be impacted by the problem.
High -- the problem would involve more than $100,000 or impact the entire university or several departments/areas. It is likely that the President or Executive Vice-President would hear about this and contact IRT.
Medium -- the problem would involve more than $20,000 or impact several people in one or two departments. The manager of this department(s) would contact IRT.
Low -- the problem would involve less than $20,000 and impact three or fewer people in one department. These individuals would contact IRT.
Estimate the chance that this risk will occur. In IRT, we use a three value scale.
High -- over a 50% chance.
Medium -- a 10% to 50% chance.
Low -- under a 10% chance.
The final step is to develop a plan to account for the important risk elements. The two variables identified above determine which risks require this step:
| Impact | ||||
| High | ||||
| Medium | ||||
| Low | ||||
| Low | Medium | High | ||
|
Likelihood | ||||
| = risk mitigation plan needed | ||||
The risk mitigation plan states how the risks will be monitored and managed during the project. In some cases we may decide to accept the risk. In others, the plan may be nothing more than a monthly review. Conversely, to control other risks may require development of secondary code that will be used if the desired method is technically impossible. A risk mitigation plan typically includes key dates that certain items must be complete or alternative methods will have to be employed.