Glen Alleman has an interesting post here on his thoughts about how risks are handled. He talks about Risk Retirement as the process of taking steps to stop a risk from happening. He references a post elsewhere from Brad Egeland that talks about Risk Mitigation as the process of lessening the impact of a Risk once it does actually happen.

In Project Server (All Versions) we have risks and issues as part of the standard SharePoint workspace template that is used to create workspaces for each project. Our Risks list has fields to track probability, impact, (a derived “Exposure” score based on probability and impact), mitigation plan and contingency plans (and other fields as well). We keep these fairly general so as not to paint us into any specific corner with regard to process since we have to fit into many organizations. For us Probability is just that: the chance that we think the risk will actually occur. Impact is a 1-10 subjective measure of how bad it would be for the project if it did occur. Scales for impact are something like 1 equals “less than a $500 change order or 10 hour scope change” to 10 equals “close down the project” or “someone goes to jail for compliance issue”.

When I work with customers that have not had a sustained risk management process before I suggest to them a bit of a hybrid of what Glen and Brad have said. I tend to think of Mitigation as a combination of avoidance (actions to take that will lower the probability) and what Brad calls mitigation (actions to take to lower the impact.) Contingency is then the plan of action that should be in place (generally only for high Exposure risks) in case the risk actually occurs.

Project Server has a few features that aid in this planning. Of course the Risks list has the rich text fields for laying out the high level plans for both mitigation and contingency but we also provide the ability to link tasks from the full project schedule to the risk. This link can be marked to show that the “Task Mitigates the Risk” or “Task is in risk contingency plan” (as well as a few others that do not concern risks). In this way you can insert tasks into the schedule and show that they are part of the planning for a specific risk.

The new “Inactive Task” feature in 2010 can also play a role for contingency plans. Using this feature you can insert sets of tasks into your schedule, assign resources, make estimates, and anything else you would do for any other tasks in your schedule and then mark that whole set of tasks as “Inactive”. This ‘greys them out’ in Microsoft Project but they are still there in the plan. It also removes them from the Tasks or Timesheet pages for the resources assigned to them. Then as risks actually occur you can mark the appropriate set of tasks as “Active” and your schedule now reflects the actions in your contingency plan for that task.

Here is the introductory post about Inactive tasks from Heather on the Project Team. In a later post i will show specifically how I use Inactive tasks in my risk planning.