Note: This post is focused on date driven projects, where tolerance for missing a date is very low due to market or business constraints.
Many project managers tend to have similar backgrounds writing specs, putting together schedules, and providing status reports among many other project related tasks. One area that doesn’t seem to be widely undertaken or understood is in the area of risk management.
In it’s basic form, risk management is about working with the team early in the project to identify risks to the project and the following for each:
- The trigger: what will cause the risk to occur?
- The mitigation: what will the team be doing to minimize the risk from occurring?
- The contingency: if the risk is realized, what will the team execute on as a result?
- The probability: what are the odds that the risk will be realized?
- The impact: what is the impact to the project (typically in units of time for date driven projects, but can be other things like resources)?
Using the probability multiplied by the impact, we get what’s called the exposure. The exposure can then be used to stack rank the risks, which you can then use as a prioritized risk list. The impact can also be used to help justify buffer (preferably, risk tolerance) in the schedule, and you can also run a statistical analysis on the risks and probabilities to come up with the most probable project slippage (in theory).
While the team should come up with the projected probability and impact, it’s important to note that the numbers won’t be exact. It’s also very important to ensure that the risk management process is iterative and continuous over the life of the project.