"Managing risk in practice" workshop

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 a 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, 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 are 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 is
just a fact, a requirement of our project.

The contractor may not deliver on
time is a risk.

Um, this is going to 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 is a risk we will 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.