Project Risk Management: How-to guide (with tips)

Risk management is a staple skill of project managers. As the project environments we work in get more and more complex, with greater levels of uncertainty and more transformative, disruptive projects, being able to deal with risk remains top of the list of desirable skills for managers in all areas of business.

However, project risk management is something that many project managers find tricky. The theory is easy – implementing risk management successfully so that it is actually useful on the project is a little bit harder.

In this article we’ll look at tips for risk management, the role of the risk log, how risks relate to issues and share some project risk examples.

What is project risk management?

Before we dive in, let’s make sure we are all talking about the same thing.

The Praxis Framework defines project risk management like this:

Risk management allows individual risk events and overall risk to be understood and managed proactively, optimizing success by minimizing threats and maximizing opportunities. Its goals are to:

• ensure that levels of overall risk within a project, program or portfolio are compatible with organizational objectives;
• ensure that individual risks and responses are identified;
• minimize the impact of threats to objectives;
• optimize opportunities within the scope of work.

Optimizing risk responses is one of the 12 Project Management Principles in the PMI/ANSI Standard for Project Management which is now bundled with the PMBOK® Guide.

I like the definition of risk management from the Sixth Edition, which defines it succinctly:

Project risk management includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation and monitoring risk on a project.

The challenges of project risk management

So if we know what project risk management is, why aren’t we doing a very good job of it?

Project managers don’t do risk management effectively because:

• It’s too complicated
• It’s too academic
• It’s time consuming
• Nobody cares
• It feels like a scientific process that is too difficult to take part in
• They don’t want to sound negative by talking about things that could go wrong
• They are intimidated by it.

What we need to manage project risk effectively is:

• Legitimate data
• Historical data
• Proper transparency
• A culture of honesty
• An understanding of risk sensitivity
• An appreciation of the value of risk management.

Airline, hotel and insurance industries take a scientific approach to risk management because they’ve got the data to support that.

In projects, more often than not we don’t have the data, or if it exists it isn’t accessible easily enough to be used for risk management activities.

Create a risk and issue management plan

The way you are going to log, track and manage risks and issues is documented in your risk and issue management plan.

Often, this is part of the project management plan, because you’ll normally have a standard way your company expects you to deal with project risk, so you can simply reference that.

There’s no need to create a massive document when you can point to your corporate standard or even say you’ll log the risk in the project management software and discuss it at the monthly risk meeting.

A risk management plan helps you plan for when things go wrong on the project, and they will.

Mark Engelhardt, at a the Art of Projects Conference in Hungary one year (I forget when we were there), said:

“You don’t have a choice about whether you’re going to look stupid on a project. You can only decide when you are going to look stupid.”

Your choices are at the beginning, when you ask lots of stupid questions, or at the end, when your project is struggling and someone asks why you didn’t see the problems coming.

A problem is something that is not documented: it becomes a risk or issue once it is written down and is being actively managed. Talking about risk puts you in a better position to do something about them especially, as Mark pointed out, “most of our executives are too far remote from the rest of the team.”

Mark said that around 40% of the things we identify as risks actually fade away without project managers having to take any action at all.

Another large chunk of the content on your risk register is a by-product of the ‘way we do things around here’ and you won’t be able to take any action because you are up against corporate culture.

Only 3% of risks, he estimated, turn into something explosive.

What is a risk and issue log?

A risk and issue log is a simple way to record, track and monitor project risks and issues.

Personally, I log risks and issues separately because they are different things, but you can manage them together on the same spreadsheet or in your project management software, if that works for you.

What is a risk log for?

A project risk log is a way to record all the things that might affect your project. For example, you might not get the equipment delivered on time, as the supplier has hinted that your timescales are too tight. This goes in the risk log.

The risk log is a way of capturing the kinds of things that could affect your ability to complete the work on time, on budget and to the required specification.

Then you can look back on the risks on a regular basis – say, once a month – and check that you are doing something about them. That way you can head the problems off before they become bigger issues for you and your team to deal with. It’s a way of managing your work so you don’t need to use Plan B.

At its simplest level, project risk management is a straightforward process. You don’t need Monte Carlo simulations or decision trees. You only need, Mark said, a spreadsheet with some columns covering:

• An identifier
• An explanation of the risk
• The impact of the risk
• The actions you are going to take
• The name of the person owning the risk
• The date you expect the action plan to be completed by.

Those are the basics of a risk log, and you’ll use similar columns to track and manage project issues.

Why is risk management important?

Project risk management is important because a badly managed risk can create havoc on a project. It could even get to the point where the project isn’t worth pursuing any longer because the risk profile is strategically unaligned to what the company is prepared to accept.

In the end, great risk management tries to reduce the likelihood of negative risk adversely affecting project performance to minimize the impact on project outputs.

Going beyond the basic identification and logging of risks is a way to link risk management to project performance and ensure that you are giving your projects the best possible chance of success.

7 easy tips for improving risk management

I know you want those risk management tips, so let’s get to those now! Here are 7 ways to level up your risk management to get closer to reducing the impact of risk on your projects.

1. Clarify roles and responsibilities

The risk with any process is that over time people come to take it for granted and forget – or choose not – to do all the steps involved. If there isn’t any governance around that then no one will ever know that there are shortcuts being taken.

Clarify the roles and responsibilities of the people involved in project risk management. This also gives you the opportunity to remind them of priorities and what the organizations risk appetite is, so they can better align their decisions and actions to business strategy.

2. Share risk appetite

Everyone has different levels of personal risk appetite. I am not naturally cautious on projects (but highly cautious outside of projects!). Other project managers have different approaches. And who is to say what’s right?

This is where it helps everyone to have a better understanding of the organizations strategic approach to risk. Perhaps the company believes that outside of the core product set, anything goes. But for projects and tasks related to those core products, a risk-averse approach is best.

Whatever the corporate guidance, make sure everyone knows what it is. Then you can align your project activity and decisions behind that. If nothing else, it will force the people at the top to truly think about what risks they are prepared to take.

3. Clarify how risks are identified

Another common problem is that risks aren’t identified as they emerge because the risk identification process stops at project initiation or (worse) just after the ink dries on the business case. Make sure everyone knows that spotting risks early is a good thing. Talk to them about the process for doing that.

Build it into your regular project and program team meetings. Ask people what new risks they have seen recently and what they are doing about them.

Log everything and act on it as it happens. These emerging risks are the ones that are most likely to prevent you hitting the business targets set for the project, far more than the ones identified at inception.

4. Know your success factors

You might think that project success factors aren’t linked to risk, but let me beg to differ.

Success factors are how your project is going to be measured. They are the performance targets you strive to meet as a project team. They describe what operational success looks like and how you will know that the project is finished.

If you don’t hit those success factors, it’s highly likely that your stakeholders will consider your project a failure.

So how about linking risk to success criteria? Link each risk back to a critical project success factor. You’ll be able to quickly see the impact on the project if the risk materializes.

You’ll also be able to work out which success factors are most at risk and use that information for interesting conversations with your sponsor.

5. Budget for risk

I don’t meet many project managers who have a dedicated budget for risk. If you can pinpoint the effect of a risk on a project success factor you’ll be able to assess how bad it would be for the project if the risk happened.

With that information you can lobby for a risk budget to pay for your risk management activities. You might want to mitigate the risk somehow and you’ll need cash to pay for whatever that looks like.

Justifying why the money is required is far easier if you can point to performance indicators that are at risk (like inability to deliver the predicted profit) instead of just pitching it as a project problem.

6. Update your business case template

How much space does risk get in your business case template? When you start a project, this is exactly the kind of thing you should be thinking of.

Your execs need to know what happens if they approve the project. Does the risk profile of the company’s project portfolio suddenly go through the roof? Or is it broadly in line with the risk exposure that the company currently has?

What about risk analysis; is that all in there? In enough detail for someone to really understand what they are signing off?

Arguably, early risks and a management plan for them, plus risk analysis of the project work overall and a statement of how this aligns to the company’s strategic approach to risk are all things that should go into that business case.

The idea is to give your execs the best possible information to help with decision-making. Obviously, you’ll want them to say yes to your project, but they need to do that from a position of quality information and risk exposure is part of that.

Need a business case template? Get one here.

The same goes for your Project Charter. Once you’ve got past the business case stage you can update your Project Charter template to include adequate and detailed information about the risks the project is facing. This should go beyond a few bullet points of the initial identified risks.

7. Aggregate risks

If you work as a project manager, aggregate the risks from your workstream leaders. At program level, aggregate risks from all the projects. Above that, produce an aggregated view of portfolio-level risk.

Ultimately, you want to get to a point where the risks that are presented to the Board link tangibly back to what project team members are actually doing. That alignment will ensure a full picture that enables managers to spot trends.

It’s useful because often big issues that hit companies severely are the result of several smaller problems all cascading and running into each other in a perfect storm.

Draw in information from operational teams and corporate risk management activities that cover business-as-usual work too to get the full organizational picture.

Aggregating your risks might not let you avoid catastrophe totally but it may help you spot where things are going awry before it is too late to do anything about it. It will also help you unpick problems and see the root cause if and when something happens that you wish hadn’t.

Risk reporting tips

Recently one of the students taking my Better Project Status Reports course got in touch with some questions about risk and issue reporting. I thought it would be worth sharing my responses with everyone.

To give you some background, we were talking about a large project which would run over several years with 4 workstreams covering technical build, data migration, change management and testing. The student wanted some advice about how best to communicate risks and issues to senior management.

Are there guidelines about what risk information should be reported to senior management?

No, not that I am aware of. The PMI Risk Practice Standard doesn’t include anything. The PMBOK® Guide no longer talks about project performance reports and never included what to put in them to my knowledge. I think you’ll have to define the content of your reports yourself.

As a rule of thumb, I’d include the top three risks for the month along with what you are doing about them, plus any decisions you need the sponsor to make.

What should you include in a graphical risk management dashboard?

For a senior management report, I would only report the open risks per project and/or open risks per category (scope, budget, schedule etc). This would let you see if there is one area like schedule that has a big risk impact on all projects.

I wouldn’t include:

• Total number of risks overall
• Closed risks
• Risks with an impact status of Low or Medium

This is because the senior management team can’t do much, if anything, with this information. The number of risks alone is pretty meaningless. Some may be very small, some projects may only have a few but they could be significant. A better way would be to report risk impact – what is the cost of all the risks if they happened?

The best approach would be to ask the key stakeholders what they are interested in seeing.

I don’t think closed risks or number of risks is of any use as it doesn’t give them information they need to make decisions about the project. Risks by category, or risks with an impact rating of ‘High’ is more meaningful.

Should I show risk trends over the months?

No. What would the senior management team do with this information?

At the beginning of the project you’ll identify lots of risks and then close some and open new ones. If you have a risk review meeting one month and identify another 50 risks this will skew the trend data.

I would advise only showing a snapshot in time. You could use an arrow to indicate whether the overall risk profile of this project is going up or down, using a metric like whether there are more or less High risks or whether the cost implications for risk mitigation are going up or down.

What about reporting on issues?

Most of this article has been about risk management, but as risks and issues often fall into the same section of a project report, here’s some thoughts on issue reporting.

For senior management, only show the high priority open ones. Typically I report also on ‘high priority closed this month’, then those issues drop off the report for the next month. This shows that you are making progress in resolving issues, even if new ones come along.

If you don’t do this, your report could show that there are 20 open issues with a status of High Priority this month, and 20 next month. However, they could be 20 completely different issues! Without more detail, like issue names and descriptions (which, frankly, your sponsor is not going to want to wade through), your stakeholders will not know that you are dealing with issues and may assume that you are not tackling problems on the project.

As well as a graphical representation in a pie chart or dashboard, I would also include the top 10 issues in more detail – descriptions and action plans. If you need senior management input to resolve any issues make sure that these are included in the report and that you highlight where they need to make decisions.

Again, the best approach would be to ask your senior management team what they want to see. If they don’t know, present them with your graphs and report for a few months and then ask for feedback about what they think and what else they need to know in order to carry out their roles on the project i.e. decision making, governance and oversight.

Want more guidance on project reports? Get the ebook version of Better Project Status Reports as part of my productivity bundle here.

Can a risk become an issue?

Yes.

Once a potential problem becomes a real problem, your risk becomes an issue.

Issues can be risks that have happened. Or issues could be totally new problems that you didn’t see coming. Either way, you manage them the same.

Can issues become risks?

Not really. An issue is something that has happened. Risks haven’t happened yet. Something can’t un-happen, so an issue can’t become a risk.

However, an issue can spawn new risks. Something happens on the project and that might create new risks for you to log and manage. They’ll be related to the issue but they won’t be the issue.

Project risk examples

Here are some examples of project risks. You might have some of these on your project. Bear in mind they are fictitious, so you should be inspired by them, rather than copy them directly into your risk log.

• There’s a risk that the price of a core material may go up due to international pricing and that will have a negative effect on our project budget.
• There’s a risk that a core member of the team will be taken ill during the development phase and that will impact our ability to deliver as we will be short of resource.
• There’s a risk that the new corporate branding guidelines will be released before we finish the project which will mean we’ll have to rebrand the product, adding extra time to the project.
• There’s a risk that the solution we are building will not meet the information governance requirements.
• There’s a risk that the user group will not like the solution and we will need to consider the design again.
• There’s a risk that we won’t get planning permission for the new build.

Want more inspiration? Read this guide to common project risks.

Once you have identified project risks, you’ll need to decide what to do about them. Read this guide to selecting risk responses to help you work out the next steps.

Key takeaways

• Project risk management is a core skill for project managers.
• A risk is something that might have an effect on the project if it materializes.
• The project risk management process is about identifying, recording, tracking and acting on risks to get the best possible outcome for the project.
• Use a risk and issue log to record and manage your risks (and issues).
• Risks should be included in your project status reports.