While I'm passionate about many topics, risk management is at, or near, the top. This is because I've seen it work and, more importantly, I've seen and lived the results of poor risk management. On one instance, I was leading a project that experienced a $250,000 cost impact as a direct result of a completely avoidable risk. These are lessons you want to learn through someone else, not through experiencing them yourself.
Standard risk lists are filled with items like "not enough resources" or "aggressive timeline." Are these actually risks? NOW HEAR THIS...More than likely, you're never going to have enough resources and timelines will always be aggressive. Get used to it. These are certainties, not risks. This is, in general, the nature of the modern project environment.
But beyond their obviousness, risks like these fail to provide the project manager or the team any useful direction. As an example, consider the statement "not enough resources." What does that mean in the context of the project? Is it the cause of something else? Is it a statement of what your project is experiencing at this moment? There is simply no way to know from the description provided.
A good risk statement will articulate the cause, identify the risk, and communicate the result or impact of the risk becoming an issue. Statements such as the ones above do not clearly articulate anything. Instead, consider stating your risks in this format:
"As a result of , a may occur, leading to ."
To do this properly, you'll have to identify the trigger most likely to turn your risk into an issue. For example, the "not enough resources" statement could be rewritten as, "As a result of slips in other projects, the resources required for project completion may not be available, leading to missed deadlines, poor quality, or both." Stated in this verbose manner, the risk communicates many vital pieces of information.
- What's the cause? Slips in other projects are the cause which now becomes your trigger.
- What's the risk? The resulting lack of resource availability is your risk, which will become your issue if it's realized.
- What's the result of the risk being realized? Should the risk become an issue, the missed deadlines and/or poor quality will be the result. These will have to be lessened in severity should this risk become an issue.
Another alternative for risk statements is an IF-THEN structure. Following this format, the resource availability risk above would be written as, "IF other projects currently in progress slip, THEN the resources required for project completion will be unavailable, leading to missed deadlines, poor quality, or both." I've found that this method works especially well when trying to get a group of software developers to discuss project risk. This risk statement method also helps to connect with a development team, since you're speaking to them using their language.
With the risks properly stated, we may now move toward determining the probability of occurrence, the severity of the impact, and identifying an owner for the risk.
The probability of occurrence is, admittedly, subjective. My suggestion is to assign a range of possibilities to the probability of occurrence. As an example, you could state your probability using the following four categories:
|Remote ||25% or under|
|Slight ||26 – 50%|
|Medium ||51 – 75%|
|Almost Certain ||Over 75%|
This is often referred to as a range estimate. I find these ranges far more useful than "point" estimates for both probability and impact values. You can be much more confident of an estimate when providing a range than when providing a single number.
Try it: Without looking at the internet or in a book, estimate the radius of the sun in kilometers using a single number. How confident are you in your answer? Would you feel more confident if you were allowed to give a range, perhaps somewhere between 300,000 and 900,000 kilometers? Of course!
The point is that you can enhance your ability to effectively manage risk by acknowledging that your guess is just that—a guess. You can increase your confidence level in both probability of occurrence and magnitude of impact. You can increase it further by performing a Monte Carlo analysis, but that's a topic for another time.
The magnitude of the impact is determined in a similar way. Assume the risk has occurred. What would be the impact to your project? You can categorize the impact in a consistent manner by simply providing a HIGH/MED/LOW rating, or you could provide an actual schedule or cost impact such as three months or $10,000. There are advantages and disadvantages of both approaches. The point remains the same as in the probability of occurrence example. You can estimate a range of possibilities much more confidently than you can a single point estimate.
Once the probability of occurrence and the magnitude of impact has been determined, you can consider exactly who should own the risk. Ask yourself who is in a position to do something about the risk. To become the risk owner, you should be in a position to be able to either lessen the probability of it occurring or reduce the severity of the impact. At face value, my first recommendation would be that the project manager should own the risk of not being able to obtain the required resources. This ownership would include monitoring ongoing projects your resources are currently assigned to. If the projects slip, you can work to find other available resources capable of performing the work on your project or escalate this issue.
So how many risks should you manage? It depends on the criticality and stakes of the project, the size of the project team, the aggressiveness of the schedule, and the support (or lack of support) provided by executives and sponsors. I always try to perform an entire risk assessment with the team prior to beginning the next phase of a project. It pays dividends to review your top risks during each project team meeting. You can use this time to get an update on status from the risk owner, review the priority of the risk, or provide assistance to the risk owner should they need help with mitigation activities.
This is a quick and easy overview of simple and dirty risk management. Taking some time up front using a proactive approach will save you countless hours of effort and elbow grease cleaning fan blades. I've spent some time cleaning those fan blades and I suspect you have too. It's much more enjoyable to savor the results of being proactive than it is being a fan janitor.
(And, in case you were wondering, the actual radius of the sun is 695,500 kilometers.)