The Money Files

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.

Methodology

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:

Ah, the mythical management reserve. This hits project managers who have sponsors that are poor at following through on their promises. The sponsor says that there is some kind of ‘contingency’ or ‘management reserve’ that can be spent at their discretion if required, say, in the event of an unplanned project disaster.

Said disaster happens and suddenly they don’t have authority to access those funds, or another project has used them, or you need to write a business case to access them…

How to fix it: You will struggle to fix this one in advance but your best bet is to make sure that you have full confidence that any pot of money that is being held outside your official project budget does actually exist and is there for you. Of course, the best thing to do will be to manage the project so you don’t need to tap into additional reserves.

I explain more about how to handle management reserves in this video.

Pin for later reading:

We all have the same number of hours in the day, so how come some people seem to get more done?

Well, there is no magic secret. They probably are just very good at focusing and prioritising their work. They get more done – or at least, they appear to – by doing the right things.

That said, there are a few tips and tricks I’ve discovered over the years that help me speed up my daily work. First: get a super-fast internet connection! Once you’ve got that, you’ll get less frustrated waiting for pages to load. It’s amazing how much we need to use online services and tools in the course of our day jobs, and for everything else that’s a ‘home’ job too.

After that, try the tips in the infographic below and see if you can use them to improve your focus and shave a few seconds off your regular routine tasks.

Data is a differentiator. Companies that can capture what customers buy, like, and use can interrogate that data to provide insights that help them stay ahead of the curve. Big data is the term given to the storage and analysis of workplace data for the purpose of creating meaningful management information.

The data from collaboration and project management tools is a subset of all this data. Real-time project analytics can add huge value to streamlining project management processes and in identifying early warning signs for projects.

Being able to parse a discussion thread from your collaboration tool and single out potential risks and issues could change the role of the project manager in the future. Furthermore, natural language searches will make it easier to include narrative discussions, meeting minutes, and more in the data analysis, saving hours of time when investigating or predicting problems. All of this data could be used to predict the future success (or otherwise) of projects.

There is already work happening in this sphere: The PMO Flashmob here in the UK held a session recently looking at the role of AI in the project office and project management domain. While I didn’t attend, they did publish some interesting Inside PMO report on the topic.

There’s also been a discussion around RPA – robotic processing automation (in other words, using algorithms to process info instead of humans – it’s not ‘real’ robots sitting at a desk next to you doing PMO work). There is a lot of scope for development in this space, freeing up knowledge workers to – you know – actually use their brains for stuff and building relationships to help get projects done.

Data presentation techniques

Allied to the big data revolution is the rise of data presentation techniques, because the trouble with all that data is that it is very difficult to understand. There is a trend toward simple, clean designs for websites and tools with high usability and a very visual impact. The growth of social media sites like Instagram and Pinterest, plus the sudden, recent spike in the number of infographics doing the rounds on sharing sites shows that users are gravitating toward images.

This is relevant to project management collaboration tools because project managers have to adapt the way they communicate to suit the needs of stakeholders. If the needs of stakeholders are evolving to include a requirement for more visuals, then project managers will need to move away from text-based project reports to a more engaging way of sharing status updates.

Visual data presentation is not new to project management—after all, that’s really what a Gantt chart is. Kanban, too, is a visual project management approach and many agile teams work with visual plans. We could well see the visual preference for presenting data manifesting itself in more tools that use images and visual workflows in conjunction with traditional Gantt charts.

This article includes a few points that were made in my PMI book: Collaboration Tools for Project Managers. Given what we’ve been going through and seeing so far this year, it felt appropriate to try to pick out some comments on tech for teams and where that might be taking us – because it seems to me that virtual working is here to stay.

Pin for later reading:

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: