Risk Management

In this context, risks are items that could negatively impact a project that may or may not occur either during or after project execution. Risk management is a critical but often overlooked component of project management. Furthermore, often when risk management is practiced, it is only at a high-level and during the planning stages. Managing risks should be an ongoing component of project management, just like managing scope, schedule, and costs.

Risk identification and classification is the foundation of risk management. The IT manager or project manager may inherit some risk items from the sponsor and there are several inherent risks with every project. However, the most critical and controllable risks are often identified by the project manager and project team. The IT manager will have a unique perspective, more so than a dedicated PM (if there is one), as they are in a position to see how the project affects other projects and existing services within IT.

Risks can be classified in a taxonomy like the following.

  1. Risk ID: All risks must have a unique identifier, such as “R-xx”.
  2. Type: Risks should be classified by their type, e.g., project (as a result of implementation), product/design (risk inherent in the design of a product), given (risks that are present whether the project is executed or not). Each type is likely addressed uniquely and potentially by different types of resources.
  3. Liability: In effect, the liability is a narrative describing  the risk.
  4. Trigger: A trigger is a description of the empirical observation or metric of the first manifestation indicating that the liability will be realized.
  5. Mitigating actions: These are the actions we perform or recommend that we perform in order to minimize the chance the risk will occur. Depending on the probability and exposure of the risk, a mitigation plan could be extensive.
  6. Probability: This is the estimated probability of occurrence of the liability. Using an exact percentage is rarely necessary; the choice of “high”, “medium”, or “low” is typically sufficient.
  7. Probable Date: This refers to the probable date of occurrence. A general indication of the linear phase rather an actual data is sufficient.
  8. Exposure: Exposure describes the ramifications if the liability is realized.
  9. Area of impact: The impact area is that which is impacted by realization of the risk. This might include customer satisfaction, schedule, or quality, among others. Frequently there multiple areas affected.
  10. Contingency actions: These are the recommended responses if a risk comes to fruition, either to minimize exposure or recover from the damage.
  11. Risk assumption: The party that must assume ownership of the risk and exposure.

After identifying risks and characterizing them in the preceding framework, the project manager should begin communicating the risk information and setting expectations, and then build the mitigation and contingency activities into the plans. The PM should then review status of risks periodically and monitor for changes.

An entire discipline exists for risk management which expands beyond project risk to security risk and general business risk. PMI, ISC2 and ISACA all have certifications for IT risk management and companies have dedicated positions for risk managers.