How To Analyze Risks To Mitigate Risks: Part 1

Risk Analysis & Mitigation: Part 1

By Kimber Householder

All projects have risks.  Understanding the risks and how to avoid / recover from them are key to successful project management.

Spending the time to analyze and mitigate risk before undertaking a project can save you heartache, worry, and money in the long run.  We all inherently identify and analyze risks at different levels of detail.  

But what are the risks?  How should they be classified and mitigated?  

Let’s start with a few definitions:

• Risk as related to project management: something that could occur and have an impact on the success of the project.  It’s important to remember that a risk is an issue that hasn’t happened.
• Mitigation: define how to actively avoid or reduce the severity or seriousness of the risk.
• Risk Analysis: activity performed to determine which risks need strongly defined mitigation strategies. This is done by determining the probability of the occurrence as well as the impact of the risk.  Risk Analysis typically uses a rating table where the higher probability of a risk and the impact moves the risk closer to the critical / red area awareness.  
• Risk Manager: Someone who solves problems you never knew existed in ways that will blow your mind.

To perform risk analysis and mitigation, the following activities should be performed:

1. Identifying Risks
2. Categorizing Risks
3. Analyzing Risks
4. Mitigating Risks
5. Embracing Risks

This blog, part one, will cover Identifying and Categorizing Risks. Stay tuned for the follow up, Analyzing, Mitigating, and Embracing Risk. 

Identifying Risks:

Vital to risk analysis and mitigation is first to identify the risks.  For a mid-size to large project, a formal risk session is recommended.  During this session (see blog Conference Call Efficiency), the project team brainstorms possible risks and creates a risk ledger.  The project manager or appointed risk manager records each risk with enough information to perform analysis and categorization.  The risk ledger is created or updated and published with the weekly status report.  Throughout any project, an experienced project manager is performing continual risk management. 

Having team members – including customers – involved in the risk session helps the project team understand what to keep an eye out for and how to identify risks during their day-to-day work.  Issues are easy to identify since they are currently happening, but risks are a bit more difficult.  Frequently some team members don’t want to voice “what if” thoughts because they don’t have confidence in risk analysis.  Having team members voice “what if” thoughts keeps the team aware of the possible impact rather than be caught by surprise when it becomes an issue.

While each industry would have a slightly different baseline to conduct a risk session, I’ll be focusing on software and management consulting projects based on my experience.  From my experience across multiple industries, this structure can be used in most industries, from software and management consulting to film production. The baseline for a risk session should include:

• Agreed upon scope
• Timeline for milestones and deliverables
• Resources
• Roles and responsibilities
• Budget – this does not need to be financial, but should include budgeted hours expected from each participant

The baseline provides the focus for risk identification.  What could cause the scope to change?  A deadline to be missed? An overrun of hours?  During the risk session, the risk should be recorded in a risk ledger with information about what the possibility of occurrence is, the potential impact to the project, and how the risk could be mitigated.

During brainstorming sessions, it is ok for out of the box risks to be identified.  For example, what if a pandemic hits? When it comes down to it, the risks to focus on are high probability and high impact.  Studies have shown 80% of the outcomes come from 20% of the inputs.  Carrying that to risk management, 80% of the problems will come from 20% of the risks.

Take this example:

• Risk: The custom report may take longer to create than allocated in the budget.
• Possibility of occurrence: Moderate; it is a new report and the content, and its use isn’t yet clearly defined.
• Project Impact: Moderate; while there are not any downstream dependencies on the report, if new data values are required to be available there could be an impact on data configuration, population, and dictionary
• Mitigation: Mockup a sample of the report early in the project with a specific milestone data for agreement.   

Categorizing Risks:

Depending on which article you read, you’ll find anywhere from 3 to 20 types of risks.  This is due to industry differences, the type of project, and the point of view of the person defining the risks.  A day trader will have a different list of risk categories than a pilot or a farmer or a warehouse manager.  Project managers work in all industries, therefore there is no “one” list.  

Based on my background, I will be focusing on software and management consulting risks.  The categories I focus on are:

1. Scope Creep
2. Financial
3. Resource

Identifying risks is not a one-and-done activity, nor is it only done by project managers.  

Scope Creep

One common risk is “scope creep” – which is defined as when project requirements change once the project is started.  Being aware of scope creep is important throughout the live cycle of a project.  Some amount of scope creep is common, but it can quickly take a project off a path of being successful if the project team loses sight of the project purpose.  Identifying areas with the potential to “creep” the most is important with risk analysis.  Some of the common areas of scope creep:

• Custom reports or screens – anything user interface driven has a potential to creep scope unless the report is existing and is to be reproduced in another system.
• Training – typically, the number of training sessions and people per session are specified in the contract but it’s very easy to “add one more person” or “while you’re here, can you train this group also.”  Consultants want to do what is right for our customers and if times allows, we’ll do a little bit extra – but that could impact other aspects of the project.
• Changes or additions to product features
• Documentation

From a consultant perspective, scope creep is best mitigated in the contract, but sometimes there isn’t enough information to include at the time of contract execution.  Reviewing the scope detailed in the contract during the risk session helps everyone to understand the scope boundaries as well as help to identify areas where more details could cause an impact to the project.

Financial

Project financial budgets are created using the best knowledge available.  During the risk session, reviewing the budget for specific items will help to identify potential areas up front.  Most of the financial risks I’ve encountered on projects were specific to travel or the purchase of goods:

• Travel budget – the project travel budget is typically either a percentage of the total project fee or a budget for “per week / per resource” travel.  Since 3rd parties are depended upon for pricing, there is a lot of variability with flights, hotels, and car rental fees.  Once the resources are identified for the project, any potential financial risk can be identified and communicated with mitigation options outlined.
• Material budget – this could be for software, hardware, shipping, etc.  Typically, customers have separate contracts for the material items but when they are included in a consulting contract there is a chance for a project impact

Resource

Resources – both people and assets – are typically the largest area of risks. 

• Vacations – project timelines and vacations don’t always mix.  If a key resource is planned to be on vacation shortly before or after a critical project activity, there is a risk that the schedules will collide.  Remember, if there is a collision already, it’s an issue not a risk.
• Unplanned absences – life happens and with the pandemic, there is a different level of variability than we’ve experienced in the past.  Which resources have the largest impact on the project if they are out for a prolonged period?  What can be done to mitigate their absence?
• Hardware/software outages – the cause could be locally and short term (power outage due to a storm) or mid-term (natural disaster).  Where are the potential risk areas and project impacts?

Part 2:

Stay tuned for Part 2 which will cover analyzing, mitigating, and embracing risk.  Remember – identifying the risks is vital for risk analysis and mitigation. Need help identifying risks? Contact Idenhaus today for help bringing everything together.