Risk Management
Risk management is often one of the most overlooked responsibilities of a project manager or even from the organization as a whole. If approached and managed correctly, there are generally less problems associated with the project. This means that, if management, the organization, or team members don’t have a good understanding of risk management, then this avoidance of problems can be attributed to luck or coincidence rather than proper management of risk. This misinterpretation can cause further issues down the road on the same or future projects by undervaluing the importance of risk management. Risk can be ignored but it can’t be eliminated. Even by making specific choices to avoid as many risks as possible, there is still a risk that choosing this more conservative route will result in negative impacts on the project outweighing the already minimal benefits of this approach. Since it can’t be avoided, it is important to directly focus on it and understand how to manage it properly. There are generally three approaches to risk and payoff, risk-averse, risk-neutral, and risk-seeking. There isn’t a right or wrong approach, but rather what the organization or stakeholders deem acceptable for the project. A risk-averse approach tends to avoid as much risk as possible. A risk-seeking approach allows for greater risk to be involved in the project. Finally a risk-neutral approach tries hold and even risk/payoff balance without drifting one way or another. There are several processes involved in approaching and managing risks but today we’re going to focus on qualitative risk analysis.
Probability/Impact matrices
One approach to analyzing risk is by using a qualitative risk analysis. Using this approach often utilizes a probability/impact matrix to create a list of identified risks based on their magnitude and priority. This usually involves the stakeholders for the project coming up with and providing any risks they can come up and evaluate their likelihood and impact on the project. This helps identify which risks need to be more focused on. It is then up to the project manager to create the probability/impact matrix of the risk probabilities and impacts. Below is a sample matrix of risks.
(Schwalbe, p. 482)
In the above matrix, risks 1 and 4 have both been analyzed as a high probability of occurring and a would have a high impact on the project. Logically, these should be the first for the team to work on in terms of planning risk responses for if they do occur. Afterwards, depending on the risk approach for the project, which risks the team focuses on next will vary. It is up to the team to determine what qualifies as “high”, “medium”, or “low” impact/probability, but it should remain consistent throughout the process to ensure an accurate plan and response. In an agile environment however, the project could evolve to the point where the original determining factors for risk’s are no longer accurate or feasible. In this case it is up to the project manager and stakeholders to determine the correct changes moving forward with the updated evolution of the project. According to Schwalbe, “It may be useful to create a separate probability/impact matrix or chart for negative risks and positive risks to make sure that both types are adequately addressed. Some project teams also collect data on the probability of risks and the negative or positive impact they could have on scope, time, and cost goals. Qualitative risk analysis is normally done quickly, so the project team has to decide what type of approach makes the most sense for its project.” (Schwalbe, 2018, p. 482)
Top Ten Risk Item Tracking
Another tool used during the qualitative risk analysis phase is Top Ten Risk Item Tracking. This tool is more useful in agile environments as it keeps track of risks as they change throughout the life of the project. While not recommended, it’s possible that how risks are gauged and defined changes over the life of the project. If this occurs, it should be well documented, and anyone involved with the risk reports should be informed.
Below is an example of a Top Ten Risk Item Tracking monthly report issued to stakeholders of the project. In this example the chart is only showing the top five risks out of the top ten. The chart also keeps track of the risk’s rank for this month and the previous month as well as how many months that risk has been in the top ten. Each month the resolution progress will update with how the team is responding to that risk.
(Schwalbe, p. 484)
As the project evolves, a continuation of tracking is more important to see which risks are evolving with the project and how. It is important to keep stakeholders on the same page with this process since they might have solutions to these risks that the project team might not otherwise come up with. It’s also possible that risks evolve into such a high probability/impact that the stakeholders choose to shift their risk approach to be more risk-averse or vice versa based on the risk’s ongoing status. Depending on the project these reports might be more or less frequent and should always be unique to the project. As always in an agile environment, flexibility is a must, and the project manager should shift to match the project’s necessities in terms of time frames.
Bibliography
Schwalbe, K. (2018). Information Technology Project Management. Boston: Cengage.