Project Management Central

Please login or join to subscribe to this thread

Topics: Risk Management
5 Strategies for threats in project risk management
Network:941



PMBOK Guide 6ed added "Escalate" strategy with the existing 4 strategies; "Avoid", "Transfer", "Mitigate" and "Accept", to deal with threats.
These 4 strategies can be grouped into following 2 categories;
- Proactive: "Avoid", "Mitigate". They can decrease the probability and/or impact of negative risks, in order to optimize the chances of project success as mentioned in the guide.
- Active: "Transfer", "Accept". They do not remove the known risks but can be considered.
How about the "Escalate"? "Proactive" or "Active"?
Sort By:
Page: 1 2 next>
Network:593



1-Risk buffering (or risk hedging) is the establishment of some reserve or buffer that can absorb the effects of many risks without jeopardizing the project. A contingency is one example of a buffer.
2-Risk avoidance is the elimination or avoidance of some risk, or class of risks, by changing the parameters of the project.
3-Risk control refers to assuming a risk but taking steps to reduce, mitigate, or otherwise manage its impact or likelihood.
4-Risk Transfer and Contracting re is a common adage about risk management that the owner should allocate risks to the parties best able to manage them.
5-Risk Mitigation includes reduction of the likelihood that a risk event will occur and/or reduction of the effect of a risk event if it does occur.
...
1 reply by JOONMIN SUH
Dec 17, 2017 6:14 PM
JOONMIN SUH
...
Hi Shadav, the 4 strategies are exactly match with yours as follows.
1-Risk buffering Accept
2-Risk avoidance Avoid
4-Risk Transfer Transfer
5-Risk Mitigation Mitigate
"3-Risk control" seems contingency for "unkown risk"; "assuming a risk". Thank you for your comment.
Joonmin
Network:401



I have read that "Escalate" seems to be a strategy to give the risk to someone else so that it's out of your hands. Sounds innocuously similar to Transfer. If you give the risk to someone , it is still active ....for them....not just for you...
...
1 reply by JOONMIN SUH
Dec 17, 2017 6:28 PM
JOONMIN SUH
...
Thank you Deepesh, yes, "Escalate" seems like "Transfer" of the risk not agreement/contract but acceptance of the relevant party.
Joonmin
Network:9312



Escalate is kind of a Transfer in my book.
Network:31



I think it's a kind of active strategy in comparison to the other strategies rather than being proactive because at the first place we claim not being responsible for the risk.
Network:1524



There was a lot of debate inside the group of authors and reviewers of the PMBOK about this topic. People like me do not agree to include escalation as an strategy because escalation belongs to project governance and it is used as an action that could be taken for all project management items inside your projects. When something exceeds the level of decision/resolution of the project team you have to put it under program/portfolio management consideration or under somebody consideration with a higher level of decision/resolution to help you. But the item still remains under your scope of management as project manager. You need to control activities to take an answer. If you read the PMBOK in the risk session that is not what the PMBOK stated. What PMBOK stated is close to say "this risk does not corresponds to me". So, in my personal opinion, that is not a strategy. Is an action to change the state of a indenfied risk.
...
2 replies by JOONMIN SUH and Mounir Ajam
Dec 15, 2017 7:00 AM
Mounir Ajam
...
Agree with your view and I share. I do not understand why this is here. Maybe it is just a recognition that many PMs are not really PMs and they have no authority so they escalate
Dec 17, 2017 6:46 PM
JOONMIN SUH
...
Thank you Sergio.
Your comment is very clear and agree with your answer.
I think project manager and team will endeavor to identify the risks inside the scope of the project and PM shall put it under program/portfolio management level as you mentioned.
I like your approach.
Joonmin
Network:750



Dec 15, 2017 5:58 AM
Replying to Sergio Luis Conte
...
There was a lot of debate inside the group of authors and reviewers of the PMBOK about this topic. People like me do not agree to include escalation as an strategy because escalation belongs to project governance and it is used as an action that could be taken for all project management items inside your projects. When something exceeds the level of decision/resolution of the project team you have to put it under program/portfolio management consideration or under somebody consideration with a higher level of decision/resolution to help you. But the item still remains under your scope of management as project manager. You need to control activities to take an answer. If you read the PMBOK in the risk session that is not what the PMBOK stated. What PMBOK stated is close to say "this risk does not corresponds to me". So, in my personal opinion, that is not a strategy. Is an action to change the state of a indenfied risk.
Agree with your view and I share. I do not understand why this is here. Maybe it is just a recognition that many PMs are not really PMs and they have no authority so they escalate
Network:415



A description I found for 'escalation' is as follows:
"Risk escalation is used when a project team identifies a risk that does not belong within the scope of their project, because it would not affect any project objective, but it could affect someone else."

Notifying another department about a risk that could affect them is just good business or professional consideration, but I wouldn’t describe it as a ‘risk strategy’.
...
1 reply by JOONMIN SUH
Dec 17, 2017 6:56 PM
JOONMIN SUH
...
Thank you Eric, I agree with your idea. In addition, PM and project team shall identify and perform risk analysis the risks within the scope of their project based on the risk management plan.
Joonmin
Network:641



Sergio & Mounir -

I would see Escalate in a slightly different context. Escalating a risk which directly impacts your project's objectives does not relieve you of the accountability for the project's success - I would see that type of escalation as still being a mitigation response.

However, if there is a risk which we've run across which doesn't affect our project's success but if realized would impact something external to our project, then escalating it will ensure that it is sent to the right risk owner and we can take it off our risk registers.

To Joonmin's original question, I'd view it as a passive strategy - other than communication we aren't expending any resources to respond to it.

Kiron
Network:750



First,

The PMBOK Guide Definition and it could be related to the project objectives or outside as Eric mentioned. However, the definition is in line with what Sergio said.

"Escalation is appropriate when the project team or the project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed the project manager’s authority. Escalated risks are managed at the program level, portfolio level, or other relevant part of the organization, and not on the project level."
Network:750



Guys

Forgive me for being blunt - what does it matter if it is passive, active or pro-active? What does it matter if it is a risk transfer or risk mitigation?

We can debate this but what is the point? What is the value added to the professional community on this?

I honestly think that the first three chapters of the new PMBOK Guide are mostly good but in many other places, the guide now reminds me of the question/cartoon "how many elephants can you put in a VW"?

The concept of escalation on any matter - is proper business whether it is a risk, quality matter, error in OPA, or anything else so why this is a risk response strategy? Beats me - except it is good juice for a few confusing exam questions.

I can imagine see the question posted here as a PMP exam question.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I respect a man who knows how to spell a word more than one way."

- Mark Twain