Project Risk Audits: What you need to know

Are you looking for a way to better manage the risks associated with your projects? Risk audits are an effective tool that can help project managers and program managers identify potential issues before they become problems.

And it’s not just me saying that. Frequent use of risk management best practice is one of the top drivers of project success, according to PMI.

By taking the time to audit risk, you can reduce uncertainty in your projects while improving visibility into what could go wrong along the way. In this article, you’ll learn when to use a risk audit, who should do it and why, how it is different from a risk review, and lots more.

What is a risk audit in project management?

Risk audits mean different things in different industries, so let’s only focus on the project management sense of the term.

A risk audit is a process used to determine whether the actions to manage the risk are actually happening and if they are happening effectively.

A risk audit can look at:

  • Project-specific risk policies and guidelines
  • The risk management plan
  • The risk management and mitigation strategies chosen for each identified risk
  • Whether the right risk owners were chosen and how effective they were
  • Effectiveness of risk response plans and whether the right actions were done.

In other words, the audit is a way to check that project risk management is happening (or has happened) in the right way.

Who carries out the risk audit?

The project manager, another project manager, a PMO person, or a risk audit person could carry out the audit.

Audits are part of internal controls on a project and fall under the governance arena, so if you have specific PMO team members who look at governance, they are the ones to ask.

The results can be fed back to the project manager, program manager, or senior management, as it’s likely the output is going to be useful to more than just this project team.

By the way, while you probably have an Audit Committee in the organization, they probably won’t be hugely interested in your risk analysis. Unless there’s anything that has an implication for enterprise-wide risk management or the operational risk framework, the auditors are unlikely to be bashing down the door to see your documentation.

Benefits of a risk audit: Is it worth scheduling one?

Audit? Who has time for that? It’s just another retrospective box-ticking exercise, right?

Wrong! It really is worth spending time reviewing the effectiveness of risk management practices in use. If you already have a process in place for peer reviews or PMO project audits, then reviewing risk is easy to add in to that.

The benefits are:

  • They provide a comprehensive assessment of the risks associated with a project
  • They help identify potential areas for improvement on this project (if it hasn’t finished) and future projects
  • They promote good project management practice – no more risk logs filed away and never looked at again.

By conducting an objective risk audit, organizations can better manage their projects, increase efficiency and cost savings, and enhance decision-making processes.

Risk audits provide valuable information that can be used to inform decisions related to resource allocation and budgeting for future projects. Should we spend more time on risk management? Did we have the right risk owners? Did people know what to do when they were allocated actions to mitigate risk, and if not, why?

With this data, project leaders have greater visibility into where investments of effort (and money) should be made in order to achieve the desired results.

Risk management audits can provide invaluable insight into the project process and help organizations make informed decisions that maximize efficiency, deliver cost savings through better resource utilization, and improve the chances of overall project success. That’s good, right? We all want those benefits on our projects.

How is a risk audit different from a risk review?

OK, the big question: risk audit vs risk review. Which one do I do?

You do both.

The risk review is the process of identifying, recording, talking about, updating the log, and working on the risk. It’s the daily stuff; the weekly conversations, and project reporting.

The audit, as we saw above, is a more thoughtful, lessons learned-style conversation on whether you were doing the right things, identifying potential risks in a timely way, choosing the right actions, carrying them out effectively with the right people, and therefore doing risk management in the best possible way.

The table below summarizes the differences.

Risk AuditRisk Review
Broad scope covering all aspects of risk managementScope is focused on risk management execution
One-off exerciseRegular project management activity
Best carried out by someone external to the project teamBest carried out by the project team
Happens retrospectively; reviews past performanceHappens in the moment as new risks are identified
Provides assurance on the processProvides assurance that delivery risks are being handled
Looks at the process overallLooks at individual risks

When do you do a risk audit?

You can do a risk audit whenever, but it’s best to think about how you’ll get the most out of the output. I would do one when I’m at least halfway through the project, so there is enough data to review, and I can do something useful with the output.

You don’t have to do what I would do, though. There are 3 moments in a project where you can carry out any kind of project audit, including one that focuses on the risk management process.

1. Pre-Project Audit

This type of audit is conducted prior to the start of a project. Use it to review other projects and pick up lessons from their experience to build into your planning.

This is a kind of pre-mortem: think about what could go wrong with the project and build in some resilience, so it doesn’t happen. The exercise helps with risk mitigation and identification because you can pick up a lot of what to do from what other projects did (or did badly!).

2. Interim Project Audit

This is the most common, in my experience. An interim project audit is conducted during the course of a project in order to assess progress against objectives and identify any areas that need improvement or adjustment. You might do one, or you might have them planned in at regular intervals on a long project.

Use the experience to learn about how you can tweak delivery and ways of working to get better results from the rest of the project.

If your project is very short, you might not have time to do this, and you’d move straight on to the next one…

3. Post-Project Audit

A post-project audit is a more formal experience than a lessons-learned session. Typically, lessons learned also focus on the ‘what’ of the project, whereas audits focus on the ‘how’ – did we do things in the right way? Did we follow the processes? How effective were we at doing project management?

These lessons can be filed away for use in future projects.

The frequency of risk audits will be something you can put in your plan. Then you’ll know when they are scheduled for and can prepare.

Key takeaways

Risk audits are a valuable tool for project and program managers to ensure their projects are running smoothly. Risk audits provide an in-depth look at how project risk management is being done on a project, and that provides insights into what could be done better.

Audits are different from regular risk reviews as they look at the effectiveness of the process.

Your next steps:

  • Talk to the PMO about what provision they make. Could someone audit your risks for you?
  • Schedule time for a risk review. Incorporate it into a retrospective or a broader project audit to minimize the impact on your workload.
  • Talk to the project stakeholders about the purpose of managing risk and do a brief sanity check to ensure you are managing risk effectively – you can do this without the overhead of a full risk audit.

Finally, if you have the time, pick one of your past projects to go back to. Pull up the risk log and look at how effectively you managed the risk during the lifecycle. What would you do differently? Where are the glaring holes in what you did? And with the benefit of hindsight and distance, can you work out why those things happened?

You might be surprised at what you learn!

Pin for later reading

project risk audits

Similar Posts