Whether it's small or large, complex or simple, every project has risk. It's our job as managers to do our best to not only minimize the risk in our projects but to minimize it as soon as we can. In this article, you'll learn a simple four-step approach for doing just that.
The first step to managing the risk of a project is to inventory the situation. That is, identify all of the risks that you think are possible in the project. The inventory should include all internal factors for the project such as resource changes, assumption failures, and sponsor availability. It should also include all external factors such as a change in company direction or a change of technology direction. Most of all, however, it should include the things that are new in the project. If the project is working with a new technology, is using a new development methodology, or even if there are new, relatively unknown team members, these need to be listed as potential risks to the project.
The purpose of the inventory phase isn't to classify the risk or identify its importance. That step happens later. The goal is to collect all the risks. If you mix in the process of evaluating the risk you'll find that you won't get a complete inventory of the potential risks for the project. Staying focused on capturing risks is essential to the process.
Once you have a complete list of potential risks, it's time to evaluate them. Each risk should be evaluated based both on its probability and on the impact that it would cause if it happens. The loss of a key team member may have a low probability; however, the impact to the project can be great.
Some people struggle with the evaluation step because both of the numbers, percentage and impact, are guesses. They recognize that even subtle changes in the values for these numbers can have a huge impact on the total risk of the project. However, in general, the objective here isn't to come up with a single number that represents each risk. The objective is to develop a framework for evaluating the various risks against one another. Although precision in the estimating process is useful it's not essential.
The other factor to evaluate when looking at a risk is its duration—how long that it can have a potential impact on the project. For instance, the loss of a subject matter expert early in the project is a risk because their input is still needed. However, later in the project they may not have much input and therefore aren't a risk if they leave.The risk of a functional analyst leaving is greatest in the initial phases of the project when they are intensively interacting with the customer. Later on in the project, the loss of the functional analyst has a smaller potential impact for the project.
In order to get a consistent number for all of the risks, multiply the probability which should be per interval of duration by the impact and finally multiply that by the duration. The resulting number is a single number, a risk quotient, which can be used to prioritize risks within the project. For instance, if the probability of the risk happening in a given week is 10%, the number of weeks the risk may happen is 10 weeks, and the impact is $1000, the overall risk is $1000. (.10*10*1000 = 1000)
Now that you have a single risk quotient for the various risks, it's possible to prioritize the risks for the project. It can give you a clear vision of what the risks are and which ones you'll ultimately need to be concerned about. This is also a part of the process that typically helps validate the estimates made above. For instance, if your greatest risk is personnel turnover (as it usually is) you may want to more objectively evaluate the probability. If the average person stays at your organization for three years you can assume a probability of them leaving in a given week is 1/156 (3x52 weeks/year) which is a 0.00641 percent chance.
Control and mitigate
Once the risks are prioritized you can go through the list and identify which risks are controllable, which risks are things that can be mitigated, and which risks must be accepted. For instance, the risk of loosing key personnel can be mitigated by providing completion bonuses or even just monitoring their happiness more closely. Technical risks can be controlled by moving them forward in the project so that they are proven out nearly immediately.
In general, the fastest way to reduce the overall risk quotient for a project is to tackle the controllable risks early in the project. The more quickly that you are able to validate the risk associated with an item the more quickly the risk is no longer a risk (so its probability can be zeroed out.) Focusing on controllable risks won't completely eliminate risk but it will quickly cut it down.
The next step is to develop mitigation strategies for those risks that can't be controlled. Completion bonuses are a routine way that organizations which are closing down operations mitigate the risk that the people participating will leave before the project is ready to let them go.
Not every mitigation strategy needs to involve money. Simply getting a verbal, personal commitment to finish the project is often enough to further reduce the probability that a person will leave during the project. Most people value their own sense of self worth and they believe that their ability to meet their personal commitments is a part of the admirable part of their self.
TechRepublic's free Strategies that Scale newsletter, delivered each Tuesday, covers topics such as how to structure purchasing, when to outsource, negotiating software licensing or SLAs, and budgeting for growth. Automatically sign up today!