When most of us think about “Risks” we think of activities which could bring harm to us, or at least cost us money, time, reputation, and so on. Risk Management is one of the principal jobs of a project manager and one of our key knowledge areas as a PMP. Further, most of the risks we identify are actions that would cause a task not to execute, or execute late or over budget. If I have a critical path tasks that requires me to finish an implementation on a specific date, the most obvious risk is that the task does not execute. Although failure to execute a task is certainly a risk, there are two other risks (and a bonus risk!) that a Project Manager must also anticipate and include in their Risk Register: Process Error and Consequential Error.

The failure to execute is an important and obvious risk, and from my experience 99% of identified risks are a result of this. I’m willing to wager however that if you compare your issue log to the risk register you will see a large number of issues don’t arise simply because a task didn’t execute, but because it didn’t execute exactly as the PM had anticipated or that it did not produce the anticipated result. This isn’t an execution issue; indeed the tasks executed exactly as we had planned for! How then can we identify such seemingly random risks? We can start by stop seeing them as random and unpredictable, but simply logical.

“Every project is initiated for the sake of some larger value or organizational strategic objective.”

Value based project management believes that a project is greater than its execution. Projects are not executed simply for their own sake, but rather every project is initiated for the sake of some larger value or organizational strategic objective. Similarly, tasks are value based as well… and values are deliberate. Every task is comprised of two parts, the cause or action, which is usually what we list in the task list, and the deliberate effect, which is the deliverable, objective, or desired outcome that is the purpose for the task. Unless you are adding random tasks to your project, every task in your project plan is deliberative.

“Similarly, tasks are value based as well… and values are deliberate. Every task is comprised of two parts, the cause or action, which is usually what we list in the task list, and the deliberate effect, which is the deliverable, objective, or desired outcome that is the purpose for the task.” 

When we are examining risks, the first mistake we make is that we ignore the deliberative nature of the task, and hence only consider risks that affect the cause. A risk however is “any event which impacts the successful execution of the project plan”, not simply risks which effect the execution of a specific task. Certainly identifying a risk which would cause a task not to execute is important and valid, but that’s only one part of the identification.

The 4 Sources of Every Risk

Every task is a statement comprised of a conditional statement comprised of a cause (the task to be executed) and the deliberate effect. If the task fails to execute, it certainly threatens the project plan, but failure to execute is not the only way in which a risk can affect the project plan. Indeed there are four distinct risks that need to be analyzed in relation to each task.  To identify these we simply need to change our perspective from seeing the failure of the actionable task–the cause part of our equation–as the risk to seeing the failure of the conditional as a whole –the implication of the cause and the effect– as the risk.

To do this we produce a statement by taking our task and identify the result, deliverable, or outcome which it is meaning to produce; we need to answer the question “why am I performing this task?” From there we can use logic to determine what 4 areas of risk we need to examine. Since a risk is any event which would cause a disruption in the successful execution of the project plan, a risk is an event where this previous statement turned out not to be true; an issue is an event where the project plan ended up not being true.

“We need to answer the question “why am I performing this task?”

After we have our deliberative statement we simply need to evaluate all permutations where it is false. For instance, lets say that I have a task “Buy Widget” for which I’ve identified the anticipated result as “having the widget”.  The deliberative statement then is:

“If I buy the widget, I will have the widget.”

And the desired outcome if the project plan is successful is:

I buy the Widget and I have the widget.

The risk therefor is that this statement is not accurate, or in logical terms, is negated. That is, the plan will not be successful if it is not the case that I by the widget and that I have the widget or in logical terms:

~(Buy the Widget & Have the Widget)

 I’m not going to go through the logic, but the result of negating this statement produces three outcomes in which the above statement can occur, and thus are the three possibilities of risk. If any of these outcomes occur, the project plan will be rendered false, and hence each of these are a risk that has to be identified.

 

Risk 1: Execution Failure: “The situation where I don’t buy the widget, and I don’t receive it.”

In the first case, what I call an execution failure, is pretty self explanatory and  previously discussed is where most risks are identified; by not performing the action, the consequence was never realized.

 

Risk 2: Process Error: “The situation where I don’t buy the widget, but I do receive it.”

The second risk is what I call a conditional error. Simply speaking, my logic as a project manager was flawed, and simply the action did not produce the intended result. Things like logistic errors, problems with the supplier, or a forgetful sales-person can easily produce this outcome. In this situation, the problem wasn’t with task execution… the problem was that the process itself failed to produce the intended result.

 

Risk 3: Consequential Error: “The situation where I buy the widget, but I do not receive it.”

The third risk is generally where “opportunity” falls into play. This is the risk that the intended outcome occurs, even though the actionable task did not execute. In the project management world opportunities are considered risks, and simply because something is a risk does not mean that I do not want it to happen or wont position myself for the opportunity to be realized… it just means that I need to plan for it and change my project plan to account for it, as failure to do so will result in the project not going as planned, which is an issue! For the third example, we have to look at risks where I do not complete the action, and yet the desired outcome occurs. (For logicians this is called Affirming the Consequent. We treated our statement as if to say “the result will occur If and only If I do xyz”, when in reality multiple actions could have produced the intended result.)

 

Risk 4: I’m simply wrong.

The last risk that can result is that we performed the action, and we obtained the desired outcome, and yet the project plan just doesn’t work. We purchased the widget. We received the widget. We paid for the widget. We did everything right and everything happened exactly as we predicted. And yet, we failed. In this case we can only deduce that the logic of the project itself was flawed… the consequence of the task could have produced an outcome that had a negative effect on the project or we needed an outcome that couldn’t result given the tasks we accomplished. Unfortunately the forth risk is a risk that is present in every project that we undergo, and looms over the head of every project manager: it is the risk that were just simply wrong.

And that’s a risk that we all just have to take.