Managing risk in an IT project

What is risk?

Due to its nature, risk may never materialize and, what’s even worse, we often don’t know whether it’s because we have done something to avoid it or not.

Let’s start from the basics. What is risk and why should we manage it?

According to the PMBOK definition, “project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. The first thing that is conspicuous is the fact that this is an uncertain event. It’s contrary to the events that are certain, e.g. a deadline (as well as death and taxes).

However, it is less obvious that there are positive risks, commonly called opportunities. For example, it possible that adding 10 more functionalities to an application won’t slow it down, or that we can deliver something more this month if we are not disturbed by meetings, etc.

Positive risks are not just semantics and another artificial, pseudoscientific division. Most of all, they remind teams that while they are tackling threats, they should not leave opportunities to luck or chance.

Why should we manage something that doesn’t exist and should better not occur in most cases?

There is no reason to go deep into the very sense of risk management. It is obvious that when you are planning any venture, even if it is just taking a walk, it is worth considering whether you should take an umbrella with you. It is similar with projects: counting on your luck sometimes pays off but in the long run it leads to serious consequences.

However, due to the fact that foreseeing and preventing risks are sometimes  time-consuming and expensive (and usually it is so), we are often tempted to set aside  negative thinking and focus on the thing that we assume to be the real product value.

Thus, who cares about risk management and who should care about it?

Anyone should care, but who really does is another story. Sometimes nobody cares. Unfortunately, this paradox is deeply rooted in short-term interests of each person engaged in a given venture.

In a classic IT project, the development team is supposed to “deliver the product before deadline, below budget and of sufficient quality”. The basic interest of an employee is to complete all tasks without too much effort.  And you can’t resent your employees that they do what they are asked for, and usually as well as they can. Highlighting potential problems is often regarded as grumbling or unnecessary negative approach. In the present working culture, especially in corporations, the badge of a problem seeker is a heavy burden and can completely hamper your career.

Therefore, in theory, it is the management (in broad sense) who should think of risks. In the end, they are the ones who suffer from the consequences of potential events. In real life, no one usually thinks about it: safeguarding against risk takes time, work and money which must be somehow reasoned, and the positive result of this would be that NOTHING will happen.

Mediocre managers focus on communicating success, burying threats and blaming others in case of failures. Clients are often not aware of the number and size of the failures or — due to the lack of proper knowledge — they tend to simplify the problem.

Business is risk: protecting from everything will make a project a never-ending and uneconomical story, and the project will become obsolete before it is launched to market. We have already explained how easily an IT project can fail in this article. That’s why risk is managed not just eliminated. Often, it is a good choice to accept the risk, but if we don’t have proper knowledge and related procedures in place, our action is not a business decision but mere gambling.

Summary

A good manager should be able, at the very beginning of a project, to identify basic risks, explain the client / project owner the need to perform cyclic observation and to make an investment in the process of managing the risks, as well as create a budget reserve which will be used if an accident happens.

In the following articles of this series, I will tell more about types of risk, identification techniques and risk evaluation in a project budget.