Some risks pose less chance for harm to a project than others. For example, the risk of a contractor you' re using quitting his job and leaving you high and dry isn't a big risk because, presumably, the company you' re contracting with will backfill with someone else, though the replacement may not be as skilled as the incumbent (hey, she may be more skilled). Compare that with the risk that you' re counting on two disparate systems to talk to each other through some middleware and finding that the battle is going to be large and long in order to get the middleware to cooperate.
It' s important to evaluate risk severity. After you' ve gotten your list of risks, prioritize them. You have a couple of different methods by which you can do this:
■ By the likelihood that the risk will occur during the project' s implementation
■ By the impact the risk would have on the project if it happened
It' s a good idea to show the list in both orders so that you and the team can then make decisions about how to go through the quantification and response development processes (described next).
Was this article helpful?