Project risk assessment is an essential part of any project management plan. This guide shares 6 key steps in assessing project risk.

Running a project can sometimes feel like the plot of a Final Destination movie. No matter how much you prepare for it, disaster is always right around the corner.

Anything can – and often does – go wrong during a project. Stakeholders disappear on extended vacations, key employees leave, and unforeseen economic conditions cut your budget in half.

So much of project success depends on spotting and eliminating these risks.

How exactly do you figure out which risks to look out for and which to ignore? And once you’ve spotted these risks, how do you create plans to counter them?

I’ll answer all these questions and more in this guide to project risk assessment.

Risk in Project Management

As we’ve noted earlier, risk management is one of the pillars of project management. Without a suitable risk management plan in place, you can’t say that your project planning is complete.

Because it is enshrined so deeply in the project management doctrine, it is also easy to trivialize risk management. Far too many PMs see it as a purely academic exercise, tacking it onto a project plan without understanding what it entails.

So let’s go back to the basics and ask: What is risk in project management?

Every decision you take during a project invariably creates a potential risk event.

Think of something as simple as file storage. If you decide you store your files locally, you create a risk event: what if your local storage fails?

To counter this, you might create a backup in the cloud. But this is inherently risky: what if the cloud storage company goes under?

So as an additional safeguard, you might opt for a second long-term storage with a more reliable partner like AWS.

Thus, your single decision – store files locally – creates multiple risk events you have to respond to.

This applies to virtually every decision in a project. If a stakeholder goes AWOL on email, you need to get a hold of them on Skype. And if they go missing on Skype, you need their phone number.

And so on.

Whether you create a contingency plan for each and every risk associated with a decision will depend on two things:

  • The likelihood of the risk event occurring
  • The impact the risk event would have on the project

This is the essence of project risk assessment: evaluating and prioritizing risks.

I’ll dig into this deeper in the next section.

6 Key Steps in Project Risk Assessment

The formal process of project risk assessment can vary from organization to organization. However, regardless of which methodology you follow, there are a few steps common to all of them:

1. Learn to differentiate between controllable and uncontrollable risks

A meteor crashes into Earth and destroys the datacenter where you store all your files.

Can you really avoid this risk?

Of course not.

Every project has some risk that is controllable and some that is not. You can prepare for the former, but with the latter, your risk mitigation plan will mostly be a hope and a prayer.

A contractor that goes bankrupt? You can line up a second contractor as a backup. But a sudden political crisis in an offshore partner’s home country? You can’t really prepare for that.

To differentiate between controllable and uncontrollable risks, ask yourself:

How much control do I have over this risk event? Would a change in my decision change the probability of the risk event occurring?

For instance, if you change an unreliable contractor upfront, you can avoid a risk event entirely. But you have no real control over the internal political stability of an offshore partner’s home market.

Uncontrollable risk events are usually related to political, social, economic, and environmental factors. One way of analyzing them is by using the PESTLE framework:

(Image source)

Using this framework, you might find that some of your partners are inherently riskier because of their local market conditions. You can reduce your risk exposure somewhat by shifting to partners in more stable conditions.

For instance, if you have a data warehouse in an area known for natural disasters, you can reduce risk by moving to a more environmentally safer warehouse location.

This form of risk reduction is largely passive. You can’t control it, nor can you influence the likelihood of the risk event occurring.

Which brings us to the next point…

2. Understand active and passive risk control methods

Jumping off the controllable/uncontrollable risk classification, you can say that your risk control measures can be divided into two broad categories:

  • Active risk control where you have direct influence on the risk event and can take active measures to control it
  • Passive risk control where your risk control options are limited to making safer choices to avoid the risk altogether

Lining up a backup contractor to take over in case the primary contractor drops out is active risk control.

Avoiding a contractor located in a politically unstable country is passive risk control.

Effective risk assessment means adopting both active and passive risk control strategies. You want to have backups and alternatives in place to actively control risk events. But at the same time, you also want to passively avoid risk altogether by choosing safer options.

For every risk that you identify, ask yourself:

  • Are there alternatives to this service/product I can call on in case of a failure?
  • Would the likelihood of the risk event go down if I choose a different product/service?
  • What best practices can I adopt to reduce the chances of the risk event occurring?

You’ll find that you have to maintain a delicate balance between active and passive risk control measures. Choosing safer options might reduce risk, but it can also increase your costs – such as choosing a US-based partner instead of offshoring.

Evaluate your own risk appetite (and that of your stakeholders) to find this balance.

3. Calculate the risk score

When you first start any project risk assessment exercise, it can be overwhelming to go through all the risk events that come up.

You can’t possibly create a contingency plan for all of them (not unless you have infinite resources). So how do you decide which to act on and which to ignore?

Easy: by calculating the risk score for each risk event.

This is nothing but:

Risk Probability * Risk Impact

Here:

  • Risk Probability is the chance of the risk event occurring expressed as a number (higher numbers = higher probability). You can also express it as a percentage.
  • Risk Impact is the expected impact of the risk event on project success. This impact is based on the priority of the deliverable affected. A risk event that affects a key deliverable will have a higher Risk Impact than a non-essential deliverable.

The higher the risk event score, the more importance it should get in your risk mitigation plan.

For instance, you might have a table like this:

In this case, Risk Event A gets top priority because it has the highest event score.

Of course, this isn’t an exact science. You can’t objectively assign a hard number to the importance and probability of a risk event occurring. Your scores are also liable to be influenced by the people you’re consulting. A programmer is likely to over-emphasize technical risks while underplaying operational risks.

Which brings us to the next point…

4. Create a project risk assessment committee

Risk management duties might fall into the project manager’s cradle, but they shouldn’t be only your responsibility.

Rather, you need to get people from diverse backgrounds involved to truly figure out which risks are important, which aren’t.

This project risk assessment committee should include:

  • Project manager: As the person responsible for the project plan, it is only natural that you get involved. You’ll also be responsible for all the operational aspects of this committee.
  • Subject matter experts: These are people inside or outside the agency who can identify risks and evaluate their probability and impact. For instance, you might have your lead developer look over the technical deliverables, while the lead designer might consider the design/UX aspects.
  • Key stakeholders: Get both internal and external stakeholders involved to understand what they prioritize in the project.

Getting stakeholders involved is particularly important. Stakeholder priorities don’t always align with the stated project priorities. Yet, you want to keep them happy while ensuring a successful project.

By getting them onboard, you get a fair idea of what risk events you can prioritize to keep them happy without jeopardizing the broader aims of the project.

5. Accommodate contingencies in your risk mitigation approach

Your risk mitigation approach itself is not without risk. This might sound ironic, but if you want your project to be truly risk-proof (not that any project can be without risk), you need a risk mitigation plan for your risk mitigation plan.

Have an outside contractor lined up in case a key employee leaves the company? Great. But what if the contractor is located in a politically unstable country? You’ll want to line up a second contractor to take over if things go south.

Essentially, you want at least two levels of risk mitigation, at least for all mission-critical deliverables. You want a backup and an alternative to that backup.

When you’re creating your risk mitigation plan, ask yourself:

  • What are the active and passive risks associated with this risk mitigation tactic?
  • Are there safer alternatives that I can switch to? If yes, what are the costs associated with the switch (both in terms of money and time)?

Thus, you might have a spreadsheet like this:

In this example, multiple risk mitigation tactics ensure that your mission-critical deliverables remain safe, no matter what.

Of course, this is overkill for most deliverables. But for the most important parts of the project, it is worth it to secure them at multiple levels.

6. Keep a compendium of all risk

Aka a “risk register”.

Every mature organization should create this register to make future project risk assessment easier. Think of it as an internal Wiki that documents all the risks you or other PMs have ever encountered on any project.

Ideally, these risks should be classified by project type, size, and client.

This way, any time you get a new project, you can refer to the risk register to see what risks usually come up.

For instance, if 90% of your app development projects under $100k have data storage issues, it might be a good idea to invest in storage alternatives for future projects.

Documenting all risks can also tell you what your organization excels at and what it struggles with. If a certain risk type routinely crops up across projects, it probably means you need to bolster your expertise in that area.

Over to You

Project risk assessment can be hard, especially when you’re starting out. You have too little historical data to lean on and have to rely on subject matter experts to assess project risk.

But if you follow the tips I’ve shared above, you’ll find that project risk assessment isn’t just easy, but also enjoyable.

One way to reduce risk in any project is to use better software, like Workamajig. Workamajig’s robust, cloud-based agency management tools can help you secure your data while bringing greater transparency to your workflow.

The result? Safer projects and more productive project manager.