The Money Files

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:

In this video I give you a quick overview of some of the key date-driven milestones you should be aware of on your project and why these are important. Budgeting is so driven by business timescales. If you miss a date, the implications could be huge – especially, say, if the date is to submit your budget requirements for the next financial year!

Pin for later reading:

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:

Are you finding it hard to get governance working right on your project? Governance, in the widest sense of the topic, is everything that helps you manage and control the project, so strong processes are part of that.

And when your projects let you down, it’s impossible to provide the level of governance you need.

The infographic below shows reasons why project processes might not be robust enough to support good project control.

When processes are too informal, no one really knows what to do to get things done, or how to record that they happened.