Risk appetite – OPEN

Add your own custom notes.

You need to login before you can record your own custom course notes.

Registration is easy, and completely free.

Topic 7.6: Risk appetite

Likes people like this topic - including you!

SharesThis topic has been shared 25 times!

Progress2,610 people have passed the quiz

When is a risk not a risk, but something the project can live with?

The terms risk appetite and risk tolerance refer to the degree of uncertainty someone is willing to accept, usually in anticipation of a reward.

For example, fast-tracking a project’s schedule is a risk often taken to achieve the reward created by an earlier completion date.

Individuals and groups adopt attitudes towards risk that influence the way they respond.

These risk attitudes are driven by perception, tolerances, and other biases, which should be made explicit wherever possible.

The problem, though, is that organisations and stakeholders all have varying degrees of risk that they are willing to accept.

Complicating this further, projects are, by their very nature, riskier undertakings than business-as-usual; therefore the default risk settings of an organisation need to be adjusted to accommodate the risk / reward trade-off introduced by projects.

A consistent approach to risk should therefore be developed for each project or program of work, and communication about risk and its handling should be open and honest.

The probability / impact matrix is a popular risk management tool that is common to both projects and business-as-usual.

Although it is commonly used as a ready-reckoner for calculating a risk event score (as we did in the last topic), its more important function is to set the organisationally-agreed risk thresholds for each project.

In this example, the risk thresholds for the project are set at low, medium and high, where any risk with a rating from 8-15 is considered to be a medium risk, and risks scoring above or below that band would be high or low, respectively.

So continuing our previous example, with a score of 12, damaging an iPad would be considered a medium risk; whereas landing Ryan Gosling only rated a 5, and would be considered lower priority opportunity.

Just calling a risk low, medium or high adds nothing to the project unless there is an action linked to it.

That is why the response at each threshold needs to be clearly defined and consistently applied.

The following table illustrates this:

For this project, high risks require immediate action.

We must insert something into our project plan that says we will do X to ensure the risk either does not occur, is less likely to occur, or if it does occur, doesn’t impact us as badly as originally foreseen.

This necessarily involves creating a new task or group of tasks in our WBS, each of which needs to be costed and similarly inserted into our schedule.

A medium risk, on the other hand, requires us to establish a contingency.

contingency is an action that is only exercised if the risk eventuates (becomes an issue).

For example, because our iPad might be damaged, we can set aside the price of a replacement iPad in our budget so that we have the money available to purchase a new one, if required.

The float in your schedule can also be used as a contingency, if required.

Because you can set aside either time or money as a contingency, the schedule and budget need to be updated accordingly.

We will discuss contingency planning in much greater detail shortly.

You should also monitor this risk, to see if the risk does materialise or its circumstances change.

The document we use to manage this is called a risk register – again, we will discuss this in more detail soon.

Finally, a low risk is one that we accept.

In doing so we acknowledge and monitor the risk in our register, but do not take any action or allocate any allowances to it unless circumstances change so as to escalate it to a higher threat level.

With the finite time and scarce resources available to projects, we do not have the luxury of fully treating every little risk as you might do in an operational setting.

That said, it is important that you carefully set your thresholds and related actions at levels that align to the expectations of stakeholders and the risk appetite of your organisation.