Okay, let's have a look at
risk management in practice

And what I want to do
is to start with some basic concepts

then focus on TWO difficult areas
in the risk process

So, I guess if I asked you
to define the word 'risk'

you would have some idea
of what it meant

We might not have a formal definition
that we could quote,

but we all have something in our minds
when we hear the word 'risk'

This is what we think,
and maybe you think of things like this

Maybe you feel like this little guy,
facing some big ugly challenge

that you know is just going to
squash you flat.

Maybe you feel like this guy.

This is a real job in North Korea,

and his job is to hold the target
for other people to shoot at

Sometimes project managers
have the target here

We feel like everybody is shooting at us
in our job

Or maybe you just know there's something
nasty out there, waiting to get you

And maybe that's what you think of
when you think of the word 'risk'

Well that's partly true
but it's not the whole truth.

Risk is not the same
as uncertainty.

Risk is related to uncertainty
but they're different.

So all risks are uncertain
but not all uncertainties are risks.

If you have a risk register
or a risk list,

you don't have a million items in it,
or you shouldn't.

You don't even probably have
a thousand items in it,

you have a smaller number.

Although there are millions
of uncertainties in the world.

So how do we decide which uncertainties
we're going to call 'risk'?

And write them down 
and put them in our risk register

and decide to do something about them.

Clearly 'risk' is a subset
of uncertainties, but which subset?

How do you know?

I think it's very simple to separate
risk and uncertainty.

And I use 3 English words,

these words here,
"risk is uncertainty that matters."

Because most of the
uncertainties in the world don't matter.

We don't care if it's going to rain
in London tomorrow afternoon.

It might, it might not.
It's irrelevant, it doesn't matter.

We don't care what the 
exchange rate will be

if it's between the Russian Ruble 
and the Chinese Yen in 2020.

It doesn't matter to us.

But there are things on our projects,

and things in our families,

and things in our country,

which are uncertain which do matter to us.

If it's an uncertainty that matters, 
it's a risk.

So here's another question,
how do you know what matters?

In your projects, 
what are the things that matter?

The things that matter in our projects
are our objectives.

So we must always connect uncertainty
with objectives,

in order to find the risks.

And if we look at 
some definitions of risk,

this is the ISO standard that I mentioned,

it connects those words very simply;

Risk is the effect of uncertainty
on objectives.

And we might look at another definition
from the UK,

from our association 
for project management,

it says the same thing that risk
is an uncertain event

or a set of circumstances, 
which is uncertain,

but it matters because should it occur,

it will have an effect 
on achievement of objectives.

Uncertainty that matters.

So we should be looking 
in our risk register for two things:

"Is it uncertain?" We don't want 
problems in our risk register.

We don't want issues in the risk register.

We don't want constraints or requirements.

These things are certain,
what we want is uncertainties,

something that might happen
or might not happen.

But the other important question for our
risk register is

"Does it matter?"

Which objective would be affected 
if this thing happened?

And then when we want to see
how big the risk is,

we can ask those two questions:

"How uncertain is it,

and how much does it matter?"

And that will tell us how big the risk is.

So, this idea of uncertainty that matters

then develops into
something which is useful

by linking uncertainty to our objectives.

So, we have two dimensions of ‘risk,’

we have an uncertainty dimension and we

have a dimension that 
affects our objectives

In projects, we call
this probability and impact.

We could call them other things,

there are other English

words we could use,
but these

are the ones,
most often, we use.

And I would like to ask you with 
this picture of the mouse.

What effect matters to the mouse?

So first of all, clearly, 
he is in an uncertain situation here.

And he's seen some risks.

His objective is to get the cheese
and stay alive.

And so, one of the risks he has 
identified is a bad thing

that might happen:
he might be killed or injured.

And so, he has been a 
good project manager,

he has put his little helmet on, 
and he is preparing

so that it doesn't happen to him.
So, he doesn't get killed or injured.

Very good.

And there are things in our projects, 
that if they happened

would kill or injure us.

They would waste time,

waste money, damage reputation,

destroy performance,

maybe even injure real people.

And as project managers we have to
see those things and stop them happening.

Protect ourselves in advance.

Avoid them.

Are there any other uncertainties
that matter for the mouse?

Well there is...

the cheese.

There's an uncertainty here which 
matters a great deal.

"Will I get the cheese out of the trap?"

He might, or he might not.

And if he doesn't get the 
cheese out of the trap, he's failed

So he has two uncertainties to manage,

one of them is bad - he might be killed
or injured -

the other is good - he might 
get the cheese.

And what he has to do,

what he has to do is to manage both
of these at the same time.

And as project managers, we have to
do the same thing.

And also we have to do it in the
best possible way -

sometimes there's a better way to get the 
cheese without being killed or injured.

In our projects, we have to stop the 
bad things happening,

but we also have to get the cheese out
of our projects.

"So what does 'cheese' mean,
in your project?"

"What is the 'cheese' in your project?"

'Cheese' means value.

'Cheese' means benefits.

'Cheese' means products and 
services that people want and need.

'Cheese' means customer satisfaction.

'Cheese' is the good stuff 
that we're trying to get

out of our difficult projects.

And if we don't do anything bad -

we don't waste time, we don't 
waste money, we don't damage reputation -

but we don't create value,

we've failed.

If the mouse didn't die but he didn't 
get the cheese, he failed.

If we create benefits, but we waste time 
and waste money and destroy reputation,

we've failed.

And if the mouse gets the cheese
and he's killed,

he's failed.

So we have to do both of these things.

And when we think about risk 
and think about impact,

there are two kinds of impact that matter.

Bad ones, and good ones.

Uncertainties that could hurt the project,

and uncertainties that 
could help the project.

Both of these matter 
and both of these need to be managed.

And we have another word for those.

So, here's the definition of risk from the
Project Management Institute, the PMI,

from the PMBok Guide.

It's the same as the others 
that we've seen:

an uncertain event or condition, 
that if it occurs, affects an objective.

But PMI knows about the mouse. PMI knows 
about the cheese and the traps,

and has added three words 
to the definition of risk here.

It's not the words 'cheese' and 'traps'.

It's the words 'positive or negative'.

What this tells us is that there 
are good risks, as well as bad risks.

And we heard that in one of our 
keynote speeches, earlier this morning.

In the uncertain situation that this 
country faces going forward

with all the changes that there have been,
there are threats.

There are things that could go wrong.

And you need to see those
and address them.

But there are also opportunities.

Uncertain things that might happen
that could be good.

And we also need to see those things,

and to try and proactively 
make them happen.

And that is equally true in our projects,

in our personal lives,

and also at the national level.

And I'll be talking about some of 
those things later on this afternoon

So, PMI has this definition. The other 
standards have something very similar.

The ISO standard, at the bottom here,

says 'risk is the effect of
uncertainty on objectives.'

Note, the effect can be 
positive or negative.

And the APM, Association for Project 
Management in the UK says the same thing.

So we have this new idea,
that risk is a double-sided concept.

And it's the same impression,
the word you have for risk,

we mostly think of bad things.
But it could be used for good things,

as well. Isn't that right?

It's an uncertain word.

And there are good risks as well 
as bad risks.

So in our project 
risk management process,

we should be looking out for the traps
and avoiding them

and protecting ourselves and 
preventing them happening.

But we should also be looking
out for the cheese

and chasing it, and making it
happen proactively,

so we get the maximum
benefit for the minimum cost.

That’s why risk management is so 
important to

project success: because it effects 
our objectives.

It gives us the best possible chance
to achieve our goals.

So how do we do that?

If we think about the risk management
process,

the process has to do a number of things.

If risk is uncertainty that affects
objectives,

we have to know what our objectives are.

Then, we have to identify the
uncertainties.

The uncertainties that would matter to
those objectives.

And remember that they could be good
or bad, threats and opportunities.

That gives us a long list of uncertainties
that matter,

but they don't all matter the same.

So the next thing we have to do is
to prioritize, and ask the question

"How uncertain,
and how much does it matter?"

Then we get a prioritized list of risks.

We know which are the worst threats and
the best opportunities,

so that we do something about it.

Then we plan how to respond.

We think about what would be appropriate
to stop the bad thing happening

and to make the good thing happen.

And having decided, we do it of course.

And then risk is constantly changing 
so we need to come back and do it again,

and see what has changed.

We could express this process as a number
of questions that it's important to ask,

and keep on asking about our project.

In fact, you can use these questions for
anything.

You could use these questions for your
next career move.

You could use these questions for deciding
about your pension.

You could use these questions to decide
how to bring up your children

or to decide on how to invest the nation's
wealth.

These are the questions:

"What are we trying to achieve?"
That's setting objectives.

Then, "what could affect
us in achieving that?"

That's identifying risks.

Then, "when we have a list of risks,
which are the most important ones?"

That's prioritizing at that
assessing the risks.

Then, "what could we do about it?"

Planning our responses and doing it,
implementing the responses.

And then, "did it work and what's changed"
Reviewing the risk.

So if we look at a risk management
process, we could link each step in the

process to one of these questions.

And this is why risk
management is so easy,

because all we're doing is asking and
answering obvious questions.

Anybody who's doing anything important
will ask these questions:

"What am I trying to do?"
"What could affect me?"

"Which are the big ones?"
"What shall I do about it?"

"Did that work?"
"Now what?"

And you could ask those questions every
Monday morning when you drove to work,

or every Saturday morning.

You can ask the question, say

"What am I trying to achieve today?"
"This week?"

"What could affect me and
which are the big ones?"

"What shall I do?"

We can manage risk on a very simple basis,
or we can use this as the structure for

a risk process which is much more complex,
which involves lots of meetings,

and lots of stakeholder groups and
lots of analysis and statistics.

It's the same questions.

So I would like you to remember
two important things.

One is, risk is uncertainty that matters.

And secondly, these questions,
these six questions.

Because that's the heart,
that's the basis of managing risk,

and it really is very, very easy.

Now, in the time that we have, I want to
focus on just two parts of this process,

and then give us the opportunity
to try out some of these things.

The identification step, clearly
very, very important

because if we don't identify the risks,
we can't manage them.

And then planning responses.

Understanding how we can deal with
the uncertainties that we've identified.

So, let's think about these things:
identifying risks.

How do we find all of the risks?

Well, you can't.

You can't find all of the risks because
there are risks that arrive

that we hadn't seen before.

There are emergent risks,
new risks, different risks

and I'll be talking about those
later this afternoon in my speech.

What we want to find are the knowable
risks: the risks that we could find.

We don't want somebody
on our project team who knows a risk

and they're not telling anybody.

So this process is about exposing the
uncertainties that matter,

finding them so we can
do something about them.

And there are lots of techniques,

brainstorming, workshops, check lists,

testing our assumptions and so on.

But I would like to answer a 
bigger question,

a different question from techniques.

And it's the question, "are we 
finding the real risks?"

When you go to a risk workshop and you
write things in your risk register,

are they really the uncertainties that 
matter for your project?

Are these really the things that could 
drive you off track or really help you?

Or are they just the obvious things?

Where all projects have problems with 
requirements,

with resources, with testing. 
These are things that

always come up, and we have processes 
to deal with them.

But are they the real risks?

I would like to suggest to you that often
in our risk registers

we confuse real risks with other things.

Often, we confuse risks with their causes,
where does the risk come from?

Or we confuse risk with their effects,
what do they do if they happen?

But risks are uncertainties that matter.

They are not causes or effects.

So causes are things that are true.

This is true that the project 
is difficult,

it is true that we do not have enough
people on the project.

it is true that the customer hasn't 
signed the contract yet.

These are not risks, they are facts.

They might be issues.

They might be problems, but they are 
not risks because they are not uncertain.

And a lot of people write these
things in our risk register.

"We don't have enough time 
for this project."

"It’s a risk!"

No, it’s a problem.

Sometimes we confuse risks
with their effects.

There could be an accident,
we could be late.

those are not risks either,
they are the effects of risks,

how do you manage, we could be late?
If your late, it’s too late.

What we want to know is,
why might you be late?

What unplanned thing could happen
that would result in you being late?

So, risks sit between causes and effects.

We can’t manage causes because 
they're here now, they're facts.

We don't want to manage effects
because they may never happen.

What we can manage is risks
that sit in the middle

because they haven't happened yet.

So, risk management has 
to separate risks from

their causes and risks from
their effects.

And I find looking at hundreds of
risk registers all around the world.

I've worked in 48 different
countries, every continent, every culture.

Uh, not the Antarctic, it’s too cold.
Um, but nearly every continent.

And over half of the stuff in risk
registers are causes or effects.

Over half.

So the things we are trying to
manage in the risk register

are not risks and then 
people are surprised that it doesn't work.

So how do we separate cause, risk, and
effect. Here is a little test.

And these statements are
written in your notes.

Or you can just think as we go.

Each of these statements and they are
all very simple is one of these things.

A cause is something that is true today.

A risk is an uncertainty that might,
or might not happen.

The effect is why it matters
to our objective.

Okay? So you have to
think what these are.

The project is based in a 
third-world country.

Cause? Risk? Or effect? 
What do you think?

Cause! Very good.

So, this is a fact, there might be 
uncertainties that come out of this fact.

So we may not get the resources we need,
there may be security concerns.

We may not get paid. These are 
uncertainties that come from this fact.

Interest rates might go down.

It's a risk.

Or they could stay the same or
they could go up.

And we could go over budget.

It's an effect.

So, a million things could
take you over budget,

maybe interest rates is one of them.

Okay? They were easy. 
How about this?

The weather might be better than usual.

So risk could be the same or worse.

It would be a bad thing if you
were selling umbrellas.

It would be a good thing if you
were selling ice cream.

It depends what your project is.

Um, I'm allergic to prawns.

It's a cause, it's a fact.

What is the risk that comes from
this fact, this cause?

You think maybe I could be sick?

I could have a reaction. 
I could be very ill. I could die.

All of those things are effects. 
Aren’t they?

But if something happens 
that I didn't plan,

because I am allergic something might
happen that makes me sick.

What's the something?

I might eat prawns without knowing.

So then I check, are there prawns in this?
You know I avoid things with prawn in them

I manage the risk and not the effect.
And not the cause.

Okay, we have got to use a new technique,
an unproven technique.

It's a fact, it's a requirement,
we have to do it.

we might introduce design errors but it 
just is a fact.

A requirement of our project.

The contractor may not deliver on
time is a risk.

Um, this is going too fast.

It might not work for some reason.

You saw the color, it's an effect.

Okay, I will go more slowly. Uh,
we don't have enough people.

It's a cause, yes. And lastly,
there's a risk that we'll be late.

Hmm...mm. 
It's an effect, is it?

Because we want to know what is the
risk that we'll be late.

Being late is an effect.

So apart from the prawns, all of the blue
and green things we see in risk registers.

The project environment, new technology,
lack of resources, or going over budget.

Lack of performance, delivering late. 
These are not risks.

These are causes or effects.

And if we looked at a real risk register 
and this is written in your notes for you

If you want to do this afterward,
we could do another exercise

In fact, the next page of the notes,
if you turn over the page

has these written a bit larger for you

English only I'm afraid.

We'll have to do something about that.

Um. You could just try this little 
exercise on a real risk register

This is one of my clients, I asked 
them for their top 10 risks.

This is what they gave me.

They're not risks. They're all sorts of
things mixed up.

Really, you should do this on your 
risk register.

But let me show you what happened
when I did this on their risk register.

I found there was a whole mixture
of things.

So, the current hardware is not fast
enough to support testing. That's a fact.

It's a cause.

This means that we may be unable 
to test performance

until production hardware is used.

That's the risk.

So we have two things in this 
statement.

The next one down is just a fact.

A number of usability issues have
been identified by the supplier.

Okay, so what?

What difference does that make?

Let me color code this for you.
Just to be slightly friendly.

Umm.

But you will have to do it on your own
if you want to try the complete exercise.

Umm. There is a whole range of different
things in this so-called risk register.

And I would expect that yours is the same.

That you'll have things in your risk 
register that are just pure facts.

Or things that are a mixture of risks 
and other things

Now, there are two in this list that I 
think are particularly interesting.

It's this one and this one.
They have all three colors in them.

Because they have a cause and a risk 
and an effect.

So, let take this one. The team 
does not have a documented design.

For this function. That's a fact.

So what?

Well, there's the risk 
that the architecture

may not support 
the required functionality.

That might happen because we don't have 
a documented design.

Why do we care about that?

If that happens, it results in the
requirements not being met.

or a higher number of defects.

That hits our performance objective
and our quality objective.

So, now we have three things,
we know what the risk is.

The risk is that the architecture might 
not support the functionality.

We know why that's happening,
because we don't have a documented design.

And we know how it could affect the 
project in not meeting the requirements,

or delivering defects.

Those are really useful things to know.

And it will be helpful if every risk 
description had those three things in it.

And, so what we recommend is
a structured description of risk

that has three parts to it.

That says "as a result of" some fact,
a cause. Then, an uncertainty might occur.

It might not, but it might.

And if it did, it would be a risk.

and if that thing actually happened,
it would lead to

An affect on the objectives

And we recommend and PMI recommends
and the ISO standard recommends

and best practice guidelines recommend.

But you describe your risk in these 
three stages.

What do we know, what uncertainty does
that gives us, and why does it matter?

And then we can use it to help us
manage the risk.

In English, we have definite words 
to describe facts

This is true. This has happened. 
This does occur.

We have uncertain words to describe the
risk. It might or it might not

It's possible.

And then we have conditional words that 
say this would follow

if the risk occurred.

Maybe your language is a little different.

But we can use the language 
to help us perhaps.

So one of the things
I'd like us to try,

in the short exercise we're
going to do in a moment,

is to try describing risks
in that three part way.

What do we know?

What uncertainty does it give us?

And why does that matter 
to our objectives?

And I would recommend that you
try that for your own

real risk register on your project, and
see what difference it makes.

You might be surprised.

Now, let's think about the
next question, which is not,

Well, there is another question.

"How do we prioritize them?"

But the one I want to focus on is,
"What could we do

about the risks that we've identified?'"

Planning risk responses.

Here are the questions
we need to ask.

"What are we going to do based on
the risk?"

How manageable it is.

How bad or good it might be
if we left it alone

impacts the variety.

Whether we have the people
and the equipment of the skills

to deal with it.

A resource availability

and cost effectiveness.

Can we spend a small amount
to save a big amount?

We don't want to spend a big amount 
to save a small amount.

And the next important question

"who is going to do this?"

What could we do to deal with risk?

Often, people think of four things.

Four different types of things 
we could do to address

uncertainties that matter.

And each of these has a name.

It's a strategy. A strategy to focus
our planning.

To focus our thinking.

And then, once we've focused our thinking
with a strategy, we can develop tactics

to address each individual risk.

So, what are the four things
that most people think of?

The first is risk avoidance.

Is there something we can do to
kill the risk, to remove it altogether?

The second is something we call
risk transfer.

Can we give it away?

Can we get somebody else
to take it away for us?

The third is what we call risk reduction.

Some people call this risk mitigation.

And here, we're trying to make
the risk smaller

so that we could accept it.

And the fourth response after avoid, 
transfer, or reduce

is the one that everyone forgets.

They think if we can't do anything 
about it

we just have to hope and pray and wonder
and wait.

The other response is

to take the risk.

We call that risk acceptance.

To recognize we're taking this risk
and to include it in our baseline

and to monitor it very carefully.

So, you might see those four options as
quite a good set of response strategies.

But there's a problem.

The problem is all these 
things only work for bad risks.

What about opportunities?

We don't want to avoid or 
give away or make smaller

opportunities.

So, how do you respond if you find 
a good thing that might happen

on your project.

Do you just wait and see and hope?

Or is there something active that we 
could do?

Fortunately, there are four response
strategies for opportunities

that match the four response strategies
for threats.

So, here are the bad ones.

Avoid a bad thing.

Give it to someone to take away.

Make it smaller.

Or take the risk.

This is not those things 
I'm trying to achieve.

To remove the uncertainty.

To get somebody else to help.

To change the size of the risk.

Or to include it in our project plan.

We could do all of those four things,

for opportunities.

How do you eliminate uncertainty

from opportunity?

You capture it.

Take up a strategy,

which makes it definitely happen.

In English, we call this "Exploit".

Exploit is the same as avoid.

For avoid, you make the probability
zero.

It can't happen.

For a threat, it's avoid.

For opportunity, exploit.

It's to make the probability 100%

It will happen. It must happen.

So they're aggressive strategies.

You kill the threat, 
you capture the opportunity

It's the same kind of thing.

What could we do, instead of giving away,
transferring a threat?

We want to involve 
somebody else to help us.

We could share the opportunity.

We could ask them 
to come into our project

and be involved with us in a
joint venture

or a subcontract, or a partnership.

Where they help us to achieve this
uncertainy that would help us all?

And we give them some part of the benefit

We share the opportunity

How could we change the size
of an opportunity?

We don't want to reduce it,
we want to enhance it.

We want to grow it,
we want to make it more likely.

And bigger impact. It's the same idea but
the other way around for the opportunity.

And the last one, if we can't do these
active things, we could just

Accept an opportunity and wait and see
what happens.

But monitor it very closely if there's
nothing else we could do.

So what this slide tells us is that
there's an equal variety

Of potential response times that we can
choose between for our opportunities

Equal to the number that we have threats.

You see, the secret to thinking
about opportunities...

Is to recognize that an opportunity
is the same as a threat.

The only difference is the sign
of the impact.

So a threat has a negative impact,
an opportunity has a positive impact.

Apart from that, they're the same.

They are both uncertainties that matter.

They are both things that might or might
not happen.

But could affect our objectives.

They can both be managed practically.

They both make a difference to the chances
of succeeding on our project.

And that's why risk management should
manage threats and opportunities together

in a single process.

Because they are the same things.

And that may be new thinking to
some of you.

Those of you who always think of risk
as a big ugly thing waiting to squash me.

Or the unknown thing in the future
that's going to hurt me.

There are some like that, and we need to
stop them happening to protect ourselves.

But there are also some very good things
out that which might happen

Which we need to see, and
we need to chase them.

And make them happen. So that our
projects could be more successful.

There is another response strategy
that we might try.

Which is really not recommended, and
just pretending that there are no risks

and hiding away and saying maybe
it will never happen.