The processes you have for project management – or lack of them – can add significant risk to your project. But you don’t often find them called out on the risk log.
Poor processes can add time delays, extra steps and confusion. They contribute to poor communication and overspending. They impact project quality. In short, processes that aren’t optimal can hinder your ability to deliver a decent outcome for the project.
Unfortunately, processes are often constrained by the company you are in. If you are mandated to follow certain processes, you have little flexibility to do anything about them. That’s not a good situation to be in – ideally you should be able to tailor the process to the size and complexity of your project.
I’ve highlighted three of the main process-related factors that influence risk on your project in the video below.
Pin for later reading:
The people in the project team, and the processes they use, are a risk factor to your project.
You might not have them on your risk register, but they definitely add risk.
For example: if you end up working with an inexperienced team, you’re in a more risky situation than one that’s highly skilled at the required work.
Poor processes across your organisation, or just in your team (say, people don’t apply the processes properly) can also add risk. A particular challenge, I think, is when projects are forced to use processes that can’t be appropriately tailored for the size of project. You get small projects forced to jump through governance hoops because that’s the process – even when it’s a ridiculous admin overhead. That adds risk to the project too.
Lack of people on the team is also a risk (one that is more likely than the other two to find its way to the risk register, in my view). You’re going to struggle to hit deadlines and delivery quality work if you don’t have enough people.
The risk profile of your project is hugely affected by the project team and the context in which you work. Unfortunately, you don’t always have a lot of control over those elements. You might find yourself being given project team members, instead of being able to pick the most able.
I’ve summarised this in the quick video below, which sets out three of the ways your project team and project environment can influence the risks faced by your project. Enjoy!
Pin for later reading:
Strategy plays a huge part in whether or not your project is going to be a success. Yes – things decided way above your pay grade influence the outcomes of your project.
That happens through risk. The corporate approach to strategy (or lack of it) massively shapes how your project is going to be carried out, implemented and delivered. The framework in which your project is being managed is of course influential – I’d say it was one of the enterprise environmental factors that shapes how you need to act on the project.
The risk profile of your project changes depending on your project’s context. A project in my company will have different outcomes to the same project (even if we hypothetically believed it would be delivered by the same project team) because the corporate approach to project management is different. The risk appetite would be different.
Strategy brings risk to your project in numerous ways. I’ve called out three of the main strategic factors that influence risk on your project in the video below.
Pin it to read later:
Project risk management is a team effort. As the project manager it might feel like you are taking the lead role, but overall it shouldn’t be a one-person job. You need to work together to identify the risks on your project and do something about them.
You can’t work as a team if you don’t have a team. So, you should identify your risk management team as early as practical in the project. That’s what textbooks would recommend, but in my experience you don’t always know who is going to be the right person to be the risk owner for a particular risk until it makes it on to the risk log – then you need that person on your team.
However, there are some common roles you will definitely need involved in risk management. Identifying who is going to fill those roles will save you time later. When a risk is uncovered, you don’t want to be waiting around trying to work out who is going to look at it. You want to know, broadly, who is going to help you deal with it.
Let’s look then at who does what in risk management on a project. These are the people you need to inform about the risk management processes and get them lined up to act when something is brought to your attention.
You might think this is obvious – many of you reading this will be project managers. But if you are an IT workstream lead or a Scrum Master, or Product Owner, then maybe you will be working alongside the project manager.
The role of the project manager is to create the risk management plan. The risk management strategy is likely to be set by the Project Management Office, but you might need one specifically for your project. It is more likely that you’ll take the risk management policies for the business and the PMO and make them actionable and meaningful for your project.
Another role for the project manager is to update the risk log. Unless you have a dedicated risk manager working alongside you, that job falls to the PM.
Finally, the project manager should take a role in the governance of risk. That involves ensuring risk management actually happens and that people take the process seriously. They should know what the process is and follow it. You can check that there is enough attention being paid to risk overall and provide oversight. For example, make sure you have risk management as a standing item on your project board agenda.
Second, we have the role of the project sponsor. They may not take a hands on role in doing mitigation actions (although they might, depending on what is required). However, they are going to be a huge influence on how risk is managed.
The sponsor will set the risk appetite for the project. That means they are accountable for the risk profile of the project (making sure it isn’t riskier than they would like) and ensuring it fits within the risk appetite for the business overall.
The sponsor also acts as the escalation point for the team. They are able to resolve risks that the project manager and team can’t. And if it needs to go even higher, the sponsor is the person to do that.
Next we have suppliers. This is shaping up to look like a list of people who are involved in your core project team and project board, and that is not a coincidence!
Suppliers and the work they do also carries risk. They have responsibilities around risk management, namely making sure that they flag anything important to the project manager. They may maintain their own project risk log, but they should also be passing up significant risks to the project manager.
If a supplier tells you that their work is creating no project risk and there’s nothing for you to be notified of, be very suspicious! That to me would sound like someone who doesn’t know what risk management is or what they should be doing.
Many risks relating to your supply chain are going to carry a financial risk. For example, if the supplier can’t source the correct parts for your machine, then you’ll have to get them elsewhere at a higher cost. Make sure you factor in risk management plans for supplier risks because they could leave you significantly out of pocket.
Your core project team are essential people to work with you on risk management. You’ll involve them in risk identification at the beginning of the project and throughout. You’ll rely on their expertise to put together risk management plans and own the actions. You’ll need them to help you spot new risks or to deal with risks that become issues.
The day to day risk management activities are going to be carried out by the team.
Project Management Office (PMO)
Before you get too far into a project at a new place, talk to the PMO. What they expect you to do for risk management is going to follow the normal pattern: identify risks, manage them, report the big ones, but there might be specific processes or templates they expect you to use.
You might also be subject to internal audit or project assurance. The PMO may get involved in this and it would be natural to expect them to see your risk logs as part of any review.
The PMO’s role isn’t all about governance and holding you to account. You may also be able to draw on them for support. Sometimes project coordinators sit within the PMO and can be ‘loaned out’ to project managers for project admin or support tasks. This could include coming to risk meetings to take notes, updating the risk log, chasing team members for updates and things like that.
Think about who you are going to need for risk management on your project, just like you think about what resources you need for every other area of your project. Identify the types of people who will need to know about the process. And then involve them early.
Let them know what you expect of them and what the process is going to be. The earlier you do this on the project, the easier you will find the later stages of risk management because everyone will know what the whole thing is about.
Pin for later reading:
I’ve been going back over my notes from the PMI Global Congress EMEA which was in London earlier this year and I realised I hadn’t written anything about Olivier Lazar’s presentation on budgeting and risk. I wasn’t sure what to expect but he raised some good points about ensuring your project budget accurately reflected potential issues and gave tips on how to do that.
He talked about the project budget structure as one that acted as an early warning system, integrating cost, scope and risk.
“Everything starts with an estimate,” he said. “An estimate is a risk.”
The truth about estimating
Estimating, Olivier explained:
“You fail it you have to react,” he said. “Project management is an activity of anticipation.”
Having said that, you can’t anticipate events in the future – unless your crystal ball works better than mine – but you can put mechanisms in place to maximise the opportunity to anticipate and avoid the wilful blindness that was discussed in other presentations during the conference.
Use your plan as a baseline
We all know that what you plan isn’t going to happen exactly as you had scheduled. Olivier said that we should consider the project plan as a baseline, not a map; a speedometer, not the GPS.
Usually, he went on, projects go over time and over budget because risk has not been adequately taken into account.
Therefore it’s important to plan the risk response as early as you can, because this helps you work out the cost. Risk response budgets can then be included in your budget, lowering the likelihood that you’ll go over your planned spending.
He recommended grouping risks together then identifying common response strategies, with a minimum of 3% contingency. You’ll want to increase the contingency reserves in these situations:
These circumstances reduce your ability to accurately identify the risk and so push the contingency up. Where you have low levels of uncertainty and ambiguity you can thoroughly identify risks (for example, in projects where you’ve done the same thing before) and thus be able to reduce the contingency reserves accordingly.
When you have identified risks (or threats) that have a high probability of occurrence, Oliver suggested integrating these fully into the project plan and identifying the opposite opportunity – the one that you could enhance or exploit.
Monitoring as you go
If 30% of your budget at completion has been used and yet 80% of your risk response budget is used up then you have a problem.
These figures show that a lot of things you thought were uncertain have actually happened – no one expects every single risk to really happen on their project because they are only risks, not certainties. If you merge your budget at completion, contingency reserves and risk budget together you might not be able to identify this situation as early. You’ll lose control and you can’t know what is happening because risk and contingency, Olivier explained, are not the same thing. Your risk and contingency budgets do not inflate your project budget (or reduce it, for that matter). They only give you more control.
If you are in this position then you need to act quickly to get your project back on track.
Review the scope statement and – while acting quickly – also take the time to react and review. Currently you are within budget so you may not have some of the triggers that you would expect, but consider this tracking your early warning sign.
Olivier concluded by saying that additional control lets you “move from panic and chaos to project management” and reiterated the idea of project management plan as the overall map for y our journey, not the step-by-step walking guide.
Have you split out risk and contingency budgets on your projects? I’d like to know what you think of this practice, so let me know in the comments.