Project Risk Management – Dealing with the Elephant in the Room 

project management

Projects are usually undertaken to either solve a problem or take advantage of an opportunity. The probability that the project – even if precisely executed – will complete on time, on budget, and on performance is typically small. Project management is utilized to increase this probability. So in a sense, project management is risk management.”
Bruce Pittman (Chief Systems Engineer, Space Portal, NASA) 

Risk Management on projects is often overlooked or at best a tick-box exercise. Whether you are risk-averse by nature or not, project leaders must pay close and active attention to risks on projects. When there are clear risks to a project (the elephant) it is best to name them and deal with them before it negatively impacts a project’s chance of success. 

In this post, we will look briefly at what risk management is, and then delve into why risks need to be actively managed and how this can be done practically, inclusively, and collaboratively with project stakeholders. 

What is Risk Management? 

Searching Google for “what is risk management” gives you nearly 4 billion results. Many of these will reference the PMBOK, defined as follows: 

“Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project. The objectives of project risk management are to increase the probability and/or impact of positive risks and to decrease the probability and/or impact of negative risks, in order to optimize the chances of project success.” (PMBOK® Guide) 

You may find yourself frowning at the phrase “positive risks” as we automatically assume that risk = negative.  Risks are in fact, any uncertain event that may or may not happen, which could have either a positive or a negative effect on the project. In the case of an opportunity presenting itself, it should be managed actively so that value can be derived from it. For example, if there is an enhancement in a technology being used, not utilizing this enhancement would be an opportunity missed which otherwise would have improved the success of the project. 

But let’s focus on the risks (Threats) that we are accustomed to. 

Why Active Risk Management? 

On many projects, project managers may have a Risk Register that is populated upfront that may or may not get an update now and again during the project. At this point, it is very important to note that Risks are not Issues. An Issue is an obstacle or challenge to the project that has already materialized whereas Risks are still a potential obstacle that may arise in the future. 

One certainty on a project is that project managers can’t know what they don’t know. For this reason, risk management must be done actively and continuously. By having regular risk management activities scheduled throughout the project as part of governance, the project manager can proactively address any new risks that are being identified. If this process is not followed, hard lessons will be learned when there is an avoidable issue blocking progress which could have been avoided had the issue been identified and managed earlier. 

Practical Risk Management 

The project manager is accountable for Risk Management but is not solely responsible for it. All delivery team members, as well as all other stakeholders, should be involved in the process. Why? Since risks are assigned owners and since risks can happen on any level of a project (from executives to the implementation team), everyone has to be involved. 

Here is the process that the Mint PMO follows that aligns with the PMBOK. 

Identify 

All stakeholders (that includes project sponsor down to each implementation team member), are invited to identify risks that will have an impact on the project should they realize. It is recommended that regular risk meetings are held where new risks are identified, classified and assigned (more about this later), as well as to review existing risks in the risk log. Stakeholders do not have to wait for this recurring session but can identify and communicate risks immediately to the project manager and should be encouraged to do so. 

Risks that have turned into Issues are moved to the Issue Register where they are managed as such. 

As a starting point, the project manager can use the project charter’s Assumptions and Dependencies to draft the first list of potential risks. For both Assumptions and Dependencies, the risk is that if they do not realize something in the project will be at risk. 

Use the right risk language 

To really name the elephant in the room, a very important aspect of effective Risk Identification is to use the correct meta-language in defining a risk. 

Dr. David Hillson (author of PMBOK Risk Management) suggests using the following approach to verbalizing the risk: 

 Source: Risk-doctor.com 

Let’s use a typical project Assumption to rephrase it as a risk. 

Assumption: The client has the necessary licenses available. 

Risk: As license availability is unknown and procurement is a lengthy process, there could be a delay in getting users access for UAT and Production, thereby causing a delay in achieving the project deadline 

This method of phrasing is important because when a risk is identified, there must be an action to address something specific otherwise, it remains a tick-box exercise without value. This wording makes it easier to decide on a course of action. It is also not possible to rate a risk in terms of probability and impact if the potential cause and impact is unknown. 

Assess 

The Mint Risk Management Procedure assesses risks by Probability and Impact on a scale of 1 to 10, where 1 signifies the lowest Probability of occurring and the lowest Impact if the risk should materialize into an actual event.  A level of 10 would therefore signify the highest Probability or Impact. The Risk Register then uses a calculation using these variables, with a weighting for Budget, Schedule, Scope and Quality that it could impact, to determine the risks’ rating. 

The risks identified and logged in the Risk Register are then prioritized based on their Rating and monitored continuously by the Project Manager and delivery team.  

Sample Risk Register 

Using an assessment approach like this, the project team can easily identify which are the highest-risk items that require the most attention. 

Response 

Each risk is assigned a Risk Owner that is in the best position to attend to the risk strategy as part of the Risk Response plan. They are then responsible for creating and executing the Risk Response (Strategy).  

The Risk Owner will retain responsibility overall for the risk’s monitoring, strategy, and response. 

The organization can decide upfront on what risk responses they will follow, but generally, the five strategy types are:  

  • Acceptance – live with it when happens 
  • Avoidance – put a plan in place to keep the risk from becoming an issue 
  • Mitigation – plan what will lower the probability of risk becoming an issue, and/or lower the impact of it 
  • Monitoring – Keep an eye on a risk where the probability and impact might be very low 
  • Transference – Transfer the risk to another party (sometimes outside the project) to avoid it impacting the delivery team 

Monitor 

The Risk Owner, once identified and allocated to the risk, will monitor the effectiveness of the strategy’s execution to ensure that the planned response is effective. The Risk Owner will provide continuous feedback to the Project Manager on the status of their risks and in the event of realization, on the action plan, its execution status and effectiveness. 

Ideally, a risk strategy will have a task as an outcome that the risk owner will action to meet the plan decided on.  

Risk management tasks can be added to project tracking tools such as Microsoft DevOps to track progress and identify whether there are further obstacles. Use DevOps as well to plan for regular risk review sessions as part of sprints for example. 

Conclusion 

Once the whole project team embraces risk management, they will start to understand its value. The project manager needs to ensure that it is not seen as just another admin-chore, and creative collaboration techniques can be used for this. Read my previous blog post on Benefit Realization Management which goes hand-in-hand with Risk Management as it asks the question – what can potentially happen to keep us from realizing the benefits the project is supposed to fulfill? 

The Mint PMO  

The Project Management team at Mint SAendeavors to build close relationships with our clients and remains aware that a project is usually part of a bigger picture. Our Mint Project Governance Framework includes active Risk Management so that we ensure that all internal and external factors are continuously assessed to support successful project delivery. 

Recent Blogs