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

How to Measure Schedule Performance [Infographic]

Interoperability: The key to efficient working

What do you do when you can’t track project cost? [Video]

Risk Identification: How to Do It

How to Make a Benefits Dependency Map [Infographic]

Risk Identification: How to Do It

Categories: risk

risk identification

This article is part seven of my look into project risk management, and today the topic is project risk identification.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

Read part 4 here: Tailoring Risk Management

Read part 5 here: Planning Risk Management

Read part 6 here: The Risk Management Plan

Identify Risks is the second process in the Risk Management Knowledge Area. It’s where we work out what risks might befell the project.

In the process we look for overall project risk and also individual project risks – things that might affect one particular area of the project.

Typically, risk identification is done at the beginning of the project to work out what existing risks there are facing the project. However, it should be an ongoing activity, and you’ll revisit it from time to time during the project. Especially as you start to spend the risk budget or work out the cost of risk management activities – I think risk identification and management tends to spawn new risks. Perhaps that’s just because you get better at spotting them once you get started!


There are loads of inputs to this process.

  • The project management plan
  • Project documents like the lessons learned log, duration estimates and requirements documentation
  • Agreements, for example for procurement of external resources, because there is likely to be some risk in entering into any deal outside of your company’s immediate control
  • Procurement documentation – check out what this has to say on seller performance reports, how changes will be managed, inspections and so on
  • Enterprise environmental factors like benchmarking studies, commercial risk databases if you have access to them
  • Organisational process assets like actual risks from past projects, checklists from past projects etc.

The project management plan has lots of areas that could give you useful information for the risk identification exercise including the requirements management plan because that might reference particular at risk deliverables.

The schedule management plan probably talks about areas of the schedule that aren’t yet fully known, and that is another area of risk.

The cost management plan may identify budget areas that haven’t been fully costed or understood, or areas of contingency that might warrant raising a risk to keep them on the radar. Cost estimates are a project document that might also be useful, because the cost may be expressed as a range and that implies a risk to the budget as you don’t know what the cost is going to be.

And so on.

Tools and Techniques

There are also quite a lot of tools and techniques, although most  of them will be familiar, I’m sure:

  • Expert judgement
  • Data gathering including brainstorming (as you would do in a risk identification workshop), checklists and interviews
  • Data analysis
  • Interpersonal and team skills especially facilitation for your risk workshops
  • Prompt lists (these are a list of categories against which to brainstorm – start with PESTLE if you don’t have any of your own)
  • Meetings.

The data analysis you might want to do could include root cause analysis to uncover the underlying reasons for a risk – because knowing those will help you develop a better action plan.

You could also do a SWOT analysis, or look back on previous SWOT analyses. We used to do these annually as part of the department’s strategic planning, and there were often useful overarching risks in there that would translate to a project.


The end result of this process is the risk register. The risk register will include the initial risk responses if you already know what it is you are going to do.

There’s also the beginnings of the risk report and the updates you do to various project documents like the assumptions log, issue log and the lessons learned register – if you find anything worth putting in those.

Who gets involved?

Pretty much anyone who is working on the project can get involved in risk identification. That includes you as the project manager, the sponsor, team members, the risk management team from your company if you have one, any other subject matter experts, customers and end users… basically anyone who has any interest or influence over the project or knows anything about the work you are doing.

Risk identification is everyone’s job. Set that expectation at the beginning of the project and you’ll be fine!

Next time I’ll look at qualitative risk analysis – in other words, what to do with those risks now you’ve identified them.

Pin for later reading:

risk identification pin

Posted on: September 26, 2020 12:41 PM | Permalink | Comments (2)

What goes into a project risk management plan?

Categories: risk

project risk management plan

This article is part six of my look into project risk management, and today the topic is the project risk management plan.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

Read part 4 here: Tailoring Risk Management

Read part 5 here: Planning Risk Management

So: risk management plans. What should you expect to see in one?

Here are some things you can include in your risk management plan. You don’t always need all of them – good project management is all about tailoring, so pick and choose what is appropriate and necessary for your project.

Risk strategy

This is a statement about the general approach you are taking to managing risk on the project. You can reference any organisational guidelines, the risk appetite of the company and the business context for risk management.


The methodology section is where you define the specific way you are going to manage risk on the project. That includes the approaches you will use, any software tools or other tools that are available to you and that you’ll use, and the places you’ll get data from to make decisions about risk actions and planning.

Include information about tracking risks: how will this be done? How will you record what has happened and how will adherence to the process be audited (if it will)?

Roles and responsibilities

I think it’s always useful to have this section in the risk management plan, even if you refer to the main roles and responsibilities document or a different place in the project management plan. I think it helps to know who is responsible for what, and for everyone to see that it is everyone’s responsibility to be on the look out for new risks.

Document who is going to lead risk management, any supporting roles, and who else is ‘hands on’ with the risk management process. Explain what their responsibilities are.

Risk budget

It’s also handy to record the project funding available for risk management (if you are lucky enough to have a dedicated risk budget). I think it’s worth calling out even if there is no dedicated risk budget, because it makes it clear to  senior execs and the project sponsor that managing risk takes money, and if there is none, there’s a limit on what you can usefully do to avoid or mitigate the risk.

In this section you’ll want to talk about how you can access the risk budget – because let’s be positive and assume there is one – and how the funding will be tracked and reported so you can see when it’s running out.

Timing and reporting

Write a short section that talks about how often you’ll do risk management reviews, when each part of the process takes place and how risk management is woven into your project schedule. I would include formal risk workshops in here, alongside a formal monthly risk review, while noting that risk management is an ongoing activity bound into everything else we do on the project.

You can also record how and when risk reporting is going to be done, and what is going to be included in the risk reports. I would mention what level of risk is going to be reported in each place. For example, in Steering Group meetings I would report every significant risk. In monthly project reporting, the template we used to use only had space for the top 3 risks.

Categorisation of risk

Finally, document how you are going to categorise risk on the project. You might already have organisational-wide definitions and categories, in which case you should use them. If you don’t, you can easily make up some categories. Things like Technical, Commercial, Reputational, Environmental etc are all common categories. Think about what the project is trying to achieve and what departments are involved, and that can be the basis for your categorisation. I would start with a simple list and allocate each risk to one category only.

If you want to get a bit more detailed and dive into risk management further, you can create a risk breakdown structure which is a useful way of grouping risks and seeing how they interact and relate to each other.

Risk appetite

Include a statement about how much risk the project (or organisation) is prepared to accept. You’ll get this either from ‘official’ company sources or from the project sponsor.

Remember that risks can aggregate together: lots of small, insignificant risks can make for one massive problem if they all happen at the same time.

Definitions and matrix

Include definitions of how you calculate probability and impact. It’s really important that everyone understands what these two concepts are and then what the different levels mean. Ideally, you should have this at PMO level if not organisational level, because then you can more easily comparer the risk profile of different projects.

Alongside your definitions, include the probability and impact matrix that helps you assess the risk score. Or link to where it can be found – there’s no need to reinvent the wheel or create lots of additional pages in your documentation, just reference the PMO documentation if there is any.

Pin for later reading:

project risk planning

Posted on: September 08, 2020 08:00 AM | Permalink | Comments (8)

Project Risk Management Planning

Categories: risk

project risk management planning

This article is part five of my look into project risk management, and today the topic is planning risk management, as determined by the PMBOK® Guide – Sixth Edition.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

Read part 4 here: Tailoring Risk Management

Plan Risk Management is the first process in the Project Risk Management Knowledge Area. It’s defined as:

The process of defining how to conduct risk management activities for a project.

If you are anything like me, you probably haven’t spent a lot of time thinking about how you are going to do risk management – you just do it. However, if you are new to project management, managing in a different way to how you have done before, or with a larger, more complex or strategic project, leading a project at a new organisation or similar, you will want to spend some time mapping out how the project will approach risk management.


The inputs to this process are:

  • The Project Charter
  • The project management plan, so your risk management approach can be consistent with other areas of the plan
  • Project documents including the stakeholder register which helps identify responsibilities for risk management and the risk appetite
  • Enterprise environmental factors such as organisational risk management thresholds
  • Organisational process assets like the organisational risk policy, risk vocab, authority levels for action planning, lessons learned, other risk management guidelines and documentation that you can reuse or need to align with.


There’s only one output to the process and that’s the risk management plan.

You can create a risk management plan that’s a few lines long and says you’ll follow the PMO approach for risk management, or you can create a full, detailed, bespoke risk management plan. Do what you need to do for your project.

I’m lucky in that I’ve always worked in organisation’s where we’ve either had a PMO for guidance or had experienced project managers. Not that being experienced is a shortcut for doing risk management well – you do still need to put some thought into it. I do think, though, that over time, some of the planning activities are done quickly because they are the same as the last 10 projects you’ve run and the act of planning has become so ingrained that you don’t think about the ‘how’ any more, you just focus on the ‘what’.

Anyway, part of being able to apply business acumen and critical thinking is that you make the right choices for your project, so don’t assume that because you’ve run a project before that you don’t need to do any risk management planning.

Tools and Techniques

The tools and techniques you’ll use to come up with your risk management plan are the things you would expect:

  • Expert judgment – because you’ll be talking to the risk management professionals in your organisation or using PMO best practices, and applying your own expert judgement to make the tailoring choices
  • Data analysis and stakeholder analysis – because the way you approach risk is constrained or governed by the stakeholders you have so you can better align to their risk appetite
  • Meetings – because you have to talk to people about how risk will be managed, especially if they are new to the project or the business and haven’t done active risk management before. And you might want a few risk workshops to help define your approach and get everyone on the same page.


The Plan Risk Management process is something you should do before the project begins working on tasks to complete deliverables. So get your risk management plan completed as quickly as you can before the project begins.

You can, of course, review and update the approach to risk management as the project evolves. Something might happen that means it’s worth reviewing the context for risk management and updating the plan. As with all aspects of the project, keep revisiting it to make sure what you are doing is fit for purpose and updating the associated documentation for the record.

Planning risk management shouldn’t take you too long. It’s about establishing the framework for doing risk management on the project and getting agreement about the activities required to manage risk effectively. If you’ve already got organisational policies that cover risk, or a project risk management process from your PMO, you’re halfway there.

Next time I’ll be looking at what goes into a risk management plan.

Pin for later reading:

project risk management planning pin

Posted on: August 11, 2020 08:00 AM | Permalink | Comments (7)

Tailoring Risk Management

Categories: risk

tailoring risk management

This article is part four of my look into project risk management, and today we are looking into tailoring considerations for project risk management, as determined by the PMBOK® Guide – Sixth Edition.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

You might think there isn’t much you can tailor in risk management: the processes we use haven’t changed much since risk management in projects was thought up, or at least that’s how it seems to me. While many project management topics have moved on in their thinking, risk management is still very similar to how it was taught to me many moons ago.

But you can tailor the risk management approach used on your project to better fit your organisation’s culture and practices.

Below are some of the ways you can tweak risk management to make it work effectively in your project environment.

Tailor for size

You can adapt the way you manage risk based on the size of the project. The larger the project – as with many PM practices – the more robust and structured your processes end up being. If your project is relatively small, a nimble and light process could be all that is required.

Maybe your PMO implements several ‘routes’ through the project risk management process, depending on triggers at the beginning of the risk analysis. For example, if the project is small, and the risk is assessed as low impact, the process could be very different from a large project with a high impact risk.

Size can be determined by amount of money allocated to the budget, duration, amount of stuff in scope, or the number of people or departments affected.

Tailor for complexity

Size is one thing, but you can have very large projects that are not complex. Small projects, on the other hand, can be very complex. Where you are dealing with very innovative projects, new tech, unusual commercial arrangements, many system interfaces or diverse and vast stakeholders with many external dependencies, all those things contribute to project complexity.

Complex projects may need to take a different approach to risk analysis, looking at different factors and considering impact in a more holistic, systems thinking kind of way. For example, you shouldn’t assume that a risk will have a simple impact on one team: the more complex the project, the more likely it is to work like a complex adaptive system, and you’ll have many (perhaps unforeseen) implications from one risk.

Tailor for significance

Not all projects are created equal. Strategically important projects tend to demand more oversight and governance. There might be a different bar for strategic, significant projects – in other words, less strategic projects can get away with applying less formal risk management. Whether you should or not is another debate, but you could apply different approaches for the less important projects.

Another consideration for strategic work is that the risk analysis probably needs to be broader and take different areas into consideration, not least impact on strategic objectives and overall business goals. The level of risk on this kind of project is also likely to be higher because the stakes are higher. Therefore you might want to take a different approach to reflect the increased project risk you are likely to face.

Tailor for delivery approach

Finally, consider how you tailor project risk management to better fit the delivery approach you are using. The risk management processes I alluded to earlier work well for predictive and waterfall type methods – at least, that’s what I was taught. But the risk process is rarely sequential, even on a sequential project. Some risks are starting while others have been realised or have passed. Others need a lot of work and some need a small check in that takes minutes once a month. Each risk has its own lifecycle and risk management is an ongoing activity.

However, the PMBOK® Guide – Sixth Edition does have some guidance on adapting project risk management for agile and adaptive environments.

It explains that high-variability environments incur more uncertainty and therefore risk – so far, so expected. The book recommends carrying out frequent reviews of what is being built. It talks about making sure teams share knowledge and talk about risk so they understand risk management concepts and can manage risk. It doesn’t specifically mention that risk can come from the process (as it can in a predictive environment) but that could be inherent in the suggestion that the content of each iteration is selected based on risk profile.

All project environments benefit from an ongoing review of risk, keeping the documentation up to date and making sure that there is a clear understanding of the current risk exposure so you can take action if that exposure feels too great at any one time.

Tailoring feels like making smallish changes to the way project risk management can be applied, based on the type of project you are doing and how you are doing it. Frankly, it’s not rocket science. You should have been doing this anyway, long before the Sixth Edition came out. All project management processes should work for you, not force you to jump through hoops for bureaucracy’s sake. So if you feel like your approach to risk management is too light or too heavy handed, it’s time to start tailoring.

Pin for later reading:

how to tailor project risk management

Posted on: July 28, 2020 09:00 AM | Permalink | Comments (5)

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 (5)

The truth is more important than the facts.

- Frank Lloyd Wright



Vendor Events

See all Vendor Events