by Cheryl A. Wilson PMP, RMP, CCEP
Every time I am in a group speaking about risk with project managers I am always asked the question: “what is the definition of risk?” This question comes from even certified Project Managers (PM). I can understand this confusion as the definition of risk has changed from one version to the next in the traditional PM environments leaving an unclear definition of this important concept.
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. The 2011 Gartner report indicated that 70 – 80% of all projects are still failing. What is alarming is the number of certified PM is increasing. If there is an increase in PM each year, why is the rate of project success not increasing to match this trend?
We at MCLMG Research believe one of the 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.
If projects are still failing at an increased rate, could we conclude that the current risk model does not work? So, let us get to the heart of the issue, understanding what a risk is and what risks matters to our projects.
I am often told, risks are everywhere; I walk out the door and there are risks. But is that true?
First, let us start with a simple definition of risk then we will break down how to identify our risks and how to manage them. Many PM and project team members do not identify risks correctly and therefore end up managing the causes and not the effect.
As a PM, it is important to understand the definition of project risk in order to understand which risks matter to our projects. Not all risks are true risks to our projects. From the currently accepted definition of risk provided by most bodies of knowledge, i.e., “a risk is a potential undesirable outcome resulting in a loss,” we can expand to what risk matters to project managers (PM) concerning their projects.
We all experience risk in our life, and risk is everywhere. In the broadest sense, we are all exposed to danger, harm, or loss at almost every turn of our existence; however, this does not mean that all risk is of importance or that it matters. One of the biggest aspects of project risk management is being able to tell the difference between risks that matter and risks that do not with respect to the potential negative impact to our project deliverables.
In the financial world, risk is described as the uncertainty of not obtaining an adequate return on an investment in addition to the potential loss of principle. Risk terms used in the financial world are asset-backed risks, credit risks, foreign investment risks, market risk, etc. Therefore, the management of risks in the financial environment is the cost of obtaining valuable information that can reduce this uncertainty about a future negative impact to the original investment. Another side of financial risk is dealing with not obtaining an expected gain or rate of return for the amount of risk taken on the negative side. Trust us when we say that the financial world has risk down to a science – a most mathematical and rigorous science.
As project managers, we need to define risk from the perspective of risk that matters to our deliverables just as the financial world defines risk with respect to their investments. There are quite a number of similarities; however, financial risk is not totally equal to project risk. In order to know what risks matter to our projects, it is first important to understand what constitutes project risk.
Project risks are uncertain future events (UFE) that should they occur will have a negative impact on the production of fit-for-use project deliverables. This means that all project risks are tied to 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: time, cost, scope or quality.
If you have identified an event that is a certainty or near certainty such a gravity or physics or a chemical reaction or “Tina is going on vacation” (a near axiomatic certainty if we know Tina), then it is not a risk. Tina’s vacation is not a risk, but an event or action that is merely within the prevue of a good PM management scope. Tagging all future events as risk potentials is an attempt to transfer the necessity of an experienced, capable PM’s management skills into a realm where one can say they have no control or ability to impact any event within the project’s scope. In other words, if all future events are labelled as risks then there is no need for a PM to command a 6 figure salary. We will only need risk managers, risk owners, and risk action owners sitting in front of large computer screens trying to catch risks before they trigger. Remember, project risk are UFE that can have a negative impact on the production of a project’s deliverables, not ALL future events as all future events while they may be uncertain do not have a significant impact on the outcomes of our projects. For those that do not accept this, we would suggest a study on a concept called the “Butterfly Effect.”
If you have identified a negative event that is not tied to your deliverable(s), then it is not a risk. Not everything that is bad on the project is a risk. 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 is a topic that will be further discussed in the article: “Not all uncertainty is project risk.”
The easiest way to identify project risks is to list your deliverable(s); determine what would be the negative event to prevent you from producing your deliverable(s) as “fit-for-use” as this will lead you to your primary deliverable-centered risk. 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 final realized what risk 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 and once causes are listed as risks, the inability to mitigate your risks will lead to the inability to reduce uncertainty on your projects.
The best way to simplify the understanding of “what is a risk” from just normal “issues” on the project that are all apart of normal PM responsibilities is by providing 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. The move was to take place on a Friday, Saturday and Sunday. The deliverable is business operations up and running by 6 AM Monday morning. The risk in this situation is: not having business operations up and running by 6 AM Monday morning. There are many potential causes for this risk to trigger, i.e. tornado, lack of power, etc., but the risk remains: not having business operations up and running by 6 AM Monday morning.
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.
To recap: A risk is an UFE that if it occurs will have a negative impact on the project’s ability to produce fit-for-use deliverable(s). We will continue to talk about how to identify risk potentials, causes, and triggers in future articles. Also, it will be important to understand how each risk component will help reduce uncertainty and provide valuable information to support better decision making on our projects.