Risk Management is an activity with low priority in most of the teams I’ve been a member of during my professional life so far. Reasons vary, from tight schedule to a false feeling of safety that emerged from (sometime long) time a team spent together or a successful history of avoided critical situations.

In order to manage something (be it a risk or anything else) one have to know it in all details:  a risk is defined as a potentially dangerous situation that, if materialized, could cause harm or losing something valued. Taking a risk in day to day life is not unusual and this is generally accepted if the gain exceeds the potential loss. Or, to be more accurate: a risk is accepted if the potential loss is lower that the costs of actions that are to be taken in order to decrease it (the loss) and/or the probability for the risk to materialize.

Managing the risks have (basically) two meanings: awareness (there are things that may go wrong) and preparation (should something wrong will happen I will not be caught off-guard).

Same considerations apply when it comes to risks in IT-world. When we discuss about IT projects involving many persons and higher entity relations (company-to-company) the loss could go beyond money: market credibility can be shattered and (under extreme conditions) companies went bankrupt because of that.

The main purpose of Risk Management strategy is to identify as much as possible of anything that could go wrong during project lifetime and also BE PREPARED in case the risks (previously identified or not!) will materialize. This preparation covers two aspects: mitigation (take actions to reduce the probability for a risk to materialize) and contingency (have an action plan to reduce the loss and have a quick recovery if a risk materializes).

Having a Risk Management strategy in place also reduces the risk (sic!) of ignoring things that can go wrong (but otherwise predictable); it ensures that everyone (project team, client, management – all stakeholders) is informed in a timely manner, so that if a decision is to be taken , it will be a fully informed decision. It also helps not to make the same mistakes again! The benefits of having a risk management in place can range between 0EUR –no gain (or lose) at all, in the ideal case when no risk is ever materialized- and NOT lose a customer.. The real question here is not “should we do risk management?” but “are we ready to accept any potential (yes, potential.. until something goes wrong) loss?”

I have to mention that Risk Management is also an important part of the project management activities according to various industry standards or models, such as CMMI model (it is a maturity level 3 process), ISO9001 or ISO27001.

If you agree with me and get to the same conclusion that Risk Management at project level is not something of a low importance, let’s see how an organization can help and support this in project teams:

1. Formalize a risk management process that can be used as a model or starting point, perhaps using one of the standards or models mentioned above;
2. Have a set of risk identification guidelines available that will help the project team during the initial risk identification and assessment;
3. Formalize the risks and issues (materialized risks) reporting mechanisms;
4. Emphasize –for the entire organization- that everyone is responsible to identify and report risks during his/her day-to-day activities;
5. Promote the good practices observed; have a best practices repository where one can find examples to follow. A project or team can benefit from another one’s experience!

To wrap up: formalizing Risk Management into a plan (or strategy) will allow you raise the awareness and to easily monitor all the activities that are to be performed, decreasing the probability to overlook something and to be forced to react to an unexpected situation. You will have the luxury to act proactively against a potentially dangerous situation, without constrains induced by urgencies that usually comes with the “unexpected”. Take advantage of the knowledge base available in our organization and contribute to it with your own experience and lessons learned, so no one will have to gain its experience “the hard way”

 [First published on ISDC technical blog (internal), January 2016.]