The Money Files

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.

Inputs

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.

Outputs

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.

Timing

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:

I had a question recently which was: Where do project requirements come from?

In this quick video I try to answer that question! The TL;DR (or should that be DW?) is that you have to spend the time to talk to the whole stakeholder community to find out what requirements they have and what they are expecting. Only then can you start to prioritise and plan what’s actually going to be in the scope of the project.

How do you elicit requirements? Let us know in the comments section!

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:

Moving to online tools and collaboration via the internet takes planning, thought and consideration. It’s honestly not as easy as giving everyone a Slack account and hoping they get on with it.

Helping your team transition to online collaboration tools is something I discuss extensively in my PMI-published book, Collaboration Tools for Project Managers. In the infographic below, I share some of the do’s and don’ts of moving your team online.

Community, communication and tech all need to come together to enable your team to work efficiently in the online space. It’s a freeing and flexible way to work, but it needs support to get going and become second-nature. It is actually quite different to the mindset of being in the office all day.

Is this something you’d like more guidance on? Let me know in the comments, because I’ve got loads of tips and advice to help you get the best out of virtual working!

This article is part three of my look into project risk management, and today we are continuing our look into trends and emerging practices, 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)

There are three risk-related trends that bear investigation. Last time I looked at non-event risks and today we’re covering project resilience and integrated risk management.

Project resilience

You know about personal resilience, right? I’ve seen a lot written about personal resilience, in particular to do with how we can support ourselves and our families through difficult times. A lot of factors go into personal resilience, from preparedness to mindset.

Projects can be resilient too.

The idea of project resilience relates to unknowable-unknowns – those things we never saw coming and couldn’t have prepared for (have there been any of those lately??). These are called emergent risks: risks you can only identify once they have happened. If your project is resilient, those issues are less problematic because you can deal with them. You can’t stop them, but your project can cope. Or at least, cope better than if you had made no effort to build resilience in the team at all.

Build resilience on your project through:

• Having the right level of budget and schedule contingency
• Maintaining a risk budget for the risks that you do know about
• Working with flexible processes that let you shift quickly if necessary and deal with change
• Empowering the team to make the right decisions, and trusting them to get on with it
• Reviewing the project regularly to spot early warning signs that something might be going wrong or coming
• Getting input from stakeholders for clarification to minimise the chance of scope or strategy being the cause of emergent risks.

Resilient projects are more likely to be able to weather the storm and bounce back, because they have space and process to do so. In other words, the better managed your project, the more likely it is that you are going to be able to recover from any curveballs thrown your way.

Integrated risk management

Integrated risk management is simply making sure all the risks from the project are integrated into a bigger picture. For example, your project could be part of a programme. On the last programme I ran, we consolidated risk from all the projects so we could assess the overall health of the programme, and that overall position was reported at the programme board monthly.

Integrated risk management processes mean that risk is owned and managed by the right people in the organisation, at the right level. So as a programme manager, I wasn’t reporting up every single risk those projects had, but the important ones. There is a level of professional judgement applied to back up the risk assessment process, so that the significant risks are escalated to the level they need to be known at.

Beyond projects and programmes, integrated risk management also looks at how project-level risk relates to the portfolio as a whole. This information is useful because it helps executives get a clear picture about the level of risk the business is taking with regards to delivering change. If too much change is going on, they might consider that too risky, and slow down or postpone some projects until other initiatives have completed.

Enterprise risk is the next level. You may have a corporate risk manager: their job is to aggregate risk from all over the business. They’ll be looking for input from each department but also projects and programmes, and the entire portfolio, and considering how that works with and affects operational risk too.

Basically, integrated risk management is the overall corporate governance structures and framework for managing enterprise risk. As a project manager, you need to know how you fit into that, but the whole thing isn’t your responsibility. You should carry on managing risk as you do, making sure the people who need to know about significant project risks, know.

Next time: I’ll look at tailoring risk management for your environment, because a one-size-fits-all approach doesn’t work.

Pin for later reading: