Project Management

The Money Files

A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from

About this Blog


Recent Posts

Trends and Emerging Practices in Project Risk Management (Part A)

Why are your governance processes failing? [Infographic]

What tool do I use for tracking a project budget? [Video]

5 Considerations for Project Testing

5 Behaviours of Successful Project Managers

Trends and Emerging Practices in Project Risk Management (Part A)

Categories: risk

project risk management trends

This article is part two of my look into project risk management, and today we are diving into trends and emerging practices, as determined by the PMBOK® Guide – Sixth Edition.

Read part 1 here: An introduction to risk management

There are three risk-related trends that bear investigation and we’re looking at the first one today.

Non-event risk

The first risk-related trend it’s worth considering is non-event risk.

Most risks that I’ve ever put on a project risk log relate to something happening or not happening. In other words, they are tied to an event. There is a thing that is going to happen that becomes the risk trigger. When the event happens, we acknowledge the risk has materialised and swing into issue management.

But not all risk relates to things happening.

Honestly, this is a bit of revelation for me. I’ve never spent much time thinking about the kinds of things that present risk to the project but that are not event-driven. I’m in the ‘average’ category of risk management, and it’s not one of the areas I would call myself an expert in (can we ever call ourselves experts in anything to do with project management? There’s too much going on and too many variables… I digress…).

The PMBOK® Guide – Sixth Edition talks about two particular types of non-event risk.

Variability risk

This is where uncertainty exists about something to do with what’s going on during the project. It is about recognising that the output of an event, activity or decision might not be exactly what we think. For example, the output of an activity might be above or below the target productivity measure.

I’ve kind of covered this on my risk log in the past by talking about people not having enough time to do their work or that testing takes longer because we find more bugs than I have allowed for in the project schedule – these could be understood as a variability risks.

I also once DIDN’t put a risk on the risk log about weather conditions, which would have disrupted our ability to get equipment to where it needed to go… and lo and behold, that project was hit by a snowstorm and we couldn’t deliver the kit.

We can manage these risks by using Monte Carlo analysis. Reflect the range of variation in probability distributions. They might not be perfect, but it will give you a better idea than guessing, and let you create an action plan to reduce the variability. The more you can reduce the variability, the more easily you can predict (and therefore manage) the output.

Ambiguity risk

Ambiguity risk is about not being able to predict the future: we should all be able to put that on the risk log. This type of risk calls out the fact that we don’t know for certain what might be required for the project, for example in terms of technical solution – until such time as the solution is fully costed, architected and known.

Another example would be future developments in the world of regulation or compliance, which may change the direction of the project or the solution. I once managed a compliance project (GDPR – remember that?) and at the same time other regulation was being introduced that would have an impact on the work we were doing. The lack of information about what was coming made us wonder how much we would have to rework what we were doing. Despite the ambiguity, in that situation, we ploughed ahead, knowing we would have to incorporate subsequent changes when they were known. That actually was on the risk register, if I remember correctly.

For me, the point of including these two types of risk is to make it clear to stakeholders that we aren’t magical beings as project managers. Stuff goes wrong. We do our best. We are thinking about these things but we often need to clearly articulate that we don’t know what we don’t know.

Manage these types of risk by doing exactly that: define what isn’t clear (if that isn’t a contradiction in terms) and then work out how to make it clear. That could be through using third party experts, or through reducing ambiguity by prototyping, user workshops, incremental development, simulation and AI and so on.

Next time we’ll look at the other two emerging practices in project risk management. Watch this space…

Pin for later reading:

Posted on: June 30, 2020 12:00 AM | Permalink | Comments (3)

How to stay afloat in times of organisational change [Video]

Categories: change management, risk

coping with organisational change

In this video I look at 3 things you can do to help calm the overwhelm when the business seems to be changing around you more quickly than you can keep up!

I talk about making sure change management, risk management and day to day operations on projects go as smoothly as possible, freeing you up to cope with whatever project-related changes are being thrown your way.

Pin for later reading:

organisational change

Posted on: June 14, 2020 06:51 AM | Permalink | Comments (6)

Project Risk Management: An Introduction

Categories: risk

project risk management

What I like about the PMBOK® Guide – Sixth Edition is that the language allows for scope to adapt the information to your own environment. For example, the definition of the project risk management Knowledge Area starts like this:

Project Risk Management includes…

which opens itself up to the interpretation that there could be other factors included as well as the ones listed.

In this article, and over subsequent articles, we’re going to look at the Project Risk Management Knowledge Area. Why? This blog is normally about things to do with project financial management, and what’s more relevant than managing risk so you don’t get a massive budget impact? OK, I’m sure you can think of other relevant things, but risk management is definitely a factor in controlling your budget.

Doing risk management on your project involves:

  • Risk management planning
  • Identification of risk
  • Risk analysis
  • Response planning and implementation
  • And monitoring risk.

The reason why we do it isn’t just to save the company’s purse. It’s to increase or decrease the likelihood and impact of risks (depending on whether they are opportunities or threats) in order to optimise the chance that the project will be successful.

Note: when I first started learning project management, on my first training course, risk was considered as a purely negative event. It’s thanks to thought leaders in the field and the development of the profession that risk is now more widely known to represent both the good things that could happen as well as the bad things. In other words, risk is a reflection of uncertainty, not doom.

Risk is not inherently bad – even the negative risk. We take risks in daily life, every time we cross the road, or take a flight. But we calculate the risk (subconsciously) and do it anyway if our brain tells us that the odds are worth taking.

Business and project risk are no different. The goal of project risk management is to identify the things that might happen on a project and weigh up whether it’s worth doing anything about them. Oftentimes, it is worth expending energy to do something about them because ignored risks can turn into issues and be suddenly a lot harder to deal with.

Levels of risk

There are two levels of risk on a project.

First, we have the individual project risk. Take a risk, assess it, and note the impact it will have on the project. That’s at a very granular level, and while we do a lot of that, and it’s a useful exercise, we also need to look at the bigger picture. That’s the next type of risk.

Second, we have overall project risk. Let’s say your project risks are all assessed as low impact and low likelihood. Individually, each risk isn’t very risky. But now let’s say you have 5,000 risks. That’s a lot of ‘not very risky risks’ and aggregated, the picture looks very different. When you consider how those risks might interact with each other, the picture gets even worse. If one risk happens, it could make others more likely, or more impactful. Overall project risk looks at the whole picture of the cumulative, aggregated position that is created by all the risks.

When you look at the risk profiles of several projects, you can see different trends emerging again. At a portfolio level, you aggregate the risk profiles of all the projects and programmes.

Ultimately, you want risk at any level to be in line with stakeholders’ risk appetite. When a project gets too risky, stakeholders will be nervous. The exposure to the business feels too great. The portfolio management team, in conjunction with the corporate risk team, will take that kind of decision.

At a project level, your role is to escalate up to the PMO, your programme manager or even your boss and let them know about the significant risks facing your project.

That’s the reason we have risk management processes. It makes all this easier. When you have a risk framework and structure within the organisation, you can more easily pass information to the places it needs to go and keep your risks in check.

Next time: I’ll be looking at trends and emerging practices in risk management for projects.

Pin for later reading:

Posted on: June 01, 2020 01:39 PM | Permalink | Comments (6)

Standardising the Language of Risk [Video]

Categories: risk

Standardising the language of risk

How do you talk about risk? Do you talk about negative and positive risk, or threats and opportunities?

And do your colleagues use the same terminology? As a project manager, we need to be able to have conversations about risk – and make sure that the people we are talking to understand what we are talking about! That can be hard to do if you don’t have a standard risk language – terminology that everyone in the business understands.

In this video I talk about the benefits of standardising the way you and your team talk about risk because. With standard vocab you can gain better buy in for your risk management actions because people get what you want to do.

It also allows for comparability between risks between projects, programmes, portfolio and the enterprise level. By all using the same definition of ‘major’ to describe a risk assessment, for example, you ensure that everyone understands the same thing.

This video talks about how to have a conversation about standardisation, and what you can do as a project manager even if you think you aren’t in a position to influence corporate standards on risk.

Pin for later reading:

Posted on: January 06, 2020 08:59 AM | Permalink | Comments (10)

Benefits of Risk Management [Video]

Categories: risk

risk managementWe all know we have to do risk management on projects. And beyond that, our businesses should have enterprise risk management in place, because… well… it’s the right thing to do.

However, if you’ve ever had to convince a project sponsor that it’s worth spending time on risk in a project board meeting, then you’ll know that sometimes not everyone feels the same way about risk management.

When you need to have conversations with your stakeholders and teams – and perhaps even the leadership in your organisation – about why risk management is a worthwhile endeavour, then this video will help.

I talk about the benefits of managing risk at an enterprise and project level. Specifically, we do risk management:

  • Because it meets mandatory requirements
  • For assurance
  • For effective decision making
  • For process efficiency.

Watch the video below and then let me know – what are the benefits of risk management that are the most important to you?


Pin for later reading:

Posted on: December 10, 2019 08:59 AM | Permalink | Comments (4)

Solutions are not the answer.

- Richard M. Nixon