In chapter 11 of PMBOK 6, it mentions a document called: "defnitions of risk impact levels for the project" that is given to the project team so risk thresholds and variation around a project objective can be examined. (pg 398 KEY CONCEPTS FOR PROJECT RISK MANAGEMENT).
Has anyone seen this type of document?
I've searched the internet for "definitions of risk impact levels" and get nothing meaningful. Saving Changes...
Mahabubur RahmanProject Manager Structures-Bridges| Department of Infrastructure, Government of Nothwest TerritoriesYellowknife, Northwest Territories, Canada
To my understanding, definitions of risk impacts are customized according to the risk thresholds of a project. It helps to assess the impact on the project and determine which risk need to take prior action. To develop an effective risk response plan we follow other processes like perform qualitative risk analysis and perform quantitative risk analysis depending on the availability of time and budgets. Saving Changes...
Hello Mahabubur, Yes, I agree with you. But the document that defines these "risk impact levels" for the project team isn't clearly defined anywhere in PMBOK6 that I can find.
My interest was really "What does a definition of risk impact levels document look like?"
While I'm reading chapter 11, I noticed that "Escalate" isn't listed as a strategy to take for "Overall Project Risk" (paragraph 11.5.2.7)
But, the guide does mention that "The same risk response strategies that are used to deal with individual project risks can also be applied to overall project risk." So, I guess ESCALATE is a valid option, just not described in the guide.
...
3 replies by David Maynard, Kevin Drake, and Margaret Love
Jun 03, 2018 9:21 PM
Margaret Love
...
I'm thinking that "Escalate" isn't appropriate for "Overall Project Risk". "Escalate" is what you do when someone identifies a risk that doesn't really belong to the project. The impact would be felt outside the project - at the program level or corporate level or in another project. I think a better term would have been "Hand Off" because you are handing it off to the appropriate person to manage. But you can't hand off your overall project risk. It's yours to manage as the PM in charge of the project. I could be wrong but my thinking is that overall project risk always belongs to the project and is therefore not escalated.
Jun 03, 2018 10:07 PM
Kevin Drake
...
I agree with that,
Jun 04, 2018 3:28 PM
David Maynard
...
All:
Thank you for your replies!
I understand the generic low / medium / high risk assessment. But, there's something else "afoot" here I think.
The document hinted at on Page 309 - last paragraph before "Trends and Emerging..." appears to come *from* the stakeholders or sponsor(s), are for each project objective, are explicitly stated, and are given to the project team (NOT generated by the team).
This doesn't sound like the regular Risk Assessment Matrix to me. It's something else. Something from the corporation, not OPA, but specific to the project.
I've never heard of this. I don't even see how it could happen. Are the stakeholders that much in touch with the details of a project to supply this document?
Saving Changes...
Mahabubur RahmanProject Manager Structures-Bridges| Department of Infrastructure, Government of Nothwest TerritoriesYellowknife, Northwest Territories, Canada
I haven't seen a document like this, but I've seen it captured in Project Risk Management Plans before. Basically, it provides some consistency and objectivity around how different teams can assess a given risk as being low vs. medium vs. high impact.
Kiron Saving Changes...
Margaret LoveSenior Instructor| VelociteachGreenville, Sc, United States
Jun 03, 2018 2:14 PM
Replying to David Maynard
...
While I'm reading chapter 11, I noticed that "Escalate" isn't listed as a strategy to take for "Overall Project Risk" (paragraph 11.5.2.7)
But, the guide does mention that "The same risk response strategies that are used to deal with individual project risks can also be applied to overall project risk." So, I guess ESCALATE is a valid option, just not described in the guide.
I'm thinking that "Escalate" isn't appropriate for "Overall Project Risk". "Escalate" is what you do when someone identifies a risk that doesn't really belong to the project. The impact would be felt outside the project - at the program level or corporate level or in another project. I think a better term would have been "Hand Off" because you are handing it off to the appropriate person to manage. But you can't hand off your overall project risk. It's yours to manage as the PM in charge of the project. I could be wrong but my thinking is that overall project risk always belongs to the project and is therefore not escalated. Saving Changes...
Margaret LoveSenior Instructor| VelociteachGreenville, Sc, United States
Table 11.1 is an "Example of Definitions for Probability and Impacts", which is what I think they are referring to as "definitions of risk impact levels for the project". Saving Changes...
While I'm reading chapter 11, I noticed that "Escalate" isn't listed as a strategy to take for "Overall Project Risk" (paragraph 11.5.2.7)
But, the guide does mention that "The same risk response strategies that are used to deal with individual project risks can also be applied to overall project risk." So, I guess ESCALATE is a valid option, just not described in the guide.
I agree with that, Saving Changes...
Sandra MaughonProfessor| Piedmont CollegeCleveland, Ga, United States
It is typically a grid that defines what low, medium, or high is, or if the levels are more granular like a scale of 1-10. It defines impact in terms of cost, schedule quality ( or other key factors). For example, "low" to you may mean 5 day delay or less than $500, but your customer (sponsor) may think "low" means 1 day delay to schedule or less than $100. Very simple examples, but you can see how quickly general terms such as low, medium, and high can be a serious communication issue. Likewise as you and your team are evaluating risks, you need to be sure everyone is assessing the same way. I'll see if I can find an example chart tomorrow, in the meantime asq.org has a good FMEA spreadsheet template (excel) that works well. Saving Changes...
