What is a Project Risk?
Project risk management is an important aspect of project management. It is an important skill for a project manager to have. But, before we have an understanding of project risk management we have to internalize the concept of what a project risk is. Here is how I’d define a project risk:
Anything that could impact your project is a Project Risk. For most practical purposes, a risk is considered to be something that may have a negative impact on your project. Theoretically however, a risk may have either a negative or a positive impact on your project.
From a logical point of view, issues are easier to understand. We deal with risks and issues on a day-to-day basis. Let’s define what an issue is:
An issue is situation that has occurred that is negatively impacting a project.
Now that we understand what an issue is, we can define a risk in relation to an issue - that would be another way to look at a risk:
A project risk is a project issue that has not happened as yet, but there is a certain probability of that risk happening.
Sometimes definitions are very dry. We may want to examine using some examples.
Examples
Can you guess some examples?
Let’s go with a few simple ones.
Possibility of you being hit by another car is a risk.
Possibility of you hitting another car is a risk as well.
Possibility of a meteorite hitting your house is an extremely less probable risk.
The above three are examples of general risks that we face on a day-to-day basis. For more details on the general topic of risk, read What is a risk?
But this topic is not on the general concept of risk - this topic is about the specialized concept of project risk. Let’s examine some examples of project risk below.
Your project may get delayed due to missed requirements is a project risk.
You project may get delayed due to requirements not being met during product development is a project risk as well.
Your project may not be able to meet the required project delivery deadline.
Your team may not be able to deliver everything in the scope of project requirements due to cost overruns.
Your team may not be able to deliver everything in the scope of project requirements in order to avoid schedule delays.
The quality of the product delivered by your project may not meet required quality standards.
Your project delivered on time, on budget and with full scope may not still fully satisfy the stakeholder.
Categories of Project Risks
There are obviously many more examples of project risk that you can come up with. If you notice carefully, you’d see that the risks can be grouped into different categories depending on if the risk is a risk to the project scope, project schedule, project budget, project quality etc. Let’s list them below:
Project Scope Risk - A risk that may impact the scope of what is to be delivered by the project
Project Schedule Risk - A risk that may impact the schedule of the project
Project Budget Risk - A risk that may impact the budget of the project
Project (Deliverable) Quality Risk - A risk that may impact the quality of the deliverable of the project
Management of Project Risks
What is important to understand is that a project risk may impact one of these areas - Scope, Schedule, Budget or Deliverable Quality, but as a project manager, you may still be able to manage that risk and not let that compromise the overall project. Good project management practices recommend to build some amount of contingencies (reasonable) within each of these areas to account for unexpected variances. The core idea is that when a risk within one of these areas materializes, either/or of the two steps can be taken:
You would have either a contingency within that area to absorb the impact
You would be able to transfer the impact to another risk category and absorb it there
Again, let’s take a look at an example:
The project is tracking behind its baseline schedule - it is a schedule risk materializing - Some ways to potentially handle it:
Absorb with schedule: The delay is a couple of days and there is sufficient contingency built within the project schedule to absorb it
Transfer to budget: The delay is somewhat larger, but if the project has some budget contingency then you should be able to add 3 additional developers for 2 months (at extra cost) to absorb the impact
The discussion on the topic of risk is so vast and could go so deep that even thinking about capturing it all in one post is not fair. So, I’ll be capturing this in various posts over a period of time.