Project risk management fundamentals

In this final chapter in our series on software project management, we have some advice on risk management. As a project manager of an IT project, you can avoid many risks by careful planning and good communication. 

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

What you should do before risk management

In a very generic sense, almost any activity that a project manager does is risk management. Any task that is not executed correctly will cause some risks. Performing the task correctly or checking whether the task has been done correctly is thus risk management. This way of looking at project risk management is however not helpful in practice. It replaces concrete tasks with vague risks and thus makes the project harder to understand. What we therefore recommend is to first do the following right:

• To manage the risks of lacking functionality: Create a clear scope list of product backlog with user stories. Validate this list with stakeholders
• To avoid risks related to non-functional requirements: Identify non-functional requirements and make them smart and flexible
• To avoid the risks of not having resources available: create a clear schedule and share this with team members so that they can check the schedule against holidays and other absence.
• To avoid legal, security and organisational risks: plan short actions for each organisational aspect (check: COPAFIJTH). Communicate the overall plan with stakeholders and ask for feedback

If you do these steps correctly, you should have frequent conversations with all stakeholders. In these stakeholders, they will probably mention residual risks that are not immediate addressed in the planned project activities. These risks can be collected and managed under risk management

Risks, probability, impact and expected loss

A risk can be defined informally as an uncertain future event with negative consequences. The most basic equation in risk management is Expected Loss = Impact * Probability. For each risk, the expected loss is calculated by estimating the impact (amount of ‘damage’ in euros when the event occurs) multiplied by the probability that the event occurs. In our risk management templates, we create lists of risks with impact and probability, and create a risk matrix that visualizes which risks have the highest expected loss. Typically one wants to address the risks with the highest expected loss by taking mitigating actions. For instance, if the impact of power loss is extremely high, one should buy a backup generator. In The Netherlands we typically do not take any measures against earthquakes, since the probability of a major earthquake in The Netherlands is extremely small (less than 0.1% in any year). (image source: wrike.com)

Typical software risks

As a source for inspiration and discussion among project teams, we have listed here some commonly occurring risks in IT projects. We recommend you to discuss whether these risks apply to your project:

• Unplanned staff absence
• Unavailability of infrastructure
• Insufficient availability of users for testing
• Usability issues
• Performance issues
• Security issues
• Staff illness or other unplanned absence
• Staff turnover and need for replacement
• Discovering that estimations have been too optimistic
• Necessary elements are not in scope
• Privacy issues
• Hardware design issues
• Battery life issues
• Internationalisation issues
• No need from users for product
• Cultural issues in international projects

Not listed here are three generic risks that apply to almost any project and are typically caused by underlying specific risks. It can be helpful to assess the impact of these risks. The probability of these risks should be estimated by looking at the underlying risks:

• Cost overrun: is there an acceptable margin? At what level of costs is the project not worth doing?
• Schedule overrun: What is the impact in euros for each week of delay?
• Quality issues: The impact is typically an extra iteration to fix the issues. Is this possible and what would be the costs or other effect?

Types of mitigating actions

For each risks there are often many actions or responses that could be taken. The cure can however be more expensive than the risk itself, so one should should do a careful cost benefit analysis. To help identify all possible actions, we recommend the mnemomic PRACT. The PRACT actions are:

• Prevent: take action to circumvent the risk completely
• Reduce: Reduce the probability of the event occuring
• Accept: Do nothing as the cost of measures is higher than the value
• Control: Reduce the impact of the risk, for instance by taking action now or planning and rehearsing the right response when the event occurs
• Transfer: Transfer the costs of risks to another party, by making them responsible or buying insurance.

These actions together should yield a new risk matrix, with an overall expected loss that is acceptable for your organisation. For large projects, one should not just do risk management in the beginning, but also during the project. All risks should be checked during the project, and new actions might need to be planned during the project if risks have increased or new risks have popped up.