When you think of risk management, what springs to mind first? For many people, it’s something like a risk discussion on a project aimed at uncovering risks or a log of project risks. Perhaps you think of a process for managing risk on projects.
Whatever comes to mind first for you, it’s highly likely to be something connected with running a project.
However, risk management goes beyond the role of the project team. In this article we’ll discuss the 3 must-have roles for risk management within your organizational and project risk structure. Yes, top of the list are project managers! But there are other crucial roles that your organization should adopt and embed in order to make risk management a truly useful part of your approach to business governance.
Role #1: Project Managers
Project managers are the first line of defence for your business against project risk. They are responsible for:
- Identifying project-related risks
- Assessing those risks
- Preparing strategies to address the risk and getting buy-in for risk management activities as required
- Carrying out the risk management activities within the project
- Reporting on risk management
- Closing down risks that have passed.
Of course, they do all of this with the support and expertise of project team members and other subject matter specialists. But at the end of the day, the project manager is the individual accountable for the risk management activities being carried out on the project.
Risk management is at the core of project management methodologies and is covered extensively in professional standards and best practice. Your project teams should have no difficulty in being able to carry out this role, or in acknowledging that it sits with them.
Read Next: Managing Project Risk for more details on what the risk management activities of project teams should be.
Role #2: Business Owners
Projects don’t start because a project manager has nothing better to do. They begin way back in the project life cycle with a business case or proposal document that sets out why the project is required and the problem it is addressing.
The person who wrote that business case is the business owner, and often turns out to be the project sponsor if the project is approved.
This role has a significant part to play in managing risk, but the kind of risks we’re talking about here sit outside of the responsibilities of the project team, and align to functional areas. In his book, Filling Execution Gaps, author Todd C. Williams gives examples of this kind of risk including:
- Market conditions
- Market adoption (e.g. of a new product)
- Product usability.
These are things that would have an impact on how successful a new product is, but that are beyond the control of the project team. These risks would be (hopefully) substantially addressed in a business case to ensure that, even with awareness of the risks, the project would still be viable. The ongoing management of these risks would fall to the business owner who could be the product owner, a marketing manager or another executive.
Role #3: Risk Governance Group
The final role to consider within your organizational framework for risk governance is that of a specific governance group. This is a cross-functional group of subject matter experts who can bring their specialist knowledge to the management of complex risk across multiple projects.
In other words, it’s a committee who look at program and portfolio risk where it makes sense to manage these collectively. Examples of where it might be appropriate to look at risk across projects would include construction initiatives and high-risk projects like defense and aerospace work. Alternatively, you may decide that it’s appropriate to have this kind of multidisciplinary group looking at portfolio risk in your business even if you don’t build nuclear power plants routinely. There are many reasons why a strand of your project governance framework linked to risk could be beneficial for your organization.
Risk Roles Defined
Importantly, you should be defining risk roles within your approach to risk management. Your governance framework should call out the roles involved and what they are responsible for. The purpose of doing this is to bring clarity to the individuals in those roles. When they know what they are expected to do, it’s a lot easier for them to step up and actually do it. Framing their responsibilities clearly leaves no room for error or misunderstandings.
As well as providing clarity about what is expected from people in the roles, it also makes it easier to fit risks to people. In other words, when you know that the business owner is responsible for risks relating to the business case, there is no opportunity for that individual to sidestep their responsibilities! You don’t need to discuss where the risk sits: it sits squarely with that manager. This can help hugely in organizations that struggle to get ownership for risk management activities.
When you come to put together your own approach to organizational risk management, you might decide that you need more than these 3 roles. That’s fine. It’s important to stay flexible and define an approach that works for you. However, the 3 roles outlined above provide three different levels of risk management expertise to your business, at different levels in the project, program and portfolio structure. As a baseline, you should consider them all. How you then go on to embed them in your own risk culture is ultimately a decision for senior leaders and your Project Management Office team.
Recommended reading: Filling Execution Gaps, Todd C. Williams, de Gruyter, 2017.