Skip to content

So really …. How Do You Define “Project Risk”?

So really …. How Do You Define “Project Risk”? When I am asked to speak at a conference about Project Risk, or for a team of Project Managers (PM) at an organization, or just to a project team, I am ALWAYS asked this question …. “So what is the definition of project risk?”  As I know this question is coming I am prepared to stop my presentation, no matter where I am and define this four letter word that confuses not only the certified project management professional (PMP®), but the non PM and project team members as well.  I can understand this confusion as the definition of risk is not the same throughout the industry thus leaving an unclear definition of “true project risk.”

One of biggest reasons projects fail is the lack of valuable information that can make a difference on our projects.  Valuable information will reduce uncertainty.  Uncertainly is at the heart of risk management.  If PM do not understand the meaning of risk and cannot identify the risks that matter to their project, they cannot reduce uncertainly and cannot provide this valuable information to increase the project’s success rate.

The definition of risk needs to be understood in order to correctly identify, manage and hope to reduce the uncertainty of risk on our projects.  I would define a successful project as a project that has produced the fit-for-use (FFU) deliverables within the defined budget and timeframe.  The alarming statistics from the Standish Chaos Report should alarm us as PM.  The report from 2009 indicated that only 32% of projects actually are successful under this definition!  The number of failed projects has increased in the past 20 years according to the report. So, to take us full circle, in order to change these statistics and produce more successful projects, we need to identify what the uncertain is on our projects to be able to increase project success rates.  This uncertainly is our project risks.

First, let us start with a simple definition of project risk so we can then break down how to identify and further manage our project risks successfully.

Project risks are uncertain future events (UFE) that should they occur will have a negative impact on the production of our fit-for-use project deliverables.  This means that all project risks are tied to our project deliverables – pure and simple. A significant hindrance to understanding project risk is accepting this concept – no deliverables, no project; no project, no risk. Therefore, a project only has risk if it has deliverables that must be produced to a quality level defined as “fit-for-use.”

If you have identified an event that is not in the future, then you have identified an issue and not a risk.  An issue is an event that has already triggered into reality and is already impacting one or more of your project’s deliverables via its detrimental deterioration of one of the project’s primary constraints: scope, time, cost, or quality.

Remember, it is important to understand the definition of project risk in order to understand which risks matter to our projects.  If the PM or project team does not keep in mind that risks are tied to the project deliverables, several things happen.

  • Normal project obstacles are that should be handled by the PM are managed within the risk registers and not by the PM, and
  • The causes of the risk are identified and managed and not the risk itself.

If you have identified a negative event or some obstacle that is not tied to your projects deliverable(s), then it is not a risk. Not everything that is bad on the project is a risk that needs to be added to your risk register. This is a hard concept for many PM as they see everything that is a problem as a risk and try to manage these problems under the risk umbrella.  This causes many of the true risks to be lost in the chaos.

Below are a suggested series of steps to follow to ensure you have identified your true project risk(s):

  1. List your project deliverable(s);
  2. Determine project risk(s), what would be the negative event to prevent you from producing your deliverable(s) as “fit-for-use”
  3. Identify any events or conditions that make the risk a negative impact to the deliverables
  4. Identify the triggers that cause the risk to transform from a potential state to a real time

This activity will assist you in identifying your deliverable-centered risk(s).  All projects have one primary risk and if there is more than one deliverable, there will be more than one risk.

This concept may take a moment to realize, but once you do, you will have finally realized risks to your projects truly are.  The error most PM and project team members make is identifying the causes of the risk(s) to their deliverables not the risk(s) themselves; thus, in attempting to mitigate the causes and not the real risks to your project deliverables leads to the inability to reduce uncertainty on your projects since you are applying mitigation strategies to causal events and the effects (the risks). An analogy would trying to mitigate a tornado (the weather) as your risk, and not true risk of not begin able to provide data to support your business operations. One cannot mitigate Mother Nature.

This leads to the importance of identifying the cause of each risk and the trigger to each cause. Risk causes are events or conditions that make the risk a negative impact to the deliverables, but they are not the risks themselves. It is important to remember not to confuse causes with the risk themselves (the effect).

Triggers are those events that if allowed to occur have a catalytic impact on the risks themselves. They cause the risk to transform from a potential state to anactive state where they are now in reality an issue that is causing demonstrable negative impact to the project’s deliverables. Triggers again are often mistaken for risks, but remember triggers are associated with the risk not the deliverable – only risks are associated with the deliverable.

Managing the causes to your risks is a very proactive approach and yet many PM never identify causes. Lessons learned from previous projects should have captured many of the causes of risks and will be valuable information even at the start of your projects.

The best way to simplify the question:  How do you define “project risk”? is to provide an example.

Let us say your project was to move a data-center from one building to another building over a 3 day timeframe in Oklahoma, USA.  The move was to take place on a Friday, Saturday and Sunday.

Deliverable:The deliverable is business operations up and running by 6 AM Monday morning following the move.

Risk:  As risks are tied to our project deliverables, the risk is: not having business operations up and running by 6 AM Monday morning.

There are many potential causes for this risk to trigger, but let us focus on the fact that Oklahoma, USA does have tornadoes during the time frame that this project is to take place.  So, the potential causes to the risk could be:  a tornado, lack of power, etc., but the risk remains: not having business operations up and running by 6 AM Monday morning which is the prevention of the deliverable being produced ‘fit-for-use.’

The mistake many PM and team members make is listing either causes of the risk or even possible triggers of the risk as the risk itself.

As a recap:

  • Risks are uncertain future events that if triggered into reality will cause a negative impact to the production of the project’s ‘fit-for-use’ deliverables.
  • Risk causes are events or conditions that make the risk a negative impact to the deliverables, but they are not the risks themselves.
  • It is important to remember not to confuse causes with the risk themselves (the effect).
  • Managing the causes to your risks is a very proactive approach and yet many PM never identify the causes.
  • Risk triggers are the future events that turn a risk potential into a reality called an issue.

Not every problem is a risk.  If everything is treated as a risk, then the PM is not necessary since all the events that the PM should be handling as a normal course of being a PM would now be assigned to risk owners and therefore out of the prevue of the PM; thus, the need the PM is now removed. This is NOT the effective and professional manner in which to identify, manage, or mitigate project risks. A PM must learn what they are responsible for managing and what is a future uncertain event that can cause negative consequences to the production of the project’s ‘fit-for-use’ deliverables.