How to Conduct a Risk Assessment for Your Project

June 6, 2018 by Andy SilberAndy Silber



One of the biggest challenges of project management is dealing with risks and opportunities. How do I build a work breakdown structure if I don’t know what’s going to be a problem down the road?

How do I build my team if the challenges are unknown? How do I effectively leverage good news? The difference between success and failure can come down to proper management of your risks and opportunities.

First, it’s important to understand the difference between an issue and a risk. A risk is something that might happen, while an issue is something that has happened. For example, climate change is an issue; an extinction-level asteroid strike in the next 100 years is a risk.

The first step to managing risks is to identify them early and take actions that reduce them, known as mitigations. A key tool to help you manage risk is a Failure Mode Effects Analysis (FMEA). You use this to find and prioritize your risks.

There are four stages to building your FMEA:

Gather a group of people, some who understand the project well, but also a couple pairs of fresh eyes. All the disciplines that are involved in the project should be represented, possibly including engineering, manufacturing, sales, support, and marketing.

Once you’ve gathered the group, it’s time for some brainstorming. Just ask, “How could something go wrong (or right) that is a deviation from our plan?”

Related: How to Use LiquidPlanner Data to Find Project Risks

I like to break the problem into categories, like mechanical and electrical, to help make sure every area of the project is touched upon. No risk is too small, and everything is added to the list without filtering. There’s just enough discussion that the team agrees what the risk is and the text is unambiguous.

Let everything sit for a few days. It’s not unusual for someone to email you with more ideas after the meeting. That’s great, it’s a sign that the team is taking the exercise seriously. Just add everything to the list.

As an example, if you’re building an electrically powered device with a pressure vessel, your risks might include:

Table 1: List of risks from brainstorming session

After a few days, convene the group again. Add any ideas for risks that have occurred to people since the last meeting, but don’t restart the brainstorming.

Then it’s time to get to the hard part, quantifying the risks for severity and probability. First, set the ground rules. Each risk should be rated on a 1 to 5 scale for severity and probability. Some teams like a 1 to 3 or 1 to 10 scale, but I find 1 to 5 provides the right amount of precision.

The exact definitions can vary, so it’s important to define them for the project you’re scoring. You should have something like this:

Table 2: Severity will be different if the worst case is triggering a Richter 7 Earthquake or having to reboot your computer. Severity 5 is the worst thing that can happen and scale down from there.

Table 3: The probability should be scaled based on the number of units you expect to deploy. A probability of 1 should be rare, but not never, while a probability of 5 should be often, but not all the time. The above example would be appropriate for a device that sells about 100,000 per year.

Some teams include Discoverability (i.e. the difficulty of determining if the risk has happened). I find that adds more complexity, but not a lot of value. It also lowers the relative RPN of risks that are easy to discover, which might lower the priority of a critical risk.

You now go through each risk and rate how likely you think it is to happen and the severity (positive or negative) if it does.

Related: Reducing Risk and Uncertainty in Your Project

Everyone needs to understand that these are Scientific Wild-Ass Guesses (not to be confused with a Stupid Wild-Ass Guess): Don’t spend a lot of time arguing whether it should be a 3 or a 4. Just put down a consensus number and keep moving forward.

When in doubt, go with the higher number. You also need to calculate the Risk Priority Number (RPN), which is the Severity x Probability, for each risk. When you’re done you should sort the risks by RPN.

Do not discuss how to solve the problems at this meeting.

Table 4: The list of risks after you’ve rated the Severity and Probability of each one. The RPN is a measure of how important each risk is.

After a few more days of letting things settle, bring the group together again. Your rules should state a thre...

(RSS generated with FetchRss)

Previous Article
3 Steps to Bringing Order and Teamwork to Your Next Project
3 Steps to Bringing Order and Teamwork to Your Next Project

Any project manager worth their salary will tell you that order and teamwork don’t just happen on a project...

Next Article
5 Ways LiquidPlanner Helps Manage Resources
5 Ways LiquidPlanner Helps Manage Resources

Effective resource management is essential to the success of any project. As a busy project manager, you ha...