Managing risk in an IT project – how to identify the risk?

1. Risk register

A handy tool that combines all information about risks in a project is the risk register. It is a set of information about every risk in a given project, containing their characteristics and response plan for each of them. The register often takes the form of a table, where each line corresponds to a particular risk, and columns describe the features of these risks.

The Internet is full of templates for the abovementioned tool, that is why I will just summarize what, in my opinion, should be included in such a document.

• Type of a risk. Is this a risk, a malfunction, or maybe an opportunity? Is the risk external or internal? There are many types of risks, and every manager should adopt their own classification that fits the type of project. (ITIL takes into account differences between a Risk and Issue; however, we will leave reflections on this subject for another occasion.)
• Who detected the risk, and who is responsible for it? That is, who is responsible for the implementation of a solution and with whom we can contact to find out more.
• Status. For example, open, in progress, closed.
• Description (and, optionally, reasons description — the root cause.)
• The probability of an event. It may be referred to as percentage or in a descriptive form, for example, low, medium, high or very high.
• The level of threat (impact.) Just like with the probability, we can determine the percentage or describe it. Additionally, it is good to indicate which aspect of the project will be harmed: is this the scope, time, budget or maybe quality?
• What do we plan in this regard?

Besides, we can try to include additional information in the register (but be careful, do not add too many, more in section 3)

• A calculation of risk severity based on the probability and threat. It gives us a bigger picture of the situation. The very information that the risk is high indicates that we must take care of it as a priority. However, combining it with an annotation that the risk materialization is not very probable makes us set it aside. Nevertheless, that does not mean that less likely risks should be ignored. It is just about defining the order and priority of a given threat.
• A calculation of risk costs in the currency — more in the next article.
• Backup plan — describes what happens in a situation when our main preventive plan fails and the risk comes true.
• Result. How the case was ended.

2. How can you collect information?

We already know where we can store information about risks. How can you find out that they exist and how can you identify them?

• Brainstorm. It can be held during team meetings, while planning a project (for example, in Scrum) or during specifically dedicated sessions. It is an effective method that enables you to quickly define many risks, discuss them right away, and determine what to do with them next.

Often, managers settle for this one way, which is useful but it is also greatly incomplete and defective. According to my experience, many risks are identified by persons outside the project team — further stakeholders, customer specialists, or members of other teams. That is why I supplement the classic brainstorm with other two essential elements.

• Interviews. It is worth considering who, besides a small team, can provide us with relevant information? Sometimes, it is a customer expert, who has no clue about technology but is perfectly familiarized with what our product will be used for. Occasionally, it can be someone from the infrastructure maintenance team, who will inform us that they have scheduled a maintenance break on the day of the planned implementation. As always, it is not worth overreacting, but it should be taken into account.
• Risk register available at any time. You know the situation in which someone asks you to tell a joke, but suddenly you do not remember any even if you usually know thousands of them? Planning risk identification is similar. The vast majority of risks appear spontaneously during everyday work and they must be noted then. Therefore, it is so important that a project manager reminds of it to the team members and that the register itself is user friendly and not too extensive, so that the people want to note anything in it.

3. Obsessive analysis trap

A risk register is as good as the quality of the information included in it. Fields and data can be added indefinitely, but unfortunately this solution is almost never right.

In practice, many managers create this register at the beginning of a project (when they are still willing to do it), identify several risks in it, and no one never again checks the register later. Optionally, they do this from time to time.

The reason may be, apart from laziness, too extensive register content, meaning too ambitious approach to the issue. Every document, register, or another Excel file prepared quickly adds us more maintenance work. Therefore, it is essential to think three times if we really want to introduce a document to our project because, later we will have to update it and perhaps extend it.

A situation like this is harmful in three ways: we have outdated information that someone could confuse with the up-to-date; we create a precedent that some documents may be incomplete, and we cause the feeling of chaos in the project.

Reality can be described indefinitely, and initially every information can seem useful. However, its later maintenance costs us a lot of work.

It is better to have 30% or even 50% less information but useful, easily accessible and up to date!

Summary

If our project is a massive undertaking, a strategy of risk management can be based on a single document that is the main source of knowledge about the condition of risk management. Obviously, in this material, I have described the minimal requirements for the identifying and collecting information on this subject. If, by any chance, you build another Burj Khalifa, I encourage you to broaden your knowledge about risk management significantly.

However, if you do not break world records in architecture, I encourage you to have the amount of documentation as small as possible, whereas the awareness and capability of risk identification as broad as possible.

It is not difficult to fail while implementing an IT project — we have written about it in How to fail while implementing a new IT project? The anti-guide.