Risk means uncertainty. To understand what sort of risks the project may be subjected, depends upon what the project is about, at least in part. Projects that delivery products, have risks associated with the product also. For example, consider three different products, an anti-locking braking system (ABS), a disk delivered gaming software, and an online game that does not require personal information. These three products have different risks associated. Failures of an ABS system can cause bodily harm. Even if the ABS does not have a hard failure that results in bodily harm, returns of products and replacement of the product in the field is quite costly, or it can be. Therefore the risks associated with this are likely high. The delivered game, has material associated with the product delivery, but if the product fails, nobody gets hurt, there are some small material consequences, but nobody gets hurt. The last instance, the online software product that has not access to your personal information is the least risky. There is not entry to your personal information, there is no material consequences, the software is on the server that can be easily updated. Tolerance to risk and therefore risk response is situation dependent. Risk has two components, probability which is the chances the thing we identify as a risk coming to past, and severity, that is how bad will the consequences be should the event come to past. The risk management plan describes how the project intends to set about managing the risk. The risk management plan describes how the team will set about the managing the risk. It is the identifying the operating rules and boundaries for the risk work?

Generally risk management falls into a sequence of steps that look something like this:

  1. Identify risks – multiple perspective, everybody on the team should be asked to contribute what they see could go wrong or what has gone wrong in the past. We want to identify as many things that can go wrong as we can think. It is a little like brainstorming, there are no bad answers, we do not care about how severe or probable just yet. We want to dredge up without judgement all things that can adversely impact reaching the project objectives or impact cost and schedule for the project.
  2. Assess risks – not all risks are equal, somethings are trivial in nature or consequences and therefore warrant little or no attention.
    • Qualitative – qualitative risk analysis is way of ranking those risks we have identified earlier. We can identify categories of risk levels, and we will put each risk in that category of severity and probability. For example, very severe and highly probable events should rank high in priority for example the number 1, and the lower severity and less probable goes to number 30,.
    • Quantitative – quantitative risks analysis works to place a dollar amount for the impact of the risk. Just how much is this risk going to cost us should it come to past. In general this evaluation is performed by exploring the dollar amount associated with the problem, multiplied by the probability of the event happening. For example, consider an outsourced contract work to a supplier that has the value of $30K, and the chance or probability of the supplier delivering this portion late is 1 in 3 or 30%. Therefore the value of this risk or the amount of money we would set aside to deal with this possibility is 30K x 30%, or $10k dollars.
  3. Plan risk response
    • Mitigate – this is actions we take to reduce the risk or probability of the event happening
    • Accept – risks are small enough, that is low probability or low severity or both, we just accept the consequences
    • Contingency – the alternative actions we intend to take should the risk occur. This is also associated with money that the project will set off to the side, not really part of the initial budget for the project, but set aside money specifically allocated to the risk we identify using a contingency. In our example of above, we would set aside $10k dollars to help solve that risk if it happens. The contingency budget then is the sum of the risks to which we put dollar amounts to that we assign this contingency to. There may be yet another reserve, and that is attached to the executives it is referred to as the management reserve. That is associated with projects going over budget and changes that impact cost or delivery.
    • Transfer – transferring the risk means we hand this potential problem to somebody else, for example, insurance or out sourcing the work. This does not really eliminate the problem though, so it is not as easy as transfer and forget in some cases. Here is where metrics or measurements are needed to track the state of the work item under consideration.
    • Avoid – is just what it sounds like – we want to take another strategy, or another tactic, or perhaps we remove the project or some portion of the project from our work list.

  4. Monitor and control risks
    • For each of the risks, especially those that we deem to be serious, we will define measurements that help us understand how near the risk may be immanent. In this way we can be proactive regarding the risk, making it possible for us to introduce our contingency plans early thereby reducing the negative consequences of the risk on the project. Metrics (measurements) allow us some measure of predictions. For example, suppose we are testing the product, and at this point in the development of that product, there should be no serious defects found. However, in the course of the testing, we find 3 serious defects. This tells us something about the schedule, specifically, that we may not be ready to launch this on time. It also indicates something about the quality, or fit for use of the product. Knowing what to expect, or more importantly the range of what to expect, puts us in a position to be able to adapt and react minimizing the damage that is incurred from the risk. There should be continuous and constant review of the risk register (the place we record all of this stuff) to see how the project is fairing with the risks as well as uncovering new potential risk areas from the team. The project environment is dynamic and subject to change

Risk management requires taking time to discuss with the team members to uncover. The historical record can be a great source for understanding what typically goes wrong. Additionally, the historical record can provide evidence of the variation of the processes and of the product and project. Experience suggest that a large component of project failures is due to a lack of understanding about variation. For example, people develop the project schedule of depending events or work, perhaps in a Gantt chart. The duration's that are given for each task is a point source, that is a single entry as opposed to a probably distribution or the worst case length derived from performance metrics. Each element in the Gantt chart suffers from this defect. Here is where probability works. Let’s say each task in a three task chain is 80% probably. Let’s also assume that though these are connected in time, the event are not connected by quality, that is each of the three tasks are independent. This will be the best case scenario. So for three tasks to all work out successful, will be the product of .8 x .8 x .8= .512 or approximately 51% probable that this will be completed on time. This is not much better than a coin toss making this more of a gamble than anything we are working to control or influence.