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. The way the bad thing
Make it smaller.
This is not those things I'm trying to
Achieve.
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.