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知道关于那只老鼠，也知道关于那个奶酪和陷阱，