Project v organizational risk

Although we have talked a fair bit about risk to this point, let’s stop and reconsider what we actually mean by risk in the project context.

You may recall that in preparation of the business case we were primarily concerned with the risk to the organisation of proceeding with one or more project alternatives. 

Theoretically, though, by the time we get to the planning phase, organizational risk is not the project manager’s problem anymore (if it ever was); that risk should have been given appropriate consideration and dealt with in initiation.

In fact, by authorizing the project, the organization is effectively saying we accept that risk, now get on with it!

Therefore the project manager is principally concerned with risks to project delivery; in other words, any uncertain event or condition that might affect project outputs.

This is not to say that outcome realization is no longer important; indeed, any changes that are made to the project plan in the course of delivery should be very clearly understood in that light. 

This is something we will return to in detail in a later module.

Nevertheless, for the purposes of project planning and the discussion here, we will limit ourselves to project output risks.

From here on, the whole point of project risk management is to identify any potential issues that may arise as completely as possible, and predetermine how these might be resolved. 

In that way, when uncertainty conspires to frustrate the project, we have the resources necessary to continue with the least disruption.

---

Risk management process

The project risk management process follows five distinct stages that recur in a cycle:

• Risk identification
• Risk analysis
• Risk prioritization
• Risk treatment, and
• Risk monitoring and control.

As with all things project management, this process is dependent on and governed by the quality of your stakeholder consultation and engagement.

Note, too, our careful use of language: a risk is an uncertain event (in other words, it has not yet occurred) that may have one or more impacts on the project, whereas an issue is an event that has occurred and is impacting upon the project.

It is also important to flag that even though we generally think of risks as something negative (as in Murphy’s Law), the processes we follow here are equally reliable in addressing opportunities; that is, uncertain events that might positively impact the project.

Keep that in mind as we introduce these techniques to consistently address project risk.