Creating a Risk Tracking System

You have seen in this chapter that risks can come from many sources. You have also seen that periodic monitoring of risks and developing mitigation plans are critical to preventing risks from derailing a project. On some projects, a risk mitigation plan document is carefully developed and then forgotten. To be successful at managing risks, you must prevent this from happening.

On several projects, I've implemented a risk tracking system for monitoring and tracking project risks. I have used IBM Rational's ClearQuest change tracking system for this purpose, but this type of system can be implemented in any similar type of tool.

Characteristics of a Risk Tracking System

A good risk tracking system should, at a minimum, track the following information:

• When the risk was identified.

• When the risk could start impacting the project.

• The person who identified the risk.

• How likely it is that the risk will impact the project. A simple five-point scale should be fine.

• An estimate of the impact's severity if the identified risk materializes.

• A complete description of the risk and how it will impact the project.

• An assigned "owner" of the risk. This is a person on the project (probably assigned by the project manager) who takes responsibility for monitoring the risk and developing the mitigation plans. A risk is less likely to be ignored if someone is assigned specific responsibility for it. Without this feature, everyone assumes someone else will take responsibility.

• The type of mitigation plan adopted (for example, risk avoidance, risk transfer, or risk acceptance).

• The date a risk is closed. A risk can be closed when it can no longer affect the project.

• The reason for closing a risk.

Figures 8-1 and 8-2 show examples of risk tracking screens developed for the IBM Rational ClearQuest tool.

Figure 8-1. A ClearQuest form for a risk management system

Figure 8-2. Another page of the ClearQuest form for managing risks

In addition to tracking specific items of information, the system should support the notion of a risk lifecycle. Figure 8-3 shows an example of a state diagram with a suggested risk lifecycle. Note that one of the states is called monitoring. The risk management system should be configured to proactively notify someone at a predetermined interval to remind the risk's owner. This reduces the chance that the risk will be forgotten.

Figure 8-3. The lifecycle of a risk in the risk management system

If possible, your risk management system should be accessible to all stakeholders via a Web interface. This allows risks to be conveyed to the stakeholders, and also provides a mechanism for them to contribute. Information useful for confirming or mitigating a risk often comes from sources you might not expect. Also, stakeholders may identify new risks. Make sure contributions to the risk management system are acknowledged. Otherwise, stakeholders will cease contributing.