Wednesday, 7 August 2019

Qualitative Risk Analysis for IT and Software Development Projects


If you have been following the unravelling of Phoenix, the Canadian governments new payroll system, you are aware of at least one major IT or software development project that has suffered catastrophic failures.  It is not alone, if you have them time, Google “software project failures” and it will return, the IEEE’s Software Hall of Shame is perhaps my favorite. At this point, you will probably come to the same conclusion shared by many in industry that IT projects can be extremely risky and prone to uncontrollable overruns and failure to deliver planned capabilities. IT Projects experience more risk than most other types of projects, a phenomenon that suggests that IT project managers would be wise to manage and hopefully minimize project risks. Now that we have made the case that if you are the PM of a IT project you need to manage risk, here is a brief overview of how you can quickly put one in place.             
First, you will need a risk management plan. Risk management plans outline who, what, when, and how (why was covered earlier). The plan can be a simple document that outlines how risks will be managed through the course of the project. It includes:
-          how you will identify, assess, and control risks
-          when activities will take place,
-          how you will communicate your plans to stakeholders.
Second, from the risk plan, you can develop a risk register. A project risk register is central to capturing and maintaining the information required to identify, assess, respond, and control your risks. Risk registers are commonly spreadsheets set up to track and assess risks. Common information that is tracked in a risk register:
Name
Descriptive name of risk
Description
If … then statement
Risk ID
Unique ID
Date Identified
When the risk was first identified
Likelihood
Probability or chance that a risk will occur
Impacts
Impact to project schedule, cost, quality, etc.
Severity or Score
Calculate level of risk severity
Owner
Person responsible for risk
Mitigation or Response Plan
Description of how and when the risk will be managed

The next step is the Risk Assessment, in which potential risks are identified and then assessed for their potential impact on the project. To identify risks, you can use several processes, including expert opinion, historical data, risk workshops etc. Once risks are identified, your team can then assess them based on criteria outlined in the risk management plan. For qualitative risk assessment, you can set up a simple probability and impact matrix that outlines how your project will assess probability and impacts. Here is an example that could be used on a small project:
Assessing the risk requires a simple multiplication of the risk probability by the highest impact rating using the numeric values . So for example, if a risk had the following assessment of:
Probability
Cost Impact
Schedule Impact
Quality Impact
4
3
4
4

The risk score =  Probability x Highest Impacts Score = 16
Risk scores can be converted to a rating. Using color help highlight the risk severity rating.
Rating
Score
Insignificant
1-5
Minor
6- 10
Medium
11- 15
Serious -
15-19
Critical
20 - 25

With the assessment completed, the next step to develop your strategies to manage individual  risks based on the assessment. Commonly, these strategies are: Avoid, Transfer, Mitigate, or Accept. Regardless of the selected strategy, any actions associated with plans  must be documented and include the person responsible, when it will occur and any costs associated with the plans.
Finally, during project execution, you monitor and control risks. This includes regular status updates (reviews) of existing risks monitor any changes and ensure controls are working. During project execution, schedule periodic risk sessions to include any new risks. The results of the risk reviews should be included in the Risk Register.
Final thought, keep it simple. Like many things in life, the best results come not from perfection, but from consistency. Keeping your risk management simple and paralleling your development process, will help to ensure consistency and ultimately better results.