Every project has some risk of failure. Identifying and planning ahead to avoid these points of failure is one of your top responsibilities. This guide on project risk management will help you understand and manage risks better.
If there is one thing you can be certain about in project management, it's this:
Every project carries some risk.
A critical resource might drop out. An important component might take longer to produce. A key stakeholder might not sign off on deliverables.
Anything can - and often does - go wrong on a project. Putting out these fires is your job as the project manager.
But things don't have to be that way. If you plan ahead, you can make fighting fires much easier (or even avoiding them altogether).
As you might know, this process of "planning ahead" is called project risk management.
In this guide, I'll share X critical tips for acing project risk management.
1. Don't Underestimate the Importance of Risk Management
As we noted earlier, a whopping 97.5% of projects fail to meet their original targets.
For large projects (i.e. budgets > $1M), the failure rate is an astonishing 28%.
Given the high chance of project failure, you'd think that risk management would be a top priority for project managers.
But that's not the case. Only 28% of project managers "always" used risk management practices, according to a PMI survey. 14% used them "rarely" or "never".
Risk management can feel superfluous at the start of the project. When you're ready to attack a problem, it's easy to think that things wouldn't go wrong in your early enthusiasm.
It doesn't help that for a lot of project managers, developing a risk management plan comes much later in the project planning phase. They develop plans for resources, financials, and communication before they even begin to think of risks.
This lack of early planning comes back to hurt you later when team enthusiasm sags and key stakeholders go missing.
The moral of the story?
Plan early, plan often, and make risk management a top priority from the get-go.
2. Differentiate between "risk events" and "project risk"
According to the UK Association for Project Management (APM)'s Body of Knowledge, there are two distinct definitions of risk in a project:
- Risk event, defined as an event or set of circumstances that can negatively impact the chance of a project meeting one or more of its goals.
- Project risk, defined as the "exposure of stakeholders to the consequences of variations in the outcome".
Risks events are solitary incidents that can derail a project. Think of a key resource dropping out or a faulty 3D printer delaying the creation of a prototype.
Project risk is more amorphous. It is the sum of all individual risk events and all other uncertainties - said and unsaid in the project. A risk event might or might not result in project failure. But a high chance of project risk will certainly end in disaster.
Managing risk events is fairly straightforward. You can identify most common risks in a project and plan ahead for them. If there is a chance of a resource dropping out, for instance, you can have a replacement lined up ahead.
Managing project risk is much harder. There are often circumstances outside your control that you can't always plan for. If there is an executive shuffle at your client's company, for instance, an existing project might get shelved or delayed. Or an economic crisis in the client’s country causes them to halve the budget.
You can plan for these risks, but resolving them is often outside your control.
As a project manager, it is crucial that you understand the difference.
In the next tip, I'll share a process for managing individual risks and overall project risk.
3. Create separate "explicit" and "implicit" risk management plans
Dealing with risk events and overall project risk requires developing plans at two different levels.
These are:
- Explicit risk management plan that deals with individual risk events. This involves identifying, analyzing, responding to, and controlling individual risks.
- Implicit risk management plan that deals with overall project risk. This involves analyzing the project's structure, content, context, and scope.
Explicit risk management plans should be familiar to you. This is where you make a list of all components in the project and the chances of them failing. You'll look at past records, industry benchmarks, and standard practices to identify things that can go wrong.
Implicit risk management plans, on the other hand, are usually created in the pre-project phase.
This is where you analyze everything besides individual risks that can derail the project. This plan deals with the "bigger picture" of the project and its impact, not individual issues.
In the next tip, I'll share tactics for developing implicit risk management plans.
4. Use implicit risk management to identify risks before they arise
We learned above that implicit risk management plans deal with overall project risk. Rather than individual risk events (such as key piece of machinery failing), this plan plots the probability of economic, political, technical, etc. events impacting the project's success.
For example, a client comes to you with a project in a highly regulated industry. Because of political uncertainty in the client's country, there is a chance that additional regulations might come into effect. If they do come into effect, the entire project will have to be scrapped, costing both you and the client.
(An example of this would be the new GDPR regulations that have a big impact on EU businesses.)
An implicit risk management seeks to identify such situations and find ways to deal with them.
There are several frameworks you can use to identify such risks:
- PESTLE: Political, Economic, Social, Technological, Legal, and Environmental risks.
- STEEPLE: The same as PESTLE but with the inclusion of 'Ethics' in the risk assessment framework.
- SPECTRUM: Socio-cultural, Political, Economic, Competitive, Technological, Regulatory, Uncertainty, and Market risks
- TECOP: Technical, Environmental, Commercial, Operational, and Political risks.
For instance, using the PESTLE framework, some risks to the project might be:
- Political uncertainty in the client's country
- Unfavorable economic conditions that might affect end-user adoption
- The client uses an older technology that is no longer supported
In sufficiently large projects, it's always a good idea to run this analysis before you even start.
Once you've identified these risks, there are several steps you can take:
- Avoid: If the risk is significant, the best solution is to avoid it, i.e. to scrap the project altogether. While this should be the last option, it is also the safest one.
- Reduce: If you can’t scrap the project, your goal should be to minimize the impact of the risk. Your goal wouldn’t be to “meet the project’s deadline/budget”, but to “not miss the deadline/budget by more than x%”.
- Exploit: In some cases, you can actually exploit the risk to increase the scope of the project. For instance, if the client’s existing product uses an older technology, you can increase the scope to update the technology as well.
- Transfer: This approach involves transferring the risk to another party such as the client’s internal team or an outside contractor. For example, instead of updating the client’s older technology yourself, you can ask the client’s developers to do it.
- Accept: With this approach, you assume that risk exists but carry on with it nonetheless. Use it when the benefits of success outweigh the cost of failure.
5. Create an ongoing process to identify and categorize risks
As an agency grows, so does its experience of risks. After a certain number of projects, you even find that the risks repeat themselves.
Developing a process to catalog these risks can save you a ton of time when you run similar projects in the future.
There are four ways to identify risks:
- Risk repository: The risk repository or risk register should be your first stop in the risk identification process. This repository is essentially a list of all risks you've encountered in finished projects, as well as their solutions. The idea is that if there is an overlap in the project's objectives, there will also be an overlap in the risks.
- Expert analysis: Ask experienced project participants, stakeholders, and domain experts about potential risks. Interview them about risks they've encountered in past projects and any gaps based on their expert opinion.
- Checklist analysis: This tactic involves making a checklist of your current resources and processes. You then make a checklist of the resources you should have to hit your targets. The gap between the two would help you identify potential risks.
- Status report extrapolation: In this tactic, you consider all the reports available to you - status reports, quality reports, progress reports, etc. - and extrapolate potential risks from them. For instance, if the status report has too many open issues, there is a chance one or more of them could jeopardize the project.
You don't have to use all these tactics; use the ones that are right for your agency and its current situation.
Once you've identified risks, you can also segregate them into different categories, such as:
- Technical risks: Technological issues, requirements, performance concerns, quality concerns.
- External risks: Issues with stakeholders, contractors, suppliers, and the market.
- Organizational risks: Limited budget, too many project dependencies, logistical issues, resource availability, etc.
- Project management risks: Issues in planning, scheduling, estimating, and project communication.
6. Don't ignore non-quantifiable risks
There is a tendency among project managers to live too closely to Peter Drucker's maxim - "If you can measure it, you can manage it".
This plays out in managers' focusing too much on risks they can quantify, often at the cost of non-quantifiable risks. Their assumption is that if you can't quantify the risk, you can't manage it either.
This obviously isn't true. Non-quantifiable risks are also manageable, but require a different approach. You have to look beyond the data and spot problems in a more holistic manner.
There are several steps you can take to deal with non-quantifiable risks:
- Make a list of all risks to the project. Then determine the extent and the quality of data available for each risk.
- If there isn't enough data about a risk, use industry benchmarks, case studies, and even subjective data such as anecdotes. These might be less reliable, but it's better than going in blind.
- Make a list of KPIs for tracking the performance of the deliverable associated with the risk. Use these KPIs to find indicators that can help you spot chances of failure/success.
- In case of risks for which absolutely no data is available, consider alternative solutions. Two common options are avoidance (i.e. scrapping the deliverable altogether), and transfer (i.e. offloading responsibility to a third party).
- Make sure that you communicate frequently about non-quantifiable risks. Keeping everyone in the loop can often help you spot non-quantifiable risks early and take evasive measures.
7. Have better communication about risks
Risks, by their very nature, aren't easy to talk about.
For one, they're inherently negative. No one wants to disrupt a positive team meeting with the idea that the project might actually fail.
Two, we're all prone to cognitive biases. We overestimate our chances of success and our ability to affect future results. If a risk has a 1 in 2 chances of happening, we'll often assume it will go in our favor.
Between these cognitive and organizational biases, people often struggle to talk frankly about risks.
This lack of communication actually hurts your ability to manage risk. Team members who might see a looming problem keep things to themselves in meetings. Others who see a project going awry might assume that they can still take corrective action.
Solve this problem by encouraging people to talk about risks. Add a section for "failures and risks" in your project meetings. Ask people to imagine the worst-case scenario and find solutions.
The more freely you talk about risks, the easier it will be to spot them early and take action.
8. Give team members a sense of ownership in risk management
In a series of papers on the 2008 financial crisis, McKinsey reached two surprising conclusions:
- That countless people at several banks saw the financial crisis coming
- That these people didn't alert superiors about the risk because they didn't think it was their job
This is one of the dangers of the traditional top-down approach to project risk management. Team members - the people closest to risk events - can feel that they are not responsible for project risks. This creates situations like the one above - issues creep up with no one taking ownership.
A more bottom-up approach to risk management can solve this problem.
Try this:
- Involve team members in the risk planning process. Ask for their input and experience when identifying risks.
- Assign people different risk-related roles. For instance, one person could be responsible for asking risk-related questions at meetings.
- Encourage people to push risks up the chain of command if they find any.
- Empower people to add risks to the risk management plan - with sufficient reason, of course.
McKinsey’s three steps to improving risk ownership
9. Address cultural issues that contribute to project risk
Project teams don't exist in isolation. The values and beliefs your organization cherishes trickle down to the bottom. Some of these end up increasing risk in the project.
For example, the failure of team members to collaborate effectively can derail a project. But if the business does not value collaboration and communication, can you really blame your team members for not prioritizing them either?
This is why you have to see project risk management as more than an isolated, project-specific exercise.
Instead, you have to paint a wider target. Look beyond the team and consider the cultural issues that contribute to project risks. Ask: Are there any values that help or hurt the project?
You'll need buy-in from executives if you're going to pull it off. Get them involved in the risk management process. Show them how the organization's culture increases the chances of projects failing.
Solving cultural issues can be an enormous challenge. But it can result in a long-term impact on your agency's ability to mitigate project risks.
10. Follow a proven risk management process
The last piece of advice I can give you is to follow a proven risk management process.This process is different for different organizations. You might have your own preferences as well.
But in case you don't, this 9-point plan is proven to work:
- Define: Define the project and get a clear, shared understanding of its goals. Your job in this phase is to consolidate information about the project.
- Focus: Get a clear, shared understanding of the risk management process. Scope the project and identify who the risk management plan is for.
- Identify: Make a list of all possible risks and threats to the project - implicit as well as explicit.
- Structure: Organize the risks and create a structure for classifying and processing them. This will help you create responses to entire risk categories, and not just individual risk events.
- Ownership: Clarify who owns each risk and what are their responsibilities in managing it.
- Estimate: Map out the probability of each risk and its impact on the project. You'll use this information to prioritize risks.
- Evaluate: Map out responses to risks and risk categories. Evaluate the success rate of each response based on past experience and industry best practices.
- Plan: Create a cohesive plan with estimates, responses, and ownership details for each risk. Also include KPIs you'll use to measure the effectiveness of the risk mitigation plan.
- Manage: Monitor the project for risks and take action based on the risk mitigation plan.
If you want to know more about improving project risk management, check out our approach to creative project management below:
What project risk management tactics do you use in your projects? Share your favorite tactics with us in the comments below!
