Project Manager’s Checklist: Risk Management

What is the risk

Risks management is a main headache for the Project Manager. If everything everywhere would go without issues, then everything would happen as planned and life would be boring. Our day-to-day reality is that some things go in a different way than we planned, assumed, or predicted. The things that may go different or that may happen and influence the project are called Risks. They have not happened yet, but there is some probability that they will happen and harm the project or bring some benefit to it. So far, our role as a Project Manager is to increase the probability and impact of positive events and decrease the probability and impact of negative events.

Risk management process

The PMBOK has a great definition of risks management processes. Everything starts with the Planning of the Risks Management on the project, during which, the Process Planning Group defines how we will work with the risks. It can define approaches, technics, tools, and templates that should be used. The next phase is Risks Identification. In this phase, we make our best to identify all possible risks that may happen. After that, we perform Qualitative and Quantitative risks analyses. Then we need to take decisions on what risks and how we will handle during Plan Risks Responses phase. The final process is Risks Controlling. It lasts for the whole phase of the project execution and ends at the end of the project.

Risks Identification

How do we know about the Risks that may occur at a specific project at all? This is a good question. The process of gathering all of the risks is called Risks Identification. It starts right after all main plans, stakeholder register, scope baseline, activities cost, and durations are ready. Read about Stakeholders management in detail, in my previous article Perfecting Stakeholders.

There are quite a lot of technics to use for risk identification, and you can choose any technics that you like. Some of the popular technics are documentation review, Brainstorming, Delphi technique, interviewing, and root cause analysis. I prefer using Brainstorming with root cause analysis because they help to identify quite complex and non-standard risks.

Let’s take a closer look at Brainstorming technique. To identify risks, we need to pass through the following steps:

1. Brainstorm on possible catastrophes.
2. Build scenarios for this catastrophes.
3. Analyze root causes of this catastrophes.

The first technic is Brainstorming. The main idea is to gather the planning working group and delve into all risks you can think of. You can use a few hints to make this event more productive:

1. Ask a direct question in the form of a nightmare – what is the worst outcome of the project you can think of?
2. Use a crystal ball – imagine that you have the ability to look into the future. Imagine what newspaper headlines can be dedicated to failures of your project.
3. Describe controversial views on the future – ask to describe the most positive and successful outcomes of the project and then the worst possible.
4. Ask about a failure that has no guilty person – How a project can fail without anyone guilty in it? Competitors? Nature? Etc.
5. Ask about a failure where there is a guilty person – how can we fail the project? How can Customers fail the project? How many team members can fail the project?
6. Describe a partial failure – Imagine the case when the project succeeds, but one or more of the stakeholders would be unsatisfied or angry.

Brainstorming sessions can be very emotional and exciting, and it would be great if you have a dedicated person to take notes about the raised items. Another barrier to overcome is the closeness of the group. Your group members should not be shy or afraid of one another to bring up the craziest ideas ever.

At the final step, think and gather the root causes of every one of the scenarios. The root causes are the risks that may affect the project and the trigger for this risk to happen.

The resulting list of Risks should be transformed into Risks registry. Further, you will need to perform qualitative and quantitative analysis of every Risk. The results of such analyses will be estimations of probability of occurring of every Risk and the impact the Risk may have on the project. The difference of the results of qualitative and quantitative analyses is that qualitative analysis deals with descriptive Risk qualities, i.e. whether the probability of the Risk is high or low, while quantitative analysis produces numeric estimates of Risks effect on project budget, schedule, etc.

Risks Qualitative Analysis

The impact of a Risk is determined according to the degree of harm or benefit it may produce. Correspondingly, we divide all Risks into two types: Threats and Opportunities. Threats have a negative impact on the project, while Opportunities have a positive impact.

Opportunities bring no danger for the project, so let us focus on Threats. So far basing on these two characteristics of Risks, we may already classify them. Let us measure the likelihood of risk appearance with the following values: Hi, Hi-Medium, Medium, Medium-Low, and Low. The impact we will measure with the following values: Insignificant, Mild, Moderate, Significant, and Catastrophic. Now we can build the Risks Heat Map, where we can put all the Risks that we have.

All risks that got into the red area have a high probability or high impact – they will definitely happen or impact from them is huge. We need to address them first. There is no reason to start the project, while we have Risks in these squares.

The next area of Risks is marked with yellow – the probability of Risk happening is medium or impact from the Risk is not huge. It will be bad if this Risk will happen, but it should be quite easy to overcome it. We need to reduce to a minimum the number of Risks in this section, but if we will have a few, it should be ok to start the project.

The last section of Risks is the green one. We love these Risks since they have a low probability or low impact. These Risks should be very easy to overcome if any of them will happen at all. We can have quite a lot of Risks in this section, as they will not influence the project much.

In practice, the company will define more gradation levels and strict rules on the Risks classification. The rules can be defined with respect of different factors, like:

Meaning that you have to evaluate impact by four parameters – Budget, Schedule, Scope, and Quality. The resulting value will be the biggest of the four. For example, if certain Risk is Mild by Schedule, Scope and Quality but Significant by Budget then this Risk is Significant.

One type of Risks deserves special mention. This type is risks-catastrophes – if this Risk will happen then the project loses its value and can be closed. Moreover, we cannot take any actions to Reduce, Avoid, or Transfer this risk. The only thing that we can do – add this risk into the list of identified risks, treat it as the assumption of the project and delegate managing this risk to the project Sponsor. When this risk will happen, then he or she has to take a decision on what to do with the project.

With opportunities, we work the same way as with Threats, just with a small note that we want them to happen, and the higher probability of happening and impact the better.

Risks Quantitative Analyses

The Quantitative Analyses are done to determine how risks will influence the schedule and budget of the project. A few interesting techniques can be used for that – interviewing to get estimations for Low, Most Likely, and High costs changes, sensitivity analyses, expected monetary value analyses (EMV), modeling, simulations, and expert judgment. We will not go into the details of these techniques in this article, as they deserve a separate discussion. Just want to mention that, depending on the size of the project, the time dedicated to these activities can wary. If the project is short-term, then this activity can be simplified or skipped.

Plan Risk Responses

Having the information, you can sort all of the risks into a few groups and focus on the most critical with the biggest impact first. You have four choices what to do with such risks – Avoid, Accept, Transfer, Reduce. Let us go in a bit detail with every one of the strategies we can agree to do with the Risk.

Avoid (Avoidance) – What can you do for not having this risk at all? Can you stop using or change some framework? On the other hand, you can outsource the complete functionality or part of the functions, like call center support. Can you remove the complete feature from the product?

Accept (Retention) – Some risks are so unlikely (a war) or low impact (slight changes in cost or time) that an optimal solution may be just to embrace and do nothing about them. Still, we can introduce a contingency plan to overcome the results such risks incur. For example, book additional money or time to fight with outcomes of the risk, book money to increase salary.

Transfer (Sharing) – Move the risk to someone else. Hire a subcontractor to make a specific type of work.

Reduce (Reduction/Mitigation) – Take steps to reduce the cost of loss or probability of happening. This is the most widely used approach for handling the Risk. The concrete approach may differ from Risk to Risk. For example, to reduce the effect of a person leaving the project, we can introduce a rule to have at least two persons familiar with some area at the same time. Alternatively, we can introduce as a must the peer programming on every feature of the project. To reduce schedule risks – split all features to subtasks and estimate with smaller granularity and a better understanding of the subtasks. Yes, this takes time but on the other hand, it reduces the risk of underestimation.

So far, we are getting to the format of the Risks registry table to be used when working with risks. Its different sections should be filled during different stages of the Risks Management Process.

Control Risks

After the risks have been analyzed and all actions planned, we need to proceed with updates to Project Plan. We need to add the required time, money, updates to the development process and even team composition, which may change. However, this is not the end of the work with risks. We need to keep track of the identified risks, constantly monitor, analyze, and respond to new risks, monitor triggers conditions for contingency plans and review the execution of the planned risks responses. At this stage, it requires much less effort than at the project-planning phase. This process ends at the end of the project.

Main risks we handle on daily basis in software development

On a daily basis, Software Project Managers handle many different risks. Here is the list of risks that we meet most often:

1. Misses in calendar planning
2. Unrealistic time and cost estimates
3. Frequent changes in requirements
4. Staff turnover / changes to membership of the project team
5. Low performance
6. Delays in providing of permissions, accounts, etc.
7. The project involved the use of new technology / unstable technology
8. Lack of Customer management commitment and support
9. Delays in communication, replies, and answers from Customer
10. Failure to manage end-user expectations
11. Unclear / misunderstood scope/ objectives
12. Misunderstanding of the requirements
13. Artificial deadlines

The Project Manager has to have the skills and experience to identify and plan risks actions. In most of the cases, you need to be creative to properly identify, plan, and handle risks on the project.

In the end, Risks Management is an inherent and critical part in the work of the Project manager. Look ahead, keep the positive mood and have a productive risks hunting on your projects.

• #Establishing Quality Process
• #Industry Standards Compliance