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 for
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.
We really don't recommend this at all.
In fact, it's probably true that ostriches
don't bury their heads in the sand.
It's just the way that the sand dunes
kind of look and it's just a pretend story
And sadly for project managers,
it's not a pretend story.
We hide our heads and we pretend
there are no risks.
And then we get surprised.
Well, we can do better than that.
So, let me just finish here just to say
we do need to do something about this
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 for 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.
Está bien, echemos un vistazo
gestión de riesgos en la práctica
Y lo que quiero hacer
es comenzar con algunos conceptos básicos
luego enfócate en DOS áreas difíciles
en el proceso de riesgo
Entonces, supongo que si te preguntara
para definir la palabra 'riesgo'
tendrías alguna idea
de lo que significa
Puede que no tengamos una
definición que podríamos citar,
pero todos tenemos algo en nuestra
mente al escuchar la palabra 'riesgo'
Esto es lo que pensamos
y tal vez pienses en cosas como esta
Tal vez te sientes así de pequeño,
enfrentando un gran desafío feo
que sabes que
sólo va aplastarte.
Quizás te sientas como este chico.
Esto es un trabajo
real en Corea del Norte,
y su trabajo es sujetar el objetivo
para que otras personas disparen
A veces los gerentes de
proyecto tiene el objetivo aquí
Sentimos que todo el
mundo nos dispara en el trabajo
O tal vez no sepas que hay algo
feo ahí afuera, esperando atraparte
Y tal vez eso es lo que pasa
cuando piensas en la palabra 'riesgo'
Bueno, eso es en parte
cierto pero no es toda la verdad.
El riesgo no es lo
mismo que la duda.
El riesgo está relacionado con
la duda, pero son diferentes.
Todos los riesgos son inciertos,
mas no todas las dudas son riesgos.
Si tiene un registro
o una lista de riesgos,
no tiene un millón de
elementos, o no debería.
Probablemente ni siquiera
tenga mil elementos en él,
tienes un número menor.
Aunque hay millones
de incertidumbres en el mundo.
Entonces, ¿Cómo decidimos
qué incertidumbres llamamos "riesgo"?
Y anótalos en el registro de riesgos.
y decide hacer algo al respecto.
Claramente, el 'riesgo' es un subconjunto
de incertidumbres, pero ¿Qué subconjunto?
¿Cómo lo sabes?
Creo que es muy sencillo
separar riesgo e incertidumbre.
Y utilizo 3 palabras en inglés,
"El riesgo es la
incertidumbre que importa".
Porque la mayoría de
las incertidumbres no importan.
No nos importa si va a llover
en Londres mañana por la tarde.
Podría, puede que no.
Es irrelevante, no importa.
No nos importa que
tipo de cambio será
si está entre el rublo
ruso y el yen chino en 2020.
No nos importa.
Pero hay cosas en nuestros proyectos,
y cosas de nuestras familias,
y cosas de nuestro país,
que son inciertos que nos importan.
Si lo que importa es una
incertidumbre, es un riesgo.
Entonces aquí hay otra
pregunta, como sabes lo que importa
En tus proyectos
¿Cuáles son las cosas que importan?
Lo que importa en tus
proyectos son los objetivos.
Por eso siempre debemos conectar
la incertidumbre con los objetivos,
para encontrar los riesgos.
Y si miramos a algunas
definiciones de riesgo,
este es el estándar
ISO que mencioné,
conecta esas palabras
de manera muy simple;
El riesgo es el efecto de la
incertidumbre sobre los objetivos.
Y podríamos mirar otra
definición del Reino Unido,
de nuestra asociación
para la gestión de proyectos,
dice lo mismo que
arriesga es un evento incierto
o un conjunto de
circunstancias, que es incierto,
pero importa porque si ocurriera,
tendrá un efecto
sobre la consecución de objetivos.
Incertidumbre que importa.
Entonces deberíamos estar
mirando en nuestro registro por dos cosas:
"¿Es incierto?" No queremos
problemas en nuestro registro.
No queremos problemas en el registro.
No quiero restricciones ni requisitos.
Estas cosas son ciertas
lo que queremos son incertidumbres,
algo que puede pasar
o puede que no suceda.
Pero la otra pregunta
importante para nuestro registro es
"¿Importa?"
¿Qué objetivo sería
afectado si esto sucediera?
Y cuando queremos
ver qué tan grande es el riesgo,
Nosotros podemos hacer esas dos preguntas:
"¿Qué tan incierto es,
y cuanto importa? "
Y eso nos dirá
qué tan grande es el riesgo.
Entonces, esta idea de
incertidumbre que importa
luego se convierte
en algo que sea útil
vinculando la
incertidumbre a nuestros objetivos.
Entonces, tenemos dos
dimensiones de "riesgo",
una dimensión de incertidumbre y
una dimensión que
afecta nuestros objetivos
En proyectos, llamamos
esta probabilidad e impacto.
Podríamos llamarlos de otras cosas
hay otros ingleses
palabras que
podrían usar, pero
estos son los
que a menudo más usamos.
Y me gustaría preguntarte
con esta imagen del ratón.
¿Qué efecto le importa al ratón?
Entonces, en primer lugar,
se encuentra en una situación incierta.
Y ha visto algunos riesgos.
Su objetivo es
conseguir el queso y sobrevivir.
Y entonces, uno de los
riesgos que ha identificado es malo.
esto podría suceder:
podría morir o resultar herido.
Y entonces, ha sido un
buen director de proyectos,
se ha puesto su pequeño
casco y se está preparando
para que no le pase a él.
Entonces, él no muere ni resulta herido.
Muy bien.
Y hay cosas en nuestros
proyectos, que si pasaran
nos mataría o heriría.
Ellos perderían el tiempo,
desperdiciar dinero, dañar la reputación,
destruir el rendimiento,
tal vez incluso
lastimar a personas reales.
Y como directores de proyecto
tenemos que ver y evitar que sucedan.
Protegernos a nosotros mismos.
Evítalos.
¿Hay otras incertidumbres
que le importa al ratón?
Bueno, hay …
el queso.
Aquí hay una
incertidumbre que importa mucho.
"¿Sacaré el queso de la trampa?"
Podría, o puede que no.
Y si no obtiene
el queso, ha fallado.
Entonces tienes dos
incertidumbres a manejar,
Uno de ellos es malo -
podría ser asesinado o herido -
el otro es bueno -
podría conseguir el queso.
Y lo que tiene que hacer
es gestionar ambos al mismo tiempo.
Y como directores de proyecto,
tenemos que hacer lo mismo.
Y también tenemos
que hacerlo de la mejor manera posible -
a veces hay una mejor manera
para hacerlo sin morir o resultar herido.
En nuestros proyectos, tenemos
que evitar que sucedan cosas malas,
también tenemos que
sacar el queso de nuestros proyectos.
"Entonces, ¿Qué significa
"queso" en tu proyecto? "
"¿Qué es el 'queso' en su proyecto?"
"Queso" significa valor.
"Queso" significa beneficios.
"Queso" significa productos y
servicios que se quiere y necesita.
"Queso" significa
satisfacción del cliente.
'Queso' es lo bueno
que tratamos de conseguir
de nuestros proyectos difíciles.
Y si no hacemos nada malo -
no desperdiciamos el tiempo y
el dinero, no dañamos la reputación -
pero nosotros no creamos valor,
nosotros
hemos fallado.
Si el ratón no murió pero
no consiguió el queso, fracasó.
Si creamos beneficios, pero perdemos
tiempo y dinero, destruimos la reputación,
hemos fallado.
Y si el ratón se lleva
el queso y lo matan,
ha fallado.
Entonces tenemos
que hacer ambas cosas.
Y cuando pensamos en
el riesgo y en el impacto,
hay dos tipos de
impacto que importan.
Los malos y los buenos.
Incertidumbres que
podría dañar el proyecto,
e incertidumbres que
podría ayudar al proyecto.
Ambos importan
y necesitan ser manejados.
Y tenemos otra palabra para esos.
Entonces, aquí está la definición
del Project Management Institute (PMI),
de la Guía PMBok.
Es lo mismo que
los otros han visto:
un evento o condición incierta,
que si ocurre, afecta un objetivo.
Pero PMI sabe sobre el ratón.
PMI sabe sobre el queso y las trampas,
y ha agregado tres palabras
a la definición de riesgo aquí.
No son las palabras "queso" y "trampas".
Son las palabras 'positivo o negativo'.
Lo que esto nos dice es que hay
son buenos riesgos, así como malos riesgos.
Y lo oímos en uno de nuestros
discursos de apertura, esta mañana.
En la situación incierta de que este
caras de países en el futuro
con todos los cambios que ha habido,
hay amenazas.
Hay cosas que pueden salir mal.
Y necesitas ver esos
y abordarlos.
Pero también hay oportunidades.
Cosas inciertas que podrían suceder
eso podría ser bueno.
Y también necesitamos ver esas cosas,
e intentarlo de forma proactiva
hazlos realidad.
Y eso es igualmente cierto en nuestros proyectos,
en nuestra vida personal,
y también a nivel nacional.
Y hablaré sobre algunos de
esas cosas más tarde esta tarde
Entonces, PMI tiene esta definición. El otro
Los estándares tienen algo muy similar.
El estándar ISO, en la parte inferior aquí,
dice que el riesgo es el efecto de
incertidumbre sobre los objetivos '.
Nota, el efecto puede ser
positivo o negativo.
Y la APM, Asociación para el Proyecto
La dirección en el Reino Unido dice lo mismo.
Entonces tenemos esta nueva idea,
ese riesgo es un concepto de doble cara.
Y es la misma impresión
la palabra que tienes por riesgo,
principalmente pensamos en cosas malas.
Pero podría usarse para cosas buenas,
también. ¿No es eso cierto?
Es una palabra incierta.
Y también hay buenos riesgos
como malos riesgos.
Así que en nuestro proyecto
proceso de gestión de riesgos,
deberíamos estar atentos a las trampas
y evitándolos
y protegernos a nosotros mismos y
evitando que sucedan.
Pero también deberíamos estar mirando
fuera por el queso
y persiguiéndolo, y haciéndolo
suceder de forma proactiva,
para que obtengamos el máximo
beneficio por el costo mínimo.
Por eso la gestión de riesgos es tan
Importante para
éxito del proyecto: porque afecta
nuestros objetivos.
Nos da la mejor oportunidad posible
para lograr nuestras metas.
Entonces, ¿cómo lo hacemos?
Si pensamos en la gestión de riesgos
proceso,
el proceso tiene que hacer una serie de cosas.
Si el riesgo es la incertidumbre que afecta
objetivos
tenemos que saber cuáles son nuestros objetivos.
Luego, tenemos que identificar el
incertidumbres.
Las incertidumbres que serían importantes para esos objetivos.
Y recuerda que pueden ser buenos
o mal, amenazas y oportunidades.
Eso nos da una larga lista de incertidumbres
ese asunto,
pero no todos importan lo mismo.
Entonces, lo siguiente que tenemos que hacer es para priorizar y hacer la pregunta
"Qué tan incierto, y cuanto importa? "
Luego obtenemos una lista priorizada de riesgos.
Sabemos cuáles son las peores amenazas y
las mejores oportunidades,
para que hagamos algo al respecto.
Luego planeamos cómo responder.
Pensamos en lo que sería apropiado
para detener lo malo que pasa.
y hacer que suceda lo bueno.
Y habiendo decidido, lo hacemos por supuesto.
Y luego el riesgo cambia constantemente
así que tenemos que volver y hacerlo de nuevo.
y vea lo que ha cambiado.
Podríamos expresar este proceso como un número de preguntas que es importante hacer
y sigue preguntando por nuestro proyecto.
De hecho, puede utilizar estas preguntas para cualquier cosa.
Puede utilizar estas preguntas para su
próximo movimiento profesional.
Podrías usar estas preguntas para decidir
sobre su pensión.
Podrías usar estas preguntas para decidir
como criar a tus hijos
o para decidir cómo invertir el dinero de la nación.
Estas son las preguntas:
"¿Qué estamos tratando de lograr?"
Eso es establecer objetivos.
Luego, "¿qué podría afectar
nosotros en lograr eso? "
Eso es identificar riesgos.
Luego, "cuando tengamos una lista de riesgos, ¿cuáles son los más importantes? "
Eso es priorizar en eso
evaluar los riesgos.
Luego, "¿qué podemos hacer al respecto?"
Planificando nuestras respuestas y haciéndolo, implementar las respuestas.
Y luego, "¿funcionó y qué cambió?"
Revisando el riesgo.
Entonces, si miramos una gestión de riesgos
proceso, podríamos vincular cada paso en el
proceso a una de estas preguntas.
Y es por eso que el riesgo
la gestión es tan fácil,
porque todo lo que estamos haciendo es pedir y respondiendo preguntas obvias.
Cualquiera que esté haciendo algo importante hará estas preguntas:
"¿Qué estoy tratando de hacer?"
"¿Qué podría afectarme?"
"¿Cuáles son los grandes?"
"¿Qué debo hacer al respecto?"
"¿Funcionó?"
"¿Ahora que?"
Y podrías hacer esas preguntas cada
Lunes por la mañana cuando conducía al trabajo
o todos los sábados por la mañana.
Puede hacer la pregunta, decir
"¿Qué estoy tratando de lograr hoy?"
"¿Esta semana?"
"¿Qué podría afectarme y
¿Cuáles son los grandes? "
"¿Qué debo hacer?"
Podemos gestionar el riesgo de una forma muy sencilla, o podemos usar esto como la estructura para
un proceso de riesgo mucho más complejo,
que implica muchas reuniones,
y muchos grupos de partes interesadas y
mucho análisis y estadísticas.
Son las mismas preguntas.
Entonces me gustaría que recordaras
dos cosas importantes.
Una es que el riesgo es la incertidumbre que importa.
Y en segundo lugar, estas preguntas,
estas seis preguntas.
Porque ese es el corazón,
esa es la base de la gestión de riesgos,
y realmente es muy, muy fácil.
Ahora, en el tiempo que tenemos, quiero
centrarse en solo dos partes de este proceso,
y luego danos la oportunidad
para probar algunas de estas cosas.
El paso de identificación, claramente
muy, muy importante
porque si no identificamos los riesgos,
no podemos gestionarlos.
Y luego planificando respuestas.
Entender cómo podemos lidiar con
las incertidumbres que hemos identificado.
Entonces, pensemos en estas cosas:
identificación de riesgos.
¿Cómo encontramos todos los riesgos?
Bueno, no puedes.
No puede encontrar todos los riesgos porque
hay riesgos que llegan
que no habíamos visto antes.
Hay riesgos emergentes,
nuevos riesgos, diferentes riesgos
y estaré hablando de esos
más tarde esta tarde en mi discurso.
Lo que queremos encontrar es lo conocible
riesgos: los riesgos que podríamos encontrar.
No queremos a nadie en nuestro equipo de proyecto que conoce un riesgo
y no se lo dicen a nadie.
Entonces este proceso se trata de exponer el
incertidumbres que importan,
encontrarlos para que podamos
haz algo al respecto.
Y hay muchas técnicas,
lluvia de ideas, talleres, listas de verificación,
probando nuestras suposiciones y así sucesivamente.
Pero me gustaría responder a una
pregunta más grande,
una pregunta diferente a las técnicas.
Y es la pregunta, "¿estamos
encontrar los riesgos reales?
Cuando vas a un taller de riesgos y te
escriba cosas en su registro de riesgos,
son realmente las incertidumbres que
¿Importa para su proyecto?
¿Son estas realmente las cosas que podrían
¿te desviará del camino o realmente te ayudará?
¿O son solo las cosas obvias?
Donde todos los proyectos tienen problemas con requisitos
con recursos, con pruebas.
Estas son cosas que
siempre surgen, y tenemos procesos
para lidiar con ellos.
¿Pero son ellos los riesgos reales?
Me gustaría sugerirle que a menudo
en nuestros registros de riesgos
confundimos los riesgos reales con otras cosas.
A menudo, confundimos los riesgos con sus causas, de donde viene el riesgo?
O confundimos riesgo con sus efectos,
¿Qué hacen si suceden?
Pero los riesgos son incertidumbres que importan.
No son causas ni efectos.
Así que las causas son cosas que son verdaderas.
Esto es cierto que el proyecto
es difícil,
es cierto que no tenemos suficiente
personas en el proyecto.
es cierto que el cliente no
firmado el contrato todavía.
Estos no son riesgos, son hechos.
Pueden ser problemas.
Pueden ser problemas, pero son
no riesgos porque no son inciertos.
Y mucha gente escribe estos
cosas en nuestro registro de riesgos.
"No tenemos suficiente tiempo
para este proyecto."
"¡Es un riesgo!"
No, es un problema.
A veces confundimos riesgos
con sus efectos.
Podría haber un accidente,
podríamos llegar tarde.
esos tampoco son riesgos,
son los efectos de los riesgos,
¿cómo te las arreglas, podríamos llegar tarde? Si llegas tarde, es demasiado tarde.
Lo que queremos saber es
¿Por qué podrías llegar tarde?
¿Qué cosa no planificada podría suceder?
que resultaría en que llegues tarde?
Entonces, los riesgos se ubican entre causas y efectos.
No podemos gestionar las causas porque
están aquí ahora, son hechos.
No queremos gestionar los efectos.
porque es posible que nunca sucedan.
Lo que podemos gestionar son los riesgos
que se sientan en el medio
porque aún no han sucedido.
Entonces, la gestión de riesgos ha
para separar los riesgos de
sus causas y riesgos de
sus efectos.
Y encuentro cientos de
registros de riesgos en todo el mundo.
He trabajado en 48 diferentes
países, todos los continentes, todas las culturas.
Eh, la Antártida no, hace demasiado frío.
Um, pero casi todos los continentes.
y más de la mitad de las cosas en riesgo
los registros son causas o efectos.
Más de la mitad.
Así que las cosas que estamos intentando
gestionar en el registro de riesgos
no son riesgos y luego la gente se sorprende de que no funcione.
Entonces, ¿cómo separamos causa, riesgo y
efecto. Aquí hay una pequeña prueba.
Y estas declaraciones son
escrito en sus notas.
O simplemente puede pensar sobre la marcha.
Cada una de estas declaraciones y son
todo muy simple es una de estas cosas.
Una causa es algo que es cierto hoy.
Un riesgo es una incertidumbre que podría,
o puede que no suceda.
El efecto es por lo que importa
a nuestro objetivo.
¿De acuerdo? Entonces tienes que
piensa cuáles son estos.
El proyecto se basa en un
pais tercermundista.
¿Causa? ¿Riesgo? ¿O efecto?
¿Qué piensas?
¡Causa! Muy bien.
Entonces, esto es un hecho, podría haber
incertidumbres que surgen de este hecho.
Por lo tanto, es posible que no obtengamos los recursos que necesitamos, puede haber problemas de seguridad.
Puede que no nos paguen. Estos son
incertidumbres que provienen de este hecho.
Las tasas de interés podrían bajar.
Es un riesgo.
O podrían permanecer igual o
podrían subir.
Y podríamos exceder el presupuesto.
Es un efecto.
Entonces, un millón de cosas podrían
llevarlo por encima del presupuesto,
tal vez las tasas de interés sean una de ellas.
¿Está bien? Fueron fáciles. ¿Qué tal esto?
El tiempo puede ser mejor de lo habitual.
Entonces, el riesgo podría ser el mismo o peor.
Sería malo si
vendían paraguas.
Sería bueno que
vendían helados.
Depende de cuál sea tu proyecto.
Um, soy alérgico a las gambas.
Es una causa, es un hecho.
¿Cuál es el riesgo que proviene de
este hecho, esta causa?
¿Crees que tal vez podría estar enfermo?
Podría tener una reacción.
Podría estar muy enfermo. Yo podría morir.
Todas esas cosas son efectos.
¿No es así?
Pero si pasa algo que no planifiqué,
porque soy alérgico, algo podría
Sucede que me enferma.
¿Qué es el algo?
Podría comer langostinos sin saberlo.
Entonces reviso, ¿hay langostinos en esto?
Sabes que evito las cosas con langostinos
Yo manejo el riesgo y no el efecto.
Y no la causa.
Está bien, tenemos que usar una nueva técnica,
una técnica no probada.
Es un hecho, es un requisito,
tenemos que hacerlo.
podríamos introducir errores de diseño, pero
solo es un hecho.
Un requisito de nuestro proyecto.
El contratista no puede entregar el
el tiempo es un riesgo.
Um, esto va demasiado rápido.
Puede que no funcione por alguna razón.
Viste el color, es un efecto.
Está bien, iré más despacio. Oh,
no tenemos suficiente gente.
Es una causa, sí. Y por último,
existe el riesgo de que lleguemos tarde.
Hmm ... mm. Es un efecto, ¿verdad?
Porque queremos saber cuál es el
riesgo de que lleguemos tarde.
Llegar tarde es un efecto.
Así que, aparte de las gambas, todo el azul
y cosas verdes que vemos en los registros de riesgos.
El entorno del proyecto, nueva tecnología,
falta de recursos o sobrepasar el presupuesto.
Falta de rendimiento, entrega tarde.
Estos no son riesgos.
Estas son causas o efectos.
Y si miráramos un registro de riesgo real
y esto está escrito en tus notas para ti
Si desea hacer esto después,
podríamos hacer otro ejercicio
De hecho, la siguiente página de las notas,
si le das la vuelta a la página
¿tiene esto escrito un poco más grande para ti?
Solo en inglés, me temo.
Tendremos que hacer algo al respecto.
Um. Podrías probar este pequeño
ejercicio sobre un registro de riesgo real
Este es uno de mis clientes, le pregunté
ellos por sus 10 riesgos principales.
Esto es lo que me dieron.
No son riesgos. Son todo tipo de
cosas mezcladas.
Realmente, debería hacer esto en su
registro de riesgo.
Pero déjame mostrarte lo que pasó
cuando hice esto en su registro de riesgo.
Encontré que había una mezcla completa
de cosas.
Entonces, el hardware actual no es rápido
suficiente para soportar las pruebas. Es un hecho.
Es una causa.
Esto significa que es posible que no podamos para probar el rendimiento
hasta que se utilice el hardware de producción.
Ese es el riesgo.
Así que tenemos dos cosas en este
declaración.
El siguiente es solo un hecho.
Se han producido varios problemas de usabilidad ha sido identificado por el proveedor.
Está bien, ¿y qué?
¿Qué diferencia hace eso?
Déjame codificar esto por colores.
Solo para ser un poco amigable.
Umm.
Pero tendrás que hacerlo por tu cuenta
si quieres probar el ejercicio completo.
Umm. Hay una amplia gama de diferentes
cosas en este llamado registro de riesgos.
Y esperaría que el tuyo sea el mismo.
Que tendrás cosas en tu riesgo
registro que son solo hechos puros.
O cosas que son una mezcla de riesgos
Y otras cosas
Ahora, hay dos en esta lista que yo
creo que son particularmente interesantes.
Es éste y éste. Tienen los tres colores.
Porque tienen una causa y un riesgo
y un efecto.
Entonces, tomemos este. El equipo
no tiene un diseño documentado.
Para esta función. Es un hecho.
¿Y qué?
Bueno, existe el riesgo que la arquitectura
puede no ser compatible la funcionalidad requerida.
Eso puede pasar porque no tenemos
un diseño documentado.
¿Por qué nos preocupamos por eso?
Si eso sucede, resulta en la
no se cumplen los requisitos.
o un mayor número de defectos.
Eso alcanza nuestro objetivo de desempeño
y nuestro objetivo de calidad.
Entonces, ahora tenemos tres cosas,
sabemos cuál es el riesgo.
El riesgo es que la arquitectura
no es compatible con la funcionalidad.
Sabemos por qué está pasando eso,
porque no tenemos un diseño documentado.
Y sabemos cómo podría afectar al
proyecto en no cumplir con los requisitos,
o entrega de defectos.
Esas son cosas realmente útiles para saber.
Y será útil si todos los riesgos
La descripción tenía esas tres cosas.
Y, entonces, lo que recomendamos es
una descripción estructurada del riesgo
que tiene tres partes.
Eso dice "como resultado de" algún hecho,
una causa. Entonces, puede ocurrir una incertidumbre.
Puede que no, pero podría.
Y si lo hiciera, sería un riesgo.
y si eso sucedió realmente,
conduciría a
Un efecto en los objetivos
Y recomendamos y PMI recomienda
y la norma ISO recomienda
y se recomiendan las guías de buenas prácticas.
Pero usted describe su riesgo en estos
tres etapas.
¿Qué sabemos, qué hace la incertidumbre?
que nos da, y ¿por qué importa?
Y luego podemos usarlo para ayudarnos
gestionar el riesgo.
En inglés, tenemos palabras definidas
para describir hechos
Esto es cierto. Esto ha sucedido.
Esto ocurre.
Tenemos palabras inciertas para describir el
riesgo. Podría o no podría
Es posible.
Y luego tenemos palabras condicionales que
di que esto seguiría
si se produjo el riesgo.
Tal vez su idioma sea un poco diferente.
Pero podemos usar el lenguaje
para ayudarnos quizás.
Así que una de las cosas
Me gustaría que lo intentáramos,
en el breve ejercicio estamos
voy a hacer en un momento,
es intentar describir los riesgos
en ese camino de tres partes.
¿Qué sabemos?
¿Qué incertidumbre nos da?
¿Y por qué importa eso?
a nuestros objetivos?
Y te recomendaría
prueba eso por tu cuenta
registro de riesgo real en su proyecto, y
vea la diferencia que hace.
Puede que se sorprenda.
Ahora, pensemos en el
siguiente pregunta, que no lo es,
Bueno, hay otra pregunta.
"¿Cómo les damos prioridad?"
Pero en el que quiero centrarme es,
"Qué podíamos hacer
sobre los riesgos que hemos identificado? '"
Planificación de respuestas al riesgo.
Aquí están las preguntas.
tenemos que preguntar.
"¿Qué vamos a hacer basándonos en
¿el riesgo?"
Qué tan manejable es.
¿Qué tan malo o bueno podría ser?
si lo dejamos solo
impacta la variedad.
Si tenemos la gente
y el equipamiento de las habilidades
para lidiar con eso.
Una disponibilidad de recursos
y rentabilidad.
¿Podemos gastar una pequeña cantidad
para ahorrar una gran cantidad?
No queremos gastar mucho
para ahorrar una pequeña cantidad.
Y la siguiente pregunta importante
"¿quién va a hacer esto?"
¿Qué podríamos hacer para enfrentar el riesgo?
A menudo, la gente piensa en cuatro cosas.
Cuatro tipos diferentes de cosas
podríamos hacer para abordar
incertidumbres que importan.
Y cada uno de estos tiene un nombre.
Es una estrategia. Una estrategia para enfocarse nuestra planificación.
Para enfocar nuestro pensamiento.
Y luego, una vez que hemos enfocado nuestro pensamiento con una estrategia, podemos desarrollar tácticas
para abordar cada riesgo individual.
Entonces, ¿cuáles son las cuatro cosas
que la mayoría de la gente piensa?
El primero es evitar el riesgo.
¿Hay algo que podamos hacer para
matar el riesgo, eliminarlo por completo?
El segundo es algo que llamamos
transferencia de riesgo.
¿Podemos regalarlo?
¿Podemos conseguir a alguien más?
para quitárnoslo?
El tercero es lo que llamamos reducción de riesgos.
Algunas personas llaman a esto mitigación de riesgos.
Y aquí, estamos tratando de hacer
el riesgo menor
para que podamos aceptarlo.
Y la cuarta respuesta después de evitar,
transferir o reducir
es el que todos olvidan.
Piensan que si no podemos hacer nada
sobre eso
solo tenemos que esperar, orar y maravillarnos y espera.
La otra respuesta es
para correr el riesgo.
A eso lo llamamos aceptación del riesgo.
Para reconocer que estamos corriendo este riesgoe incluirlo en nuestra línea de base
y monitorearlo con mucho cuidado.
Por lo tanto, es posible que vea esas cuatro opciones como un buen conjunto de estrategias de respuesta.
Pero hay un problema.
El problema son todos estos las cosas solo funcionan con malos riesgos.
¿Qué pasa con las oportunidades?
No queremos evitar ni
regalar o hacer más pequeñas
oportunidades.
Entonces, ¿cómo respondes si encuentras
algo bueno que puede pasar
en su proyecto.
¿Esperas y ves y esperas?
¿O hay algo activo que
¿podría hacer?
Afortunadamente, hay cuatro respuestas
estrategias para oportunidades
que coinciden con las cuatro estrategias de respuesta por amenazas.
Entonces, aquí están los malos.
Evita algo malo.
Dáselo a alguien para que se lo lleve.
Hazlo más pequeño.
O arriesgarse.
Estas no son esas cosas
Estoy tratando de lograrlo.
Para eliminar la incertidumbre.
Para que alguien más ayude.
Para cambiar el tamaño del riesgo.
O incluirlo en nuestro plan de proyecto.
Podríamos hacer todas esas cuatro cosas,
para oportunidades.
¿Cómo se elimina la incertidumbre?
de la oportunidad?
Tú lo capturas.
Toma una estrategia
lo que hace que definitivamente suceda.
En inglés, lo llamamos "Exploit" (Explotar)
Explotar es lo mismo que evitar.
Para evitar, haces la probabilidad
cero.
No puede suceder.
Para una amenaza, es evitar.
Para aprovechar la oportunidad.
Es hacer que la probabilidad sea del 100%.
Sucederá. Debe suceder.
Entonces son estrategias agresivas.
Matas la amenaza,
tu capturas la oportunidad
Es lo mismo.
¿Qué podríamos hacer, en lugar de regalar,
transfiriendo una amenaza?
Queremos involucrar
alguien más para ayudarnos.
Podríamos compartir la oportunidad.
Podríamos preguntarles
para entrar en nuestro proyecto
y participe con nosotros en una
proyecto conjunto
o un subcontrato, o una sociedad.
Donde nos ayudan a conseguirlo
incertidumbre que nos ayudaría a todos?
Y les damos una parte del beneficio,
compartimos la oportunidad
¿Cómo podríamos cambiar la talla?
de una oportunidad?
No queremos reducirlo
queremos mejorarlo.
Queremos cultivarlo,
queremos hacerlo más probable.
Y mayor impacto. Es la misma idea pero
al revés por la oportunidad.
Y el último, si no podemos hacer estos
cosas activas, podríamos simplemente
Acepta una oportunidad y espera y verás
lo que sucede.
Pero vigílelo muy de cerca si hay
nada más que pudiéramos hacer.
Entonces, lo que esta diapositiva nos dice es que hay una variedad igual
De los tiempos de respuesta potenciales que podemos elegir entre nuestras oportunidades
Igual al número de amenazas que tenemos.
Verás, el secreto para pensar
sobre oportunidades...
Es reconocer que una oportunidad
es lo mismo que una amenaza.
La única diferencia es el signo
del impacto.
Entonces, una amenaza tiene un impacto negativo, una oportunidad tiene un impacto positivo.
Aparte de eso, son iguales.
Ambas son incertidumbres que importan.
Ambas son cosas que podrían o podrían
no sucede.
Pero podría afectar nuestros objetivos.
Ambos pueden manejarse prácticamente.
Ambos marcan la diferencia en las posibilidades de tener éxito en nuestro proyecto.
Y es por eso que la gestión de riesgos debe
gestionar las amenazas y las oportunidades juntos
en un solo proceso.
Porque son las mismas cosas.
Y esa puede ser una nueva forma de pensar para algo de ti.
Los que siempre piensan en el riesgo
como una cosa grande y fea esperando aplastarme.
O lo desconocido en el futuro
eso me va a doler.
Hay algunos así, y necesitamos
evitar que sucedan para protegernos.
Pero también hay algunas cosas muy buenas
fuera de lo que podría pasar
Lo que necesitamos ver, y
tenemos que perseguirlos.
Y haz que sucedan. Para que nuestro
los proyectos podrían tener más éxito.
Hay otra estrategia de respuesta
que podríamos intentar.
Lo que realmente no se recomienda, y
solo fingiendo que no hay riesgos
y esconderse y decir tal vez
nunca va a pasar.
Realmente no recomendamos esto en lo absoluto.
De hecho, probablemente sea cierto que los avestruces no entierres sus cabezas en la arena.
Es la forma en que las dunas de arena
tipo de mirada y es solo una historia fingida
Y lamentablemente para los directores de proyectos, no es una historia fingida.
Escondemos nuestras cabezas y pretendemos no hay riesgos.
Y luego nos sorprende.
Bueno, podemos hacerlo mejor que eso.
Entonces, déjame terminar aquí solo para decir tenemos que hacer algo al respecto.
Oke, mari kita perhatikan managemen resiko
dalam prakteknya.
Dan yang akan saya baahas
adalah memulai dari konsep dasar
lalu fokus pada dua bidang yang sulit
dalam proses resiko.
Saya kira jika saya memintamu
mendefinisikan kata 'resiko'
kamu akan punya beberapa ide
apa maksudnya.
Kita mungkin tidak punya definisi formal
yang bisa dikutip.
Tapi kita semua memikirkan sesuatu
di kepala ketika mendengar 'resiko'
Ini apa yang kita pikirkan,
dan mungkin kamu berpikir seperti ini.
Mungkin kamu merasa seperti orang ini
menghadapi tantangan besar
yang kamu tahu itu akan menghancurkanmu.
Mungkin kamu merasa
seperti orang ini.
Ini adalah pekerjaan sungguhan
di Korea Utara,
dan pekerjaannya adalah memegang target
yang akan ditembak orang lain.
Kadang kadang manager proyek
punya target disini.
Kita merasa seperti orang lain
menembak kita dalam pekerjaan,
Atau mungkin kamu tahu akan ada
sesuatu berbahaya menunggumu,
Dan mungkin itu adalah pa yang kamu
pikirkan ketika mendengak 'resiko'
Itu sebagian benar
tapi tidak benar sepenuhnya,
Resiko tidak sama
dengan ketidak pastian.
Resiko berkaitan dengan ketidak pastian
tapi berbeda,
Semua resiko itu tidak pasti tapi tidak
semua yang tidak pasti adalah resiko,
Jika kamu punya catatan resiko
atau daftar resiko.
Bene, vediamo in concreto
la gestione del rischio.
Intendo iniziare con alcuni
concetti base
poi concentrarmi su DUE punti difficili
del processo del rischio.
Immagino che se vi chiedessi
di definire il "rischio"
avreste qualche idea
del significato.
Potremmo non avere da citare
una definizione formale,
ma quando sentiamo la parola "rischio"
abbiamo tutti qualcosa in mente.
Ecco cosa pensiamo,
e forse anche voi pensate cose del genere.
Magari sentiamo come questo ragazzino,
che affronta una prova così terribile
che sapete vi schiaccerà
del tutto.
O vi sentite come questo ragazzo.
Questo è un lavoro vero in Corea del Nord,
quello di tenere il bersaglio
a cui altri devono sparare
Talvolta i project manager
hanno il bersaglio qui.
Nel lavoro pensiamo che
tutti ci sparino contro.
Forse sapete che lì fuori c'è qualcosa
di brutto, che aspetta voi.
ed è proprio ciò che pensate
quando pensate alla parola "rischio".
Beh, in parte è vero
ma non del tutto.
Il rischio non è uguale
all'incertezza.
È legato all'incertezza,
ma ci sono differenze.
Tutti i rischi sono incerti,
ma non tutte le incertezze sono rischi.
Se avessimo un registro dei rischi
o in elenco di rischi,
non ci sarebbero milioni di voci,
non dovrebbero.
Non ce ne sarebbero
neanche un migliaio,
ma un numero minore.
Anche nel mondo se ci sono
milioni di incertezze.
Allora, come si decide quali incertezze
dovremo chiamare "rischio"?
Scriverle, metterle
nel registro del rischio
e decidere di fare qualcosa.
È ovvio che "rischio" è un sottogruppo
di incertezze, ma quale?
Come si scopre?
Penso che sia molto facile separare
rischio e incertezza.
Uso tre parole,
queste:
"il rischio è l'incertezza che conta".
Perché gran parte delle incertezze
nel mondo non contano.
Non importa se domani pomeriggio
pioverà a Londra.
Dovrebbe, non dovrebbe,
è irrilevante, non conta.
Non importa quali saranno
i tassi di cambio
tra il rublo russo e
lo yen cinese nel 2020.
Per noi non ha importanza.
Ma ci sono delle cose
nei nostro progetti,
e nelle nostre famiglie,
e nel nostro paese,
cose incerte che per noi contano eccome.
Se è un'incertezza che conta,
si tratta di un rischio.
Ecco un'altra domanda,
come sappiamo cosa conta?
Nei vostri progetti,
quali sono le cose che contano?
Le cose importanti nei progetti
sono gli obiettivi.
Perciò bisogna sempre collegare
l'incertezza agli obiettivi,
per individuare i rischi.
Se esaminiamo alcune definizioni
di rischio,
ecco lo standard ISO di cui parlavo,
collega le parole con facilità;
Il rischio è l'effetto dell'incertezza
sugli obiettivi.
Ecco un'altra definizione
dal Regno Unito,
dalla nostra associazione per
project management
dice la stessa cosa: il rischio
è un evento incerto
o una serie incerta di circostanze,
ma conta perché, se accadesse,
avrebbe un effetto sul
raggiungimento degli obiettivi.
L'incertezza che conta.
Dovremmo allora cercare due cose
nel registro dei rischio:
"È incerto?" Non vogliamo problemi
nel registro del rischio.
Non ci vogliamo questioni.
Non ci vogliamo limiti né obblighi.
Queste cose sono certe,
noi vogliamo le incertezze,
qualcosa che potrebbe accadere
oppure no.
L'altra domanda importante per il
registro del rischio è:
"È importante"?
Se accadesse questo,
quali obiettivi ne risentirebbero?
A allora, quando vediamo
quanto il rischio è grosso,
possiamo farci due domande:
"Quanto è incerto"
"e quanto conta?"
Questo ci darà l'entità del rischio.
Questa idea dell'incertezza che conta
poi si evolve in qualcosa di utile
collegando l'incertezza agli obiettivi.
Abbiamo due dimensioni di 'rischio',
una dimensione dell'incertezza e
una dimensione che influisce
sugli obiettivi.
Nei progetti, si chiamano
probabilità e impatto,
potremmo chiamarli diversamente,
potremmo usare
altre parole, ma queste
sono le più utilizzate.
Vorrei chiedervi con questa
immagine del topo.
Quale effetto conta per il topo?
Prima di tutto, è ovvio,
si tratta di una situazione incerta.
E lui ha notato dei rischi.
Il suo obiettivo è prendere il formaggio
e rimanere vivo.
Quindi, uno dei rischi identificati
è che potrebbe succedere
qualcosa di brutto:
potrebbe essere ucciso o ferito.
Quindi, si comporta da
bravo project manager,
ha indossato l'elmetto,
e si prepara
per non farlo succedere.
Così non sarà ucciso né ferito.
Benissimo.
Ci sono cose nei progetti,
che, se succedessero,
potremmo morire
o ferirci.
Sprecare tempo,
denaro, danneggiare la reputazione,
distruggere il rendimento,
persino ferire persone vere.
e noi project manager dobbiamo prevedere
tutto questo e non farle accadere.
Innanzitutto proteggere noi stessi.
Evitarli.
Ci sono incertezze importanti per il topo?
Beh, sì...
il formaggio.
Un'incertezza che conta moltissimo.
"Prenderò il formaggio dalla trappola"?
Potrebbe, oppure no.
Se non lo prendesse
avrebbe fallito.
Deve quindi gestire due incertezze,
una pessima - potrebbe morire o ferirsi-
l'altra positiva - prendere il formaggio.
Ciò che deve fare,
è gestire entrambe
contemporaneamente.
Come project manager, dobbiamo
fare lo stesso.
E dobbiamo farlo nel
modo migliore -
talvolta c'è un modo migliore di prendere
il formaggio senza morire né ferirsi.
Nei progetti, dobbiamo evitare che
accadano brutte cose,
Ma dobbiamo anche ottenere
il formaggio dai progetti.
"Allora cosa significa 'formaggio'
nel tuo progetto"?
"Cos'è il 'formaggio'"?
Il 'formaggio' è il valore.
Il 'formaggio' sono i vantaggi.
Sono i prodotti e i servizi
che la gente vuole e necessita.
Il 'formaggio' è soddisfare i clienti.
Il 'formaggio' è la buona merce
che cerchiamo di
tirare fuori da progetti difficili.
Se non facciamo niente di male -
non sprechiamo tempo, né denaro,
non danneggiamo la reputazione -
ma non creiamo valore,
abbiamo fallito.
Se il topo non muore ma non
prende il formaggio, ha fallito.
Se creiamo vantaggi, ma sprechiamo tempo,
denaro e distruggiamo la reputazione,
abbiamo fallito.
E se il topo prende il formaggio
e muore,
ha fallito.
Quindi dobbiamo fare entrambe le cose.
Quando pensiamo al rischio
e all'impatto,
ci sono due tipi di impatto che contano.
Negativi e positivi.
Incertezze che possono nuocere
al progetto,
e incertezze che lo possono aiutare.
Sono entrambe importanti
e entrambe devono essere gestite.
Per quelle abbiamo un'altra parola.
Ecco la definizione di rischio del
Project Management Institute, il PMI,
dalla guida al Pmbok.
È simile a quelle già viste:
evento o condizione incerta, che,
se verificata, ha effetto su un obiettivo.
Ma la PMI sa del topo. Sa del formaggio
e della trappola,
e ha aggiunto tre parole alla
definizione di rischio.
Non le parole 'formaggio', e 'trappole'.
Sono le parole 'positivo o negativo'.
Questo ci dice che ci sono
rischi buoni e rischi cattivi.
L'abbiamo sentito in altri interventi,
questa mattina.
Nella situazione incerta che questo paese
affronta continuando
con i cambiamenti già iniziati,
ci sono dei pericoli.
Alcune cose possono andare male.
E dovete conoscerle per affrontarle.
Ma ci sono anche delle opportunità.
Potrebbero esserci delle
buone incertezze.
E bisogna individuare anche quelle,
e cercare di adoperarsi per
farle succedere.
È così anche nei nostri progetti.
nelle vite personali,
e anche a livello nazionale.
Parlerò di alcune di questi aspetti
nell'intervento del pomeriggio.
Ecco la definizione del PMI. Gli altri
standard sono davvero molto simili.
Lo standard ISO, qui in basso,
dice: 'Il rischio è l'effetto
di incertezza negli obiettivi'.
Notate, l'effetto può essere
positivo o negativo.
L'APM, Associazione Project Management
del Regno Unito dice lo stesso.
Abbiamo quindi questa idea nuova,
che il rischio è un concetto double face.
L'impressione è la stessa,
il termine che si usa per rischio,
si pensa spesso a cose negative,
ma può indicare anche cose buone.
Non è vero?
È un termine vago.
Ci sono rischi buoni
e rischi cattivi.
Nel nostro progetto
il processo di gestione del rischio,
dovremo cercare le trappole
e evitarle,
proteggerci e impedire che accadano.
Ma dovremmo anche cercare
il formaggio
dargli la caccia e adoperarci per
prenderlo,
per ottenere il massimo
vantaggio con il minimo costo.
Ecco perché la gestione del rischio
è così importante
per il successo del progetto: perché
influenza gli obiettivi.
Ci da le migliori opportunità
di raggiungere gli obiettivi.
Come ci riusciamo?
Se pensiamo al processo di
gestione del rischio,
esso ha a che fare con molti aspetti.
Se il rischio è l'incertezza che
incide sugli obiettivi,
dobbiamo conoscere i nostri obiettivi.
Poi, dobbiamo identificare le
incertezze.
Quelle che potrebbero
influire sugli obiettivi.
E ricordare che potrebbero essere buone
o cattive, minacce e opportunità.
Ciò procura un lungo elenco di incertezze
che contano,
ma non tutte allo stesso modo.
Perciò il prossimo passo è dare
delle priorità, e farsi delle domande:
"Quanto è incerto,
e quanto conta"?
Poi fare una lista di rischi per priorità.
Conoscendo le peggiori minacce e
le opportunità migliori,
in modo da poterle affrontare.
Poi si pianifica come reagire.
Si pensa a cosa sarebbe appropriato
per far cessare le cose cattive
e per far succedere quelle buone.
Una volta deciso, andiamo avanti.
E il rischio muta costantemente
pertanto dovremo farlo di nuovo,
e vedere cosa è cambiato.
potremmo esprimere questo processo come
delle domande che devono essere poste,
e continuare a porle riguardo al progetto.
In effetti, sono domande per
tutti gli usi.
Si possono usare per il prossimo
avanzamento di carriera.
Oppure per decidere
della pensione.
Domande per stabilire come
educare i figli,
o per decidere come investire
la ricchezza del paese.
Ecco le domande:
"Cosa cerchiamo di ottenere"?
Stabilire degli obiettivi.
"Per ottenere questo, cosa
potrebbe influenzarci?"
Identificare i rischi.
poi: "Avendo in mano una lista di rischi,
quali sono i più importanti"?
Dare le priorità
e stabilire i rischi.
"Cosa è possibile fare"?
Pianificare le reazioni e agire,
mettendo in atto le reazioni.
Infine: "Ha funzionato e cosa è cambiato"?
Verificare i rischi.
Se guardiamo al processo della gestione
del rischio, possiamo legare ogni passo
del processo ad una di queste domande.
Ecco perché la gestione
del rischio è così semplice.
Perché non facciamo altro che
fare e rispondere a domande ovvie.
Chiunque facendo qualcosa d'importante
farebbe queste domande:
"Cosa cerco di fare?"
"Come mi condizionerà?"
"Quali sono le più importanti?"
"Cosa dovrei fare io?"
"Ha funzionato?"
"E adesso?"
Puoi farti le stesse domande
andando al lavoro il lunedì mattina,
o tutti i sabato mattina.
Puoi chiederti, ad esempio
"Oggi cosa voglio ottenere?"
"Nella settimana?"
"Cosa può colpirmi e
quali sono le maggiori"?
"Cosa dovrei fare?"
Si può gestire il rischio facilmente,
o usarlo come struttura per
un processo di rischio più complesso,
che comprende molti incontri,
gruppi di stakeholder e
molte analisi e statistiche.
Le domande sono le stesse.
Vorrei quindi che ricordaste
due cose importanti.
Primo, il rischio è l'incertezza
che conta.
Secondo, queste domande,
queste sei domande.
Perché sono il nocciolo,
le basi della gestione del rischio,
una cosa davvero molto, molto facile.
Ora, nel tempo che ci resta, voglio
parlare di due parti del processo,
e dare a tutti noi
l'opportunità di testarle.
Fare l'identificazione, chiaramente
molto importante,
perché se non si identificano i rischi,
non si riesce a gestirli.
E la pianificazione delle reazioni.
Capire come affrontare
le incertezze identificate.
Ecco, iniziamo pensando a questo:
identificare i rischi.
Come individuiamo tutti i rischi?
Beh, non si può.
Non si possono individuare tutti i rischi
perché ce ne sono alcuni che
non si possono prevedere.
Sono i rischi emergenti,
rischi nuovi, diversi
e di questi parlerò più tardi
durante la lezione del pomeriggio.
Adesso vogliamo individuare i rischi
conosciuti: quelli che si possono trovare.
Non vogliamo che ci qualcuno nel
nostro team veda un rischio
ma non lo dica a nessuno.
Perciò questo processo si occupa
delle incertezze che contano,
di individuarle per agire
di conseguenza.
Ci sono molte tecniche,
brainstorming, workshop,
check-list,
testare le ipotesi e così via.
Ma vorrei rispondere a una
domanda importante,
una diversa dalle tecniche.
È la domanda: "Stiamo
trovando i rischi veri"?
Quando vai a un workshop sul rischio
e scrivi cose nell'elenco del rischio,
sono proprio le incertezze che
contano per il tuo progetto?
Sono proprio le cose che possono portare
fuori strada o aiutano davvero?
O solo solo cose banali?
Quando tutti i progetti hanno problemi
con le condizioni,
le risorse, le verifiche.
Sono cose che
vengono sempre fuori, ed esistono
progetti per risolverli.
Ma sono questi i rischi reali?
Vorrei suggerirvi che spesso
nei registri del rischio
confondiamo i rischi reali con altro.
Spesso li confondiamo con le cause,
da dove proviene il rischio?
Oppure con gli effetti che producono,
cosa fanno se accadono?
Ma i rischi sono incertezze che contano.
Non sono né cause, né effetti.
Allora le cause sono cose reali.
È vero che il progetto è difficile,
è vero che sono in pochi
a occuparsi del progetto.
è vero che il cliente non ha
ancora firmato il contratto.
Questi non sono rischi, sono fatti.
Potrebbero essere aspetti.
Potrebbero essere problemi, ma non
rischi perché non sono incerti.
Molti scrivono queste cose nel
registro del rischio.
"Non abbiamo tempo
per il progetto"
"È un rischio!"
No, è un problema.
A volte confondiamo i rischi
con i loro effetti.
Potrebbe esserci un imprevisto,
o un ritardo.
Quelli non sono rischi,
sono gli effetti dei rischi,
come lo gestiamo, il ritardo?
Se sei in ritardo, sei in ritardo.
Noi vogliamo sapere
perché potresti tardare?
Quale evento non pianificato può
provocare il ritardo?
Ecco che i rischi si trovano
tra le cause e gli effetti.
Non possiamo gestire le cause, perché
sono dei fatti, succedono.
Non vogliamo gestire gli effetti
perché possono non esserci.
Ma possiamo gestire i rischi
che si stanno nel mezzo
perché non si sono ancora verificati.
La gestione del rischio deve
separare i rischi dalle
loro cause e dai
loro effetti.
Io esamino centinaia di registri
del rischio in giro per il mondo.
Ho lavorato in 48 paesi, in ogni
continente e cultura.
Beh, non in Antartide, troppo freddo.
Ma in quasi ogni continente.
E oltre la metà delle voci nei
registri del rischio sono cause o effetti.
Oltre la metà.
Perciò ciò che tentiamo di gestire
nel registro del rischio
non sono rischi e la gente
si sorprende che non funzioni.
Allora come separiamo causa, rischio
e effetto. Ecco un test.
Queste affermazioni sono
scritte come note.
O potete pensarci facendolo
Ogni affermazione è semplice
è una di queste cose.
Una causa è una cosa reale oggi.
Un rischio è un'incertezza che potrebbe
verificarsi o no.
L'effetto è il perché conta
per l'obiettivo.
D'accordo? Dovete pensare
a cosa sono.
Il progetto si svolgerà
in un paese del terzo mondo.
Causa? Rischio? O effetto?
Cose ne pensate?
Causa! Ottimo.
È un fatto, da cui potrebbero
derivare incertezze.
Potremmo non avere le risorse necessarie,
o avere problemi di sicurezza.
Forse non ci pagheranno. Sono
incertezze derivanti dal fatto.
I tassi d'interesse potrebbero scendere.
È un rischio.
O rimanere stabili,
oppure salire
Potremmo sforare il budget.
È un effetto.
Miliardi di cose potrebbero
sforare il budget,
una sono i tassi d'interesse.
D'accordo? Erano facili.
E questo?
Il clima potrebbe essere migliore.
Il rischio lo stesso o peggiore.
Pessima cosa se vendeste ombrelli.
Sarebbe un vantaggio
se vendeste gelato.
Dipende dal progetto.
Mm, sono allergico ai gamberi.
È una causa, un fatto.
Quale rischio deriva da
questo fatto, questa causa?
Potrei forse ammalarmi?
Avere una reazione.
Stare molto male. Morire.
Tutti questi sono effetti.
Giusto?
Ma se capita qualcosa
di non pianificato,
poiché sono allergico,
potrei ammalarmi.
Cos'è il cosa?
Forse mangio gamberi senza saperlo.
Allora controllo, qui ci sono gamberi?
Sapete, evito cibi con i gamberi.
Gestisco il rischio, non l'effetto.
Non la causa.
D'accordo, usiamo un'altra tecnica,
una nuova.
È un fatto, è un requisito,
bisogna farlo.
Dobbiamo introdurre errori di scrittura
ma è solo un fatto.
Un obbligo per il progetto.
Il fornitore che non consegna
in tempo è un rischio.
Mm, va troppo veloce.
Potrebbe non funzionare per alcuni motivi.
Vedete il colore, è un effetto.
Bene, andrò più lento. Oh,
non siamo abbastanza.
Sì, è una causa. E, infine,
rischiamo di essere in ritardo.
Mm... È un effetto, giusto?
Perché volete sapere qual è il rischio
se siete in ritardo.
Essere in ritardo è un effetto.
A parte i gamberi, tutte le cose blu
e verdi presenti nei registri del rischio.
L'ambiente del progetto, nuove tecnologie
mancanza di risorse, o sforare il budget.
mancato rendimento, consegna ritardata.
Questi non sono rischi.
Sono cause o effetti.
Se guardiamo un vero registro del rischio
lo avete nel materiale,
se volete farlo dopo,
possiamo fare un altro esercizio.
La pagina seguente,
se girate pagina
sono scritte più in grande,
solo in Inglese, però.
Dovremo provvedere.
Mm. provate questo esercizio
su un vero registro del rischio.
I chiesto a un mio cliente,
i 10 rischi top.
Ecco cosa mi hanno dato.
Non sono rischi. Sono un
misto di tutto.
Dovreste farlo sul serio sul
vostro registro del rischio.
Vi mostro cosa successe quando
lo feci sul loro.
Trovai questo miscuglio di cose.
La macchina odierna non è abbastanza
veloce per le verifiche. È un fatto.
E una causa.
Significa che forse non possiamo
verificare il rendimento
finché si usa l'hardware di produzione.
Quello è il rischio.
Perciò nella dichiarazione
ci sono due cose.
Quella sotto è un fatto.
Il fornitore ha identificato un tot
di aspetti di fruibilità.
Bene, e allora?
Che differenza fa?
Lo codifico con un colore,
per venirvi incontro.
Mm.
Dovrete farlo da soli, se
volete fare tutto l'esercizio.
Mmm. Ci sono molte cose nel cosiddetto
registro del rischio.
E Mi aspetto che i vostri siano simili.
Che abbiate nel registro del rischio
solo semplici fati.
O miscugli di rischi
e altre cose.
Ora, in questa lista ce ne
sono due molto interessanti.
Questo e questo.
Hanno entrambi tre colori.
Perché hanno una causa, un
rischio e un effetto.
Prendiamo questo. Il team non
ha un progetto documentato.
Per la funzione. È un fatto.
E allora?
Beh, c'è il rischio
che la struttura
non supporti
la funzionalità richiesta.
Potrebbe succedere perché non
avete un progetto documentato.
Perché ci preoccupiamo?
Se capita, i requisiti non
vengono rispettati.
o ci sarà un alto numero di difetti.
Ciò si ripercuote sugli obiettivi
di rendimento e qualità.
Ora abbiamo tre cose,
sappiamo cos'è il rischio.
Il rischio è che la struttura
non supporti la funzionalità.
Sappiamo perché succede,
perché non c'è un progetto documentato.
Non raggiungere i requisiti, può avere
un impatto sul progetto,
come fornire dei difetti.
Sono cose utili da sapere.
E se ogni descrizione del rischio
avrà queste cose, vi sarà d'aiuto.
Quindi raccomandiamo
di fare una descrizione del rischio
che comprende tre parti.
Che dica: "a seguito di" un fatto.
una causa. Poi capitano le incertezze.
Potrebbero o anche no.
Se capitassero, sarebbe un rischio.
E in caso potrebbe
incidere sugli obiettivi.
Lo raccomandiamo noi, il PMI, e lo
standard ISO.
E le linee guida per le buone prassi.
Descrivete il rischio in
queste tre tappe.
Cosa sappiamo, che incertezze nascono,
e perché è importante?
Così possiamo usarli per aiutarci
a gestire il rischio.
Ci sono parole precise
per descrivere i fatti.
È vero. È successo.
Capita.
E parole incerte per descrivere il
rischio. Potrebbe, oppure no.
È possibile.
E parole al condizionale
che dicono cosa succederà
se si incorre nel rischio.
Forse ogni lingua è diversa.
Ma forse possiamo usare
il linguaggio per aiutarci.
Vorrei provare, con voi
l'esercizio che faremo tra
un attimo,
descrivere il rischi
in quelle tre parti.
Cosa sappiamo?
Che incertezze provoca?
Perché conta per i
nostri obiettivi?
Raccomando di provare da soli
un registro del rischio del progetto,
e vedete la differenza.
Okej, spójrzmy na zarądzanie ryzykiem w praktyce
Ok, vamos ver o risco da gerencia em pratica.
E o que eu quero fazer e comecar com alguns basicos conceitos
entao focamos em duas areas dificultosas no processo de risco
Entao, eu acho se eu tivesse perguntado a voce para definir a palavra "risco"
Certo, vamos dar uma olhada
em gerenciamento de risco na prática.
E o que quero fazer é começar
com alguns conceitos básicos,
depois focar em duas áreas difíceis
em processo de risco.
Então, acho que se eu pedir para vocês
definirem a palavra 'risco'
vocês teriam alguma ideia
do que significa.
Nós podemos não ter uma definição
formal que possamos citar,
mas todos temos algo em mente
quando ouvimos a palavra 'risco'.
Isto é o que a gente pensa,
e talvez vocês pensem em coisas assim.
Talvez vocês se sintam como esse menino,
enfrentando um desafio grande e difícil
que vocês sabem
que simplesmente vai esmagá-los.
Talvez vocês se sintam
como esse cara.
Esse é um emprego de verdade
na Coreia do Norte
e o trabalho dele é segurar um alvo
para outra pessoa atirar.
Às vezes os gerentes de projetos
tem o alvo aqui.
Sentimos como se todos
estivessem atirando em nós no trabalho.
Ou talvez saibam que tem algo desagradável
lá fora, esperando pra te pegar.
E talvez seja o que vocês pensem
quando pensam na palavra 'risco'.
Bom, isto é parcialmente verdade,
mas não toda a verdade.
Risco não é o mesmo que incerteza.
Risco está relacionado com incerteza,
mas são diferentes.
Todos os riscos são incertezas,
mas nem todas as incertezas são riscos.
Se você tem um registro
ou uma lista de risco,
você não tem um milhão de itens nela
ou não deveria ter.
Você provavelmente nem tem mil itens nela.
Você tem um número menor,
embora haja um milhão
de incertezas no mundo.
Então como decidir quais incertezas
chamaremos de 'risco'?
E escrevê-las e colocá-las
no nosso registro de risco
e decidir fazer algo a respeito delas.
Claramente, 'risco' é um subconjunto
de incertezas, mas qual?
Como você sabe?
Eu acho que é muito simples
separar risco de incerteza
e eu usei três palavras.
Essas palavras aqui.
Risco é 'incerteza que importa'.
Porque a maioria das incertezas
no mundo não importam.
Nós não ligamos se vai chover
em Londres amanhã a tarde.
Pode chover ou não.
É irrelevante, não importa.
Não ligamos qual será a taxa de câmbio
entre o rubro Russo e
o yuan Chinês em 2020.
Não importa para gente.
Mas tem coisas nos nossos projetos,
e coisas em nossas famílias,
e coisas em nosso país,
que são incertos
e que importam para a gente.
Se é uma incerteza que importa,
então é um risco.
Aqui vai outra pergunta.
Como você sabe o que importa?
Nos seus projetos,
quais são as coisas que importam?
O que importa nos nossos projetos
são os nossos objetivos.
Então temos que sempre conectar
incertezas com objetivos
para podermos encontrar os riscos.
E se olharmos algumas
definições de 'risco',
este é o padrão ISO que mencionei,
ele conecta essas palavras
de forma muito simples.
Risco é o efeito da incerteza
sobre os objetivos.
E poderíamos ver outra definição
do Reino Unido,
da Associação para Gerenciamento
de Projetos.
Diz a mesma coisa,
que risco é um evento incerto
ou um conjunto de circunstâncias
que é incerto,
mas é importante, pois se acontecer,
terá um efeito
na realização dos objetivos.
Incertezas que são importantes.
Então devemos procurar por duas coisas
no nosso registro de riscos.
É incerto? Nós não queremos problemas
no nosso registro de risco.
Não queremos complicações
no registro de risco.
Não queremos restrições ou exigências.
Estas coisas são certas.
O que queremos são incertezas,
algo que possa ou não acontecer.
Mas outra questão importante
para o nosso registro de risco é:
isso é importante?
Qual objetivo seria afetado
se isso acontecesse?
E quando quisermos ver
o quão grande o risco é
nós podemos fazer essas duas perguntas:
quão incerto ele é,
e o quanto é importante?
E isso nos dirá o quão grande o risco é.
Então esta ideia
de incertezas que importam
então se desenvolve em algo que é útil
ligando incertezas
aos nossos objetivos.
Então nós temos duas dimensões de 'risco'.
Temos uma dimensão de incerteza
e temos uma dimensão
que afeta nossos objetivos.
Em projetos, chamamos isto
de probabilidade e impacto.
Nós podemos
chamar de outras coisas,
tem outras palavras que podemos usar,
mas estas são as que usamos
frequentemente.
E eu gostaria de perguntar a vocês,
com essa foto do rato.
Qual efeito importa para o rato?
Primeiramente, ele claramente
está em uma situação incerta aqui.
E ele viu alguns riscos.
Seu objetivo é pegar o queijo
e ficar vivo.
Um dos riscos identificados
é algo ruim que pode acontecer.
Ele pode morrer ou se machucar.
E então, ele tem sido
um bom gerente de projetos,
ele colocou seu pequeno capacete
e está se preparando
para que não aconteça com ele,
para que ele não morra ou se machuque.
Muito bem.
E tem coisas nos nossos projetos
que se acontecerem
iria nos matar
ou nos machucar.
Eles vão desperdiçar tempo,
desperdiçar dinheiro,
prejudicar a reputação,
destruir o desempenho,
talvez até machucar pessoas de verdade.
E como gerente de projetos, temos que
ver essas coisas e impedi-las.
Nos proteger com antecedência.
Evitá-las.
Existem outras incertezas
que importam para o rato?
Bom, existe...
o queijo.
Tem uma incerteza aqui que importa muito.
Eu vou conseguir
tirar o queijo da armadilha?
Talvez ele consiga, talvez não.
E se ele não conseguir tirar
o queijo da armadilha,
ele falhou.
Então ele tem duas incertezas
para administrar.
Uma delas é ruim,
ele pode morrer ou se machucar,
e a outra é boa,
ele pode conseguir o queijo.
E o que ele tem que fazer,
o que ele tem que fazer é lidar
com ambas ao mesmo tempo.
E como gerentes de projeto,
nós temos que fazer o mesmo.
E também, devemos fazer
da melhor forma possível.
Às vezes tem um jeito melhor
de pegar o queijo sem ser morto ou ferido.
Nos nossos projetos temos que
parar as coisas ruins acontecendo,
mas também temos que conseguir
o queijo dos nossos projetos.
Então o que significa 'queijo'
no nosso projeto?
Qual é o 'queijo' no seu projeto?
'Queijo' significa valor.
'Queijo' significa benefícios.
'Queijo' significa produtos e serviços
que as pessoas querem e precisam.
'Queijo' significa
satisfação do consumidor.
'Queijo' é a coisa boa que tentamos tirar
dos nossos projetos difíceis.
E se não fizermos nada ruim,
não desperdiçarmos tempo, dinheiro,
não danificarmos a reputação,
mas não criarmos valor, nós falhamos.
Se o rato não morreu, mas não
pegou o queijo, ele falhou.
Se criarmos benefícios, mas gastarmos
tempo e dinheiro e destruirmos a reputação
nós falhamos.
E se o rato pegar o queijo e ser morto,
ele falhou.
Então temos que fazer as duas coisas.
E quando pensamos sobre o risco e impacto,
tem dois tipos de impacto que importam.
Os ruins e os bons.
Incertezas que podem prejudicar o projeto
e incertezas que podem ajudar o projeto.
Ambas importam
e precisam ser administradas.
E temos outra palavra para esses.
Essa é a definição de risco do Instituto
de Gerenciamento de Projeto, o PMI,
do guia do conjunto de conhecimentos
em gerenciamento de projetos.
É o mesmo que os outros que já vimos:
'um evento ou condição incerto,
que se ocorrer, afeta um objetivo'.
Mas o PMI sabe do rato, o PMI
sabe do queijo e das armadilhas,
e adicionou três palavras
à definição de risco aqui.
Não são as palavras 'queijo'
e 'armadilhas'.
São as palavras 'positivo' ou 'negativo'.
Isto nos diz que existem
tanto riscos bons quanto ruins.
E nós ouvimos isso em um dos nossos
importantes discursos hoje de manhã.
Com o cenário incerto que esse país
enfrenta seguir em frente
com todas as mudanças que ocorreram,
existem ameaças.
Existem coisas que podem dar errado.
E você precisa vê-las e direcioná-las.
Mas também existem oportunidades.
Incertezas que podem acontecer,
mas que podem ser boas.
E nós também temos que ver essas coisas,
e tentar e, proativamente,
fazê-las acontecer.
E isso é igualmente verdade
nos nossos projetos,
nas nossas vidas pessoais,
e também em nível nacional.
E eu vou falar um pouco sobre essas coisas
depois no meu discurso nesta tarde.
Então, o PMI tem essa definição.
Os outros padrões dizem algo
muito parecido.
O padrão ISO, aqui embaixo,
diz que 'risco é o efeito da
incerteza nos objetivos'.
Nota: o efeito pode ser
positivo ou negativo.
E a APM, associação para gerenciamento de
projetos, no Reino Unido diz o mesmo.
Então nós temos essa nova ideia de que
o conceito de risco tem dois lados,
E é a mesma coisa em Persa.
A palavra que você tem para risco,
geralmente pensamos em coisas ruins,
mas poderia ser usado para coisas boas
também, não é verdade?
É uma palavra incerta e existem
tantos riscos bons quanto ruins.
Então no nosso processo
de gerenciamento de riscos
nós deveríamos ter cuidado com armadilhas,
e evita-las, nos protegendo e
impedir que aconteçam.
Mas também devemos observar o queijo,
e perseguir, e fazê-lo acontecer
proativamente,
para que consigamos o máximo
de benefícios pelo mínimo custo.
Esse é o motivo do gerenciamento de risco
ser tão importante para
o sucesso do projeto.
Porque ele afeta os nossos objetivos.
Nos dá a melhor chance possível
de alcançarmos os nossos objetivos.
Então como fazemos isso?
Se pensarmos no nosso processo
de gerenciamento de risco,
o processo tem que fazer
uma série de coisas.
Se risco é a incerteza
que afeta objetivos,
nós temos que saber
quais são os nossos objetivos.
Então, nós temos que identificar
nossas incertezas,
as incertezas que importam
para aqueles objetivos,
e lembrem-se que elas
podem ser boas ou ruins,
ameaças e oportunidades.
Isso nos dá uma longa lista de
incertezas que são importantes,
mas elas não são igualmente importantes.
Então o próximo passo que temos que fazer
é priorizar e perguntar o quão incerto
e o quanto é importante?
Então teremos uma lista
priorizada de riscos.
Saberemos quais são as piores
ameaças e as melhores oportunidades,
para que façamos algo a respeito
e então, planejamos como responder.
Nós pensamos sobre o que seria adequado
para impedir que a coisa ruim aconteça,
e fazer a coisa boa acontecer.
E tendo decidido,
nós o fazemos, obviamente.
Mas risco está constantemente mudando,
então temos que voltar e fazer de novo
e ver o que mudou.
Nós podemos representar esse processo
como um número de questões,
que são importantes perguntar
e continuar perguntando,
sobre o nosso projeto.
Na verdade, você pode usar
essas perguntas para qualquer coisa.
Você poderia usar estas perguntas
para o próximo passo na sua carreira.
Você poderia usar estas perguntas
para decidir sobre a sua pensão.
Você poderia usar estas perguntas
para decidir como criar os seus filhos,
ou para decidir em como
investir a riqueza da nação.
Estas são as perguntas.
O que estamos tentando alcançar?
Isto é definir objetivos.
O que pode nos afetar os alcançando?
Isso é identificar os riscos.
Depois, quando tivermos a lista de riscos,
quais são os mais importantes?
Isso é priorizar e avaliar os riscos.
E então, o que podemos fazer a respeito?
Planejar as nossas reações
e implementa-las.
E então, se funcionou e o que
mudou revisando o risco?
Então se olharmos o processo
de gerenciamento de risco,
nós podemos ligar cada etapa
do processo à uma destas perguntas.
E este é motivo de gerenciamento
de risco ser tão fácil.
Porque tudo o que estamos fazendo
é perguntar e responder perguntas óbvias.
Qualquer um que esteja fazendo qualquer
coisa importante faria essas perguntas.
'O que estou tentando fazer?'.
'O que poderia me afetar?'.
'Quais são os maiores?'.
'O que devo fazer a respeito?'.
'Aquilo funcionou?'.
'E agora?'.
E você pode fazer essas perguntas
toda segunda-feira de manhã,
quando você dirige para o trabalho
ou todo sábado de manhã.
Você pode se perguntar: 'o que estou
tentando alcançar hoje, essa semana?'
'O que pode me afetar
e quais são os maiores?'
'O que devo fazer?' Nós podemos lidar
com riscos de forma bem simples.
Ou nós podemos usar como estrutura
para um processo de risco,
o que é muito mais complexo,
que envolve muitas reuniões,
e muitos grupos de partes interessadas,
muitas análises e estatísticas.
São as mesmas perguntas.
Então eu gostaria que vocês
se lembrassem de duas coisas importantes.
A primeira é que risco
é a incerteza que importa.
E a segunda são estas seis perguntas.
Porque esta é a essência, é a base
do gerenciamento de risco.
E realmente é muito, muito fácil.
Agora, com o tempo que temos,
eu gostaria de focar em apenas duas
partes desse processo,
e nos dar a oportunidade de testar
um pouco dessas coisas.
A etapa de identificação,
claramente muito importante,
porque se não identificarmos os riscos,
nós não podemos lidar com eles.
E depois, planejamento de reações,
entender como podemos lidar
com as incertezas que identificamos.
Então vamos pensar nessas coisas.
Identificando riscos. Como encontramos
todos os riscos?
Bem, você não pode.
Você não pode encontrar todos os riscos,
pois existem riscos que aparecem
que nunca vimos antes.
Existem riscos emergentes, riscos novos,
riscos diferentes,
e eu falarei sobre eles mais tarde
no meu discurso.
O que queremos encontrar
são os riscos conhecíveis,
os riscos que poderíamos encontrar.
Nós não queremos alguém
na nossa equipe do projeto,
que saiba um risco e não
conte para ninguém.
Então esse processo é sobre expor
as incertezas que importam,
encontrá-las para que possamos
fazer algo a respeito.
E existem muitas técnicas: brainstorming,
workshops, lista de verificação,
testar nossas premissas
e assim por diante.
Mas eu gostaria de responder
uma pergunta maior,
uma pergunta diferente das técnicas.
E é a pergunta: 'nós estamos encontrando
os verdadeiros riscos?'
Quando vamos a um workshop de risco e você
escreve coisas no seu registro de riscos,
elas realmente são as incertezas
que importam para o seu projeto?
São essas coisas que realmente
vão te desviar do caminho ou te ajudar?
Ou elas são somente as coisas óbvias,
com as quais todos os projetos
tem problemas,
com requerimentos, com recursos,
com testes.
Essas são coisas que sempre aparecem
e nós temos processos para lidar com elas.
Mas são elas os verdadeiros riscos?
Eu gostaria de sugerir que,
frequentemente, no nosso registro de risco
nós confundimos riscos verdadeiros
com outras coisas.
Nós frequentemente confundimos riscos
com suas causas.
De onde vem o risco? Ou confundimos risco
com seus efeitos.
O que eles causam se acontecerem?
Mas riscos são incertezas que importam.
Não são causas ou efeitos.
Então causas, são coisas verdadeiras.
É verdade que o projeto é difícil.
É verdade que não temos pessoas
suficientes no projeto.
É verdade que o cliente
ainda não assinou o contrato.
Isso não são riscos, são fatos.
Eles podem ser complicações,
podem ser problemas,
mas não são riscos, pois não são incertos.
E muitas pessoas escrevem essas coisas
no nosso registro de riscos.
'Nós não temos tempo suficiente
para esse projeto, é um risco'.
Não, é um problema.
Às vezes confundimos riscos
com seus efeitos.
'Poderia haver um acidente,
poderíamos nos atrasar'.
Estes também não são riscos,
são os efeitos dos riscos.
Como você lida com:
'nós poderíamos nos atrasar'?
Se você está atrasado,
é tarde demais.
O que queremos saber
é por que você estaria atrasado?
Que coisa não planejada poderia acontecer
que resultaria no seu atraso?
Então os riscos ficam entre
as causas e os efeitos.
Nós não podemos lidar com as causas,
pois elas estão aqui agora, são fatos.
Nós não queremos lidar com os efeitos,
pois pode ser que nunca aconteçam.
Nós podemos lidar com os riscos, que estão
no meio, pois eles ainda não aconteceram.
Então gerenciamento de risco
tem que separar riscos de suas causas
e riscos de seus efeitos.
E eu encontro, olhando para centenas de
registros de riscos em todo o mundo,
eu trabalhei em 48 países diferentes,
todo continente, toda cultura,
não na Antártica, é muito frio,
mas quase todos os continentes,
e mais da metade das coisas nos registros
de riscos são causas e efeitos.
Mais da metade.
Então as coisas que estamos tentando lidar
no registro de riscos não são riscos,
e então as pessoas ficam surpresas
que não funciona.
Então como separamos
causa, risco e efeito?
Aqui está um pequeno teste.
E essas declarações
estão escritas nas suas notas
ou podemos apenas pensar
conforme avançamos.
Cada uma dessas declarações,
e elas são bem simples,
é uma destas opções.
Uma causa é algo que é verdade hoje.
Um risco é uma incerteza que
pode ou não acontecer.
O efeito é o porquê importa para
o nosso objetivo, certo?
Então vocês precisam pensar
o que elas são.
'O projeto é baseado em
um país de terceiro mundo'.
Causa, risco ou efeito. O que vocês acham?
Causa, muito bem! Este é um fato.
Podem haver incertezas
oriundas desse fato,
podemos não ter os recursos
que precisamos,
pode haver preocupações com segurança,
podemos não ser pagos.
Essas são incertezas
que surgem deste fato.
'Taxas de juros podem cair', é um risco,
ou elas podem se manter ou aumentar
e 'nós poderíamos exceder o orçamento'.
É um efeito. Um milhão de coisas
poderiam exceder o orçamento,
talvez a taxa de juros
seja uma delas, certo? Foram fáceis.
E essa, 'o clima pode estar
melhor que o habitual'?
O risco pode ser o mesmo ou pior.
Seria algo ruim se você
estivesse vendendo guarda-chuvas.
Seria algo bom se você
estivesse vendendo sorvetes.
Então depende de qual é o seu projeto.
'Eu sou alérgico a camarões'.
É uma causa, um fato.
Qual o risco que vem desse fato,
dessa causa?
Talvez eu possa ficar doente?
Possa ter uma reação?
Eu poderia ficar bem ruim, poderia morrer?
Tudo isso são efeitos, certo?
Mas se algo acontecer
porque eu não planejei,
por eu sou alérgico algo pode acontecer
que me deixe doente.
Qual é a coisa que poderia me fazer
comer camarões sem saber?
Então eu verifico se tem camarões nisso,
eu evito coisas que tem camarão.
Eu lido com o risco e não
com o efeito ou a causa.
Certo, 'nós temos usar uma nova técnica',
uma 'técnica não comprovada'.
É um fato. É um requerimento,
temos que fazer.
Podemos apresentar erros de projeto,
mas é apenas um fato,
um requerimento do nosso projeto.
'O contratante pode não entregar
em tempo' é um risco,
- isso está indo mundo rápido -
'pode não funcionar por algum motivo',
- vocês viram a cor, é um defeito.
Certo, eu vou mais devagar -
'nós não temos pessoas suficiente'.
É uma causa, sim. E o último
'tem um risco de que iremos atrasar'.
É um efeito, não é?
Porque teremos saber qual é o risco
de que iremos nos atrasar.
Estar atrasado é um efeito.
Então além dos camarões,
tudo que está em azul e verde
nós vemos em registros de risco.
O ambiente do projeto, nova tecnologia,
falta de recursos,
ou exceder o orçamento,
falta de desempenho, entregar atrasado.
Esses não são riscos,
são causas e efeitos.
E se olharmos para o verdadeiro
registro de risco,
e esses estão escritos
nas notas para vocês
se vocês quiserem fazer isso depois,
nós podemos fazer outro exercício.
Na verdade, na próxima página das notas,
se vocês virarem a página, tem isso
escrito um pouco maior para vocês,
receio que apenas em inglês.
-teremos que fazer algo
a respeito disso Raziel-
vocês poderiam tentar
esse pequeno exercício
em um registro de risco real.
Este é um dos meus clientes.
Eu pedi seus 10 principais riscos
e foi isso que eles me deram.
Não são riscos. São todos
os tipos de coisas misturados.
Na verdade vocês deveriam fazer isso
nos seus registros de risco.
Mas deixe eu lhes mostrar o que aconteceu
quando eu fiz isso no registro deles.
Eu descobri que havia
uma grande mistura de coisas.
'O hardware atual não é rápido
suficiente para suportar testes'.
Isto é um fato. É uma causa.
Isto significa que talvez
não possamos testar o desempenho
até que o hardware de produção
seja utilizado. Esse é o risco.
Então temos duas coisas nessa declaração.
O próximo é apenas um fato.
'Uma série de problemas de usabilidade
foram identificados pelo fornecedor'.
Certo. E daí? Que diferença isso faz?
Deixa eu classificar em cores para vocês,
só pra ser um pouco bonzinho,
mas vocês terão que fazer
por conta própria,
se quiserem tentar o exercício completo.
Tem uma gama de coisas diferentes
neste, assim chamado, registro de risco,
e eu esperaria que o de vocês fosse igual.
Que vocês teriam coisas nos seus registros
que são puramente fatos ou
coisas que são uma mistura
de riscos com outras coisas.
Mas tem duas nesta lista
que eu acho particularmente interessantes.
É esta aqui e esta outra.
Elas têm todas as três cores nelas, porque
têm uma causa, um risco e um efeito.
Então vamos ver esta aqui.
'A equipe não tem um projeto
documentado para essa função'.
Isto é um fato. E daí?
Tem o risco de que o arquitetura não
suporte a funcionalidade exigida,
o que pode acontecer porque
não temos um projeto documentado.
Por que nos importamos com isso?
Se isso acontecer, resulta nas exigências
não serem cumpridas
ou em um maior número de defeitos.
Isto atinge nossos objetivos
de desempenho e qualidade.
Então agora temos três coisas.
Sabemos qual é o risco.
O risco é que a arquitetura pode
não suportar a funcionalidade.
Nós sabemos porque isso está acontecendo,
porque não temos um projeto documentado.
E sabemos como pode afetar o projeto,
não atendendo as exigências
ou entregando defeitos.
Essas são coisas úteis para se saber.
E ajudaria se toda descrição de risco
tivesse essas três coisas nela.
Então o que recomendamos
é uma descrição de risco estruturada
que contenha três partes nela, que diga:
'como resultado de' algum fato, uma causa,
então uma incerteza pode acontecer.
Pode não acontecer, mas pode.
E se acontecesse, seria um risco.
E se isto realmente acontecesse,
levaria a um 'efeito nos objetivos'.
E nós, a PMI, a ISO, e as diretrizes
de melhores práticas recomendamos
que você descreva seu risco
nestes três estágios.
O que sabemos, que incertezas
isso nos dá e por que elas importam?
E então podemos utilizar isto
para nos ajudar a lidar com o risco.
Nós temos palavras definidas
para descrever os fatos:
isso é verdade, isso aconteceu,
isso realmente acontece.
Temos palavras de incerteza
para descrever o risco:
pode ou pode não ser, é possível.
E então temos palavras condicionais
que dizem que isso ocorreria
se o risco acontecesse.
Talvez na sua língua
seja um pouco diferente,
mas talvez possamos usá-la para nos ajudar
Então uma das coisas
que eu gostaria de tentar
nesse curto exercício
que faremos em breve,
é tentar descrever riscos
nessa forma de três partes:
o que sabemos, que incertezas nos dão e
por que importam para os nossos objetivos.
E eu recomendaria que vocês tentassem
nos seus próprios registros
de risco dos seus projetos,
e vejam que diferença isso faz.
Vocês podem se surpreender.
Agora vamos pensar
na próxima pergunta que é,
bom, tem outra questão
que é como os priorizamos,
mas a que eu quero focar é
'o que poderíamos fazer
com os riscos que identificamos?'.
Planejamento de respostas de riscos.
Aqui estão as perguntas
que precisamos fazer.
O que vamos fazer baseado no risco,
o quão manejável ele é,
o quão ruim ou bom ele pode ser
se o ignorarmos, severidade do impacto,
se temos as pessoas, os equipamentos,
as habilidades para lidar com isso,
nossa disponibilidade de recursos,
e custo-efetividade.
Nós podemos gastar um pequeno valor
para salvar um grande valor?
Nós não queremos gastar um
grande valor para salvar um pequeno valor.
E a próxima pergunta importante é:
'quem irá fazer isso?'.
O que poderíamos fazer
para lidar com risco?
Muitas vezes as pessoas
pensam em quatro coisas,
quatro tipos diferentes de coisas
que poderíamos fazer
para direcionar as incertezas
que importam.
E cada uma delas tem um nome.
É uma estratégia.
Uma estratégia para focar nosso
planejamento, nosso pensamento.
E então, quando focamos nosso pensamento
com uma estratégia,
nós podemos desenvolver táticas
para lidar com cada risco individual.
Então quais são as quatro coisas
que a maioria das pessoas pensam?
A primeira é evitar o risco.
Tem alguma coisa que possamos fazer
para eliminar o risco de uma vez?
A segunda é algo que chamamos
de transferir o risco.
Nós podemos dar, podemos arranjar
alguém para tirá-lo para nós?
A terceira é o que chamamos
de redução de riscos.
Algumas pessoas chamam isso
de mitigação de risco.
E aqui estamos tentando reduzir
o risco para que possamos aceitá-lo.
E a quarta resposta depois
de evitar, transferir ou reduzir
é a que todo mundo se esquece.
Eles pensam que se não podemos
fazer nada a respeito,
nós só temos que torcer e rezar,
imaginar e esperar.
A outra resposta é aceitar o risco.
Chamamos isso de aceitação do risco.
É reconhecer que aceitaremos o risco
e adicioná-lo na nossa linha de base,
e monitorá-lo cuidadosamente.
Então vocês devem ver essas quatro opções
como um bom conjunto
de estratégias de respostas.
Mas tem um problema. O problema é que
todas elas só funcionam para riscos ruins.
E quanto as oportunidades?
Nós não queremos evitar, dar
ou diminuir as oportunidades.
Então como vocês respondem
se vocês acharem uma coisa boa
que possa acontecer no seu projeto?
Vocês apenas aguardam, observam e torcem?
Ou tem algo ativo que possamos fazer?
Felizmente, têm quatro estratégias
de resposta para as oportunidades
que correspondem as quatro estratégias
de resposta para ameaças.
Então aqui estão as ruins.
Evitar algo ruim, transferir para alguém,
reduzir ou aceitar o risco.
Isto é o que estas coisas
estão tentando alcançar.
Eliminar a incerteza, arranjar
alguém para ajudar,
mudar o tamanho do risco ou incluí-lo
no plano do nosso projeto.
Nós poderíamos fazer todos estes quatro
itens para as oportunidades.
Como você elimina incerteza
para uma oportunidade?
Você a agarra. Você adota uma estratégia
que a faça acontecer com certeza.
Nós chamamos isso de explorar.
Explorar é o mesmo que evitar.
Para evitar, você faz a probabilidade
ser nula, não pode acontecer.
Para uma ameaça, é evitar.
Para uma oportunidade,
explorar é fazer a probabilidade
de acontecer ser de 100%.
Precisa acontecer.
Então elas são estratégias agressivas.
Você acaba com a ameaça
e agarra a oportunidade.
É o mesmo tipo de coisa.
O que podemos fazer em vez de se desfazer,
transferir uma ameaça?
Nós queremos envolver
alguém para nos ajudar.
Nós poderíamos compartilhar
a oportunidade.
Poderíamos chamá-los para participar
do nosso projeto,
se envolverem conosco
em uma joint venture, um subcontrato
ou uma parceria na qual eles
nos ajudam a alcançar esta incerteza
que ajudaria a todos nós, e nós damos
uma parte do benefício.
Nós compartilhamos
a oportunidade.
Como poderíamos mudar o tamanho
de uma oportunidade?
Nós não queremos reduzi-la,
mas sim realça-la, fazê-la crescer.
Nós queremos torná-la mais provável,
com maior impacto.
É a mesma ideia, mas ao contrário
para oportunidade.
E o última, se não podemos
fazer essas coisas ativas,
nós poderíamos apenas
aceitar a oportunidade,
esperar e ver o que acontece,
mas monitorar bem de perto
caso não haja mais nada
que possamos fazer.
Então, o que esse slide nos diz
é que há uma variedade igual
nos tipos de resposta potencial
que podemos escolher
para nossas oportunidades.
Igual ao número que temos para ameaças.
O segredo de pensar em oportunidades
é reconhecer que uma oportunidade
é o mesmo que uma ameaça.
A única diferença é o sinal do impacto.
Uma ameaça tem um impacto negativo,
uma oportunidade tem um impacto positivo.
Além disso, eles são iguais.
Ambos são incertezas que importam.
Ambos são coisas
que podem ou não acontecer
que podem afetar nossos objetivos.
Ambos podem ser lidados proativamente.
Ambos fazem diferença nas chances
de sucesso do nosso projeto.
E essa é por isso que o gerenciamento
de risco deveria lidar com ameaças
e oportunidades juntos,
em um único processo,
porque eles são as mesmas coisas.
E isso pode ser um pensamento novo
para alguns de vocês.
Para aqueles de vocês
que sempre pensa no risco
como aquela coisa grande, feia,
que está esperando para me esmagar,
ou aquela coisa desconhecida do futuro
que irá me machucar,
existem alguns assim e nós temos
que impedir que aconteçam e nos proteger.
Mas também existem coisas muito boas
lá fora que podem acontecer,
que precisamos ver, persegui-las
e fazer com que aconteçam
para que nossos projetos
possam ter mais sucesso.
Existe uma outra estratégia de resposta
que podemos tentar,
que realmente não é recomendado,
apenas fingir que não há nenhum risco,
se esconder e dizer que
talvez nunca aconteça.
Nós realmente não recomendamos
isso de forma alguma.
Na verdade, provavelmente seja verdade
que avestruzes não enterram
suas cabeças na areia.
É apenas a forma como as dunas
de areia se parecem
e é apenas uma história de faz de conta.
E infelizmente, para gerentes de projeto
não é uma história de faz de conta.
Nós escondemos nossas cabeças,
e fingimos que não há riscos
e nós somos surpreendidos.
Bom, podemos fazer melhor do que isso.
Então deixe-me terminar aqui
apenas para dizer
que nós temos sim
que fazer algo a respeito.
Deve haver uma pessoa que assuma o risco.
Temos que ter certeza de que a pessoa
que assuma responsabilidade
seja uma pessoa
que possa fazer a diferença.
E essa geralmente é a pessoa
que possui o objetivo que seria afetado
se algo acontecesse.
Então a responsabilidade sobre o risco
deve seguir com o impacto do risco.
Então deveríamos colocar as respostas
no plano do projeto
e tratá-las como qualquer outra
atividade do projeto,
algo que devemos fazer
para que o nosso projeto tenha sucesso.
Acho que isso é tudo o que queria dizer
sobre a parte falada da apresentação
do nosso workshop.
E o que eu gostaria de fazer é nos dar
a oportunidade de tentar
um desses exercícios,
o arranjo na sala com as pessoas sentadas
em fileiras dificulta um pouco,
então vocês terão que se movimentar
e conversar com seus vizinhos.
Mas deixe-me lembrá-los dos pontos-chaves
que aprendemos até agora.
Risco é a incerteza que importa.
Isso significa que estamos procurando
coisas que podem não acontecer.
Não estamos procurando problemas,
complicações, restrições, requerimentos,
ou coisas que não gostamos
no nosso projeto.
Estamos procurando
por eventos ou circunstâncias
futuras que podem nunca acontecer,
mas que se acontecerem nos afetariam.
Isto envolve tanto ameaças
como oportunidades, boas e ruins,
e nós deveríamos procurar por ambos.
Eles são importantes
porque afetam nossos objetivos.
Nós precisamos separar nossos riscos
das coisas que as causam
e dos efeitos que causariam.
E podemos usar esta descrição estruturada,
por causa da causa nós podemos
ter um risco que leva ao efeito,
para separar essas três coisas.
Nós podemos ter uma abordagem estruturada
para planejar nossas respostas ao risco,
escolher uma daquelas quatro opções
para ameaças e uma para oportunidade,
garantir que a pessoa certa aja e então,
nós podemos lidar com o risco.
Isto é tudo o que quero dizer nesta parte,
mas darei cinco ou dez minutos
para ver se temos dúvidas
antes de irmos para o exercício.
Então, se a sua pergunta
for em persa, em farsi,
tudo bem, pois tenho minha
tradutora comigo. Então, por favor.
Итак, рассмотрим систему
управления рисками на практике.
Я начну с основных понятий,
а затем сконцентрируюсь на двух
сложных областях управления рисками.
Так если бы я попросил вас
дать определение слову "риск",
полагаю, у вас бы возникло несколько идей
о том, что имеется ввиду.
Мы можем не знать точного определения,
но у всех нас возникают какие-то мысли,
когда мы слышим слово "риск".
Может быть вам приходит в голову
нечто подобное:
Может быть, вы чувствуете то,
что чувствует этот паренек, которому
предстоит столкнуться с большой угрозой,
которая вот-вот размажет по поверхности.
А может быть вы чувствуете то, что
чувствует этот парень.
Это - реально существующая работа
в Северной Корее
и заключается она в том,
чтобы держать людей на прицеле.
Иногда менеджеры проектов
целятся сюда.
Мы чувствуем, как все
стреляют в нас на нашей работе.
Может быть в просто знаете,
что где-то там снаружи
вас ожидает что-то неприятное.
Может быть это и есть то,
о чем вы думаете при слове "риск".
Что ж, отчасти это верно,
но это не вся истина.
Риск - это не то же самое,
что и неопределнность.
Он связан с неопределенностью,
но между ними есть различия.
Так каждый риск является неопределенным,
но не все неопределенности
являются рискми.
Если у вас есть регистр или список рисков,
то в них нет или не должно быть
миллионов наименований.
Там не будет даже и тысячи.
У вас будет какое-нибудь небольшое число.
Несмотря на то, что в мире
существуют миллионы неопределнностей.
Итак, как же определить,
какое из неопределенностей
мы можем назвать "риском",
записать их, внести в регистр рисков и
предпринять что-либо насчет этого.
Понятно, что риск - это
разновидность неопределнности.
Но что это за разновидность?
Как вы думаете?
Я думаю, риск и неопределенность
не сложно различить.
Я использую для этого
три английских слова.
И вот эти слова:
"Риск = неопределенность,
которая важна."
Потому что большинство неопределенностей
в мире не имеют значения:
Нам все равно будет ли
идти дождь в Лондоне завтра в полдень.
Может быть да, а может быть нет.
Это не важно.
Это не имеет никакого значения.
Нам все равно каким будет
обменный курс между рублем и юанем в 2020.
Не важно.
Но есть некоторые определенности
в наших планах,
семейных отношениях,
делах нашей страны,
которые нам важны.
Если эти неопределенности нам важны,
то это и есть "риск".
В связи с этим другой вопрос:
Что тогда имеет значение?
好的,让我们来看一下实际中的风险管理吧。
而我将从一些基本概念开始阐述
然后再逐渐聚焦在两个在风险分析中最为困难的领域
我估计,如果问你如何去定义“风险”这个词
你将会有很多不同的想法去定义它
我们可能并没有一个准确的定义让我们能够解释其
但是当我们听到“风险”这个词的时候,我们都会在头脑中得到一些画面
这就是我们如何思考的,并且可能你也会像这样
或许你感到就好像这位小兄弟一样,面对一些艰难的挑战
然后你便知道该把....
又或许你感到像这个家伙一样
这是真实的职业在北朝鲜
并且他的工作就是举起靶子让其他人来射击
有时候,项目管理同样有“靶子”在这儿
我们感觉到每个人都在向我们的工作射击
又或许你恰好知道有一些棘手的事情等待着你去做
并且当你考虑“风险”这个词时,那可能就是你所想的
但这只有一部分正确了,并不是完全正确
风险并不是指不确定
风险和不确定有所关联,但并不相同
因此,所有风险都是不确定的,但是并不是说不确定的就都是风险
如果你有一个风险登记表或一个风险清单
其上不会有几百万个项目,或者不应该有
甚至其可能连几千都不到
更可能是更小的数字
尽管世界上有几百万不确定的事情
那么,我们该怎样定义哪一些不确定的事情可以被称作”风险“呢?
将这些风险写下来并登记在我们的风险登记表上
然后,再决定为这些”风险“做些什么
显然地,“风险”是不确定的子集,但是哪一个子集呢?
你怎么知道的?
我认为区分风险和不确定非常简单
并且只需要用三个词
那就是,”风险是强关联的不确定性“
因为世界上大多数不确定并不重要
我们并不关心如果伦敦明天下午是否下雨
它可能下,也可能不下。那没有关联,那并不重要
我们并不关心2020年如果汇率在俄罗斯卢布和中国人民币之间
的金融汇率会如何
因为那对我们并不重要
但是有一些事情在我们的工作中,
在我们的家庭中,
在我们的国家中,
这些不确定的事情则与我们有所关联
如果某个事件是一个强关联的不确定,那它就是风险
因而,这引出另一个问题,怎么确定是否强关联呢?
在你的工作中,哪些事情是强关联的呢?
在我们项目中,重要的事情就是我们的目标
因此,我们必须总是将不确定和目标联系在一起
为了找到风险
如果我们聚焦在风险的一些定义上
那这是我所提倡的ISO标准
它仅由几个简单的词构成
风险是项目中不确定的效果
我们可能又聚焦在来自英国的另一些定义
或是来自我们协会的项目管理
而最终会得到一样的答案,风险就是一个不确定的事件
或是一系列的不确定的情况
但是它们重要在因为他们应该发生
它也将会有一种在目标上的成就的效果
强关联的不确定
因此,我们应该检查我们风险登记单上的两件事情
它是不确定的吗?我们不想要待解决的问题
也不想要待解决的状况
更不想出现什么约束或要求
这些事情是确定的,而我们想要的是不确定的,
一些可能发生,也可能不发生的事情
但有另一个重要的问题对于我们的风险清单来说,那就是
它是否强关联?
如果这个事情发生了,哪一个目标会被影响?
紧接着,当我们想要去看时,能否知道风险有多大?
我们能够回答那两个问题:
它有多不确定?
以及,它有多大关联?
之后,那便会告诉我们,风险有多大。
因此,这个强关联的不确定的想法
将会通过连接我们目标中的那些不确定
进一步完善以确定哪一些是有用的
因此,我们就有了2个关于“风险”的模型
我们有一个不确定的模型和一个
影响我们目标的模型
在项目中,我们将其称为可能性和实现性,
我们也能够称呼它们为另一些东西
另一些句子来表达
而且,我们经常地使用
而我们使用最多地就是
我很想问一下你关于这副老鼠图片地一些事情
什么事物会对老鼠有着很大的影响?
那么,首先,可以肯定的是,这是一个不确定的情况
然后,我们来看一些风险
他的目标是得到那些奶酪且存活下来
这就是它确定下的风险中的一个
这件糟糕的事情可能会发生,他可能会受伤或者一命呜呼
也因此,他是一个很好的项目管理了
他放下了他眼前那小的利益而去做准备
因此,坏事情就不会发生,他也就不会因此受伤或死亡
非常好
同样的,有一些在我们项目中发生的事情
同样会使我们受伤,甚至致命
它们可能会浪费时间,
浪费金钱,损害名誉,
摧毁表演
甚至可能伤害到真实的人
而作为项目管理者,我们不得不去监视这些事情并阻止其发生
以提前保护我们自身
以防患于未然
对于这只老鼠,这还有其他强关联的不确定吗?
没错......是有的
就是那个奶酪
那可是一个需要处理的大问题
我能否从陷阱中得到奶酪呢?
他也许可以得到,也许不能得到
如果他因为陷阱而没有得到奶酪,那就失败了
因此,他有两个不确定风险需要考虑
它们其中的一个会有糟糕的后果,甚至致命
而另一个要好一些,他可能得到那个奶酪
而他不得不这么做
他不得不去同时考虑这两个风险
而作为项目管理,我们也不得不做同样的事情
我们也需要以最好的可能方式去达成目标
有时,会有更好的方式去得到那块奶酪而不会受伤或死亡
在我们的项目里,我们不得不阻止糟糕情况的发生
但我们也不得不因为我们的项目而去想方设法得到奶酪
那么,“奶酪”在我们的项目中,它意味着什么呢?
我们项目中的什么是“奶酪”呢?
“奶酪”意味着价值
“奶酪”意味着利益
“奶酪”意味着产品和人们需要且想要的服务
“奶酪”意味着顾客的满意程度
“奶酪”是能够让我们试图拜托困境的好东西
而我们如果不做任何坏打算?
我们将不会浪费时间,浪费金钱,损害名誉
但我们不能创造价值
我们失败了
如果那个老鼠没有死而没有得到奶酪,那么就失败了
如果我们得到了利处,但我们
浪费了时间,金钱,损害了名誉
我们仍然失败了
如果老鼠得到了奶酪却被杀了
那他就失败了
因此,我们必须同时处理两个风险
而当我们思考风险和影响时,
两个方面是重要的
坏结局和好结局
能够伤及项目的不确定事件
和能够帮及项目的不确定事件
它们两个都需要被管理
我们也有另一个那些的说法
因此,这是来自PIM的风险定义
来在PMBok指导手册
它和我们之前看到的一样:
一个如果发生了,就会影响目标的不确定的事件或状况
但PMI知道关于那只老鼠,也知道关于那个奶酪和陷阱,