Managing risk in an IT project — how to prioritize a risk?

Risk severity assessment

The most popular way of assessing risk priority is juxtaposing the probability of risk occurrence with the severity of its negative impacts. As a result, we obtain data about the severity of a given risk. The higher severity, the higher priority of a threat.

The table below may help us translate impacts into the severity scale.

A formula to determine a threat is very simple: probability * impact = severity.

Table: Developed based on materials available in “A Guide to the Project Management Body of Knowledge” by Project Management Institute.

The assessment of probability and impact values is most often an arbitrary decision of the team members. However, sometimes we can easily calculate the cost that it triggers. For example, if the risk relates to equipment damage, there is no problem to calculate how much it will cost to repair or exchange the equipment, but it will be a bit more challenging to estimate lost benefits. I will dedicate a separate material to financial risk evaluation in which I will try to show how to prepare a project budget in terms of individual risks.

When assessing the value of impacts, we may use simple indicators from the table. For example, if impacts are rather low, we will assign them 0.1 value. You may also create your own table and determine what value is assigned to a given damage scale. For instance, 0.4 value means that the budget or time of the project will be exceeded by 30%.

Risk urgency assessment

Another critical factor that affects priorities is urgency. Urgency is nothing but a deadline in which the risk might be materialized. Even if a small damage may occur in a week, it can turn out to have a higher priority than some significantly bigger damage that might take place within the next few months.

Risk appetite and risk tolerance

The term “risk appetite” makes me think of a good title for a reality show. In the project reality, it is the level of risk that our organization, client, or team can accept.

Particular industries differ from each other in terms of the risk appetite, for example, data transmission rates in the case of a blog website will not be that significant as in the case of a financial institution. A blogger will more easily get over the risk of a data transfer slowdown.

Risk tolerance is a specified risk appetite, and it most commonly takes a specific value that can be tolerated. The types of threats may have a varied nature when it comes to their impact on an organization. While tolerating risk, we should be aware that its occurrence may be associated with, for instance, a delay of a given component delivery. Sometimes, the consequences are more far-reaching and less evident such as legal problems or incompatibility with external integrations. It may happen that impacts reach the level of an entire organization, such as portfolio management or employee structure.

Following the example above, someone who hosts a blog can easily tolerate the fact that the data transfer rate on the blog will decrease by 30%. Meanwhile, a bank can afford only 1% of a slowdown. So, until a threat posed by the risk is lower than our risk tolerance, we can easily accept it or assign it a low priority.

Company policy

Some managers take offense when someone mentions that the company policy has a real impact on priorities in risk management. In my opinion, it is closing one’s eyes to an obvious thing. If for a client or top management in the company a given aspect of the project is essential, regardless of the reason, a good manager ensures that it does not become a bone of contention because of which the manager and the team are put in a losing position.

Of course, the reason for the dispute is important. When it all got to this point because something needs to be done just to make someone feel better, it is up to the manager to explain and negotiate. However, just like in the case of risk acceptance, the manager has to have the knowledge at first, and only later make informed decisions.

Summary

Prioritizing is present in all aspects of the project management, especially regarding the order of work on the project requirements. Risk is nothing more than another project requirement, except that working on it is significantly less predictable and a bit more frustrating.

When assessing risks, it is worth remembering that risks have many aspects, so we should not focus only on one parameter, for example, potential damage. A more in-depth analysis may reveal that the damage is pretty significant but unlikely to occur. And if it happens, it will be in a year; and even if it happens, the business will accept it.

Regardless of the techniques used to work on a risk, the key to success is — as always — regularity. Even a mediocre approach to risk management is much better than an exemplary, orthodox process that is presented only once and forgotten two days later.