Following are processes defined in Risk Management Knowledge Area:
| 5 Process Groups | Initiation | Planning | Execution | M & C | Closing |
| Processes | | 11.1 Risk Management Planning
11.2 Risk Identification
11.3 Qualitative Risk Analysis
11.4 Quantitative Risk Analysis
11.5 Risk Response Planning
| | 11.6 Risk Monitoring and Control
| |
Let us talk about negative risks … it is a multiplication of Probability of occurrence and impact of that event. For example: Consider chances for an event to occur is at 95% and impact would be very minimal say $100. The impact would be 95/100 * 100 = 95. Consider chances for other event to occur is at 10% but the impact is $10000. Then the impact is 10/100*10000 = 1000. Quite a high when compared to firs one. So the whole project risk is summation of these impacts.
Project Risk = Sum Of (Events * Probabilities * Impacts)
After evaluating risks, one can choose a path of risk avoidance or risk mitigation and management. If we understand the risks on a project, we can decide which risks are acceptable and take actions to mitigate or forestall those risks. If our project risk assessment determines risks are excessive, we may want to consider restructuring the project to within acceptable levels of risk. One way to reduce risk is to gather information about relevant issues to lower the level of uncertainty. Then we can look for ways to reduce probabilities of failures or to reduce their consequences.
Deliverables which have uncertainty to be completed successfully can be considered as risk. For example: after finishing the Project planning you still feel that the scope might change then it is a Risk. Or even if scope is not well defined then it is a Risk. An unproven or immature technical approach, or known technical difficulty or complexity will increase project risk. Ambitious goals always result in risk. Unfamiliarity with the process, or inexperienced personnel, constitutes project risks, if for no other reason than being unknowns. Exterior interfaces cause risks because they can change and, even if they don’t change, their descriptions or specifications may be inaccurate. Exterior organizational dependencies create project risks. Incomplete planning or optimistic cost or schedule goals create risk. If the customer is involved in schedule dependencies for document review and approval or for delivering process information, this creates project risks.
Any area over which the project manager does not have control can be project risks. Anything that is not well understood, anything that is not well documented, and anything that can change, these all create project risks. Things that haven’t been tested are always at risk.
PMI has perfect steps to attack Project Risks. All of those processes except one are defined in Planning Phase and “Monitor and controlling” process is given to control the risk for rest of the project. Risk can be identified later in the execution Phase. But those should come back to planning phase to finish proper analysis before monitoring those.
3 steps approach is very important for all your Projects.
1. Identify all Project Risks
2. Analyze those Risk
a. Qualitatively – Probability of occurrence
b. Quantitatively – Impact if it occurs
3. What are your responses to those identified and analyzed Risks?
Remember you need not evaluate all identified risks or you need not to take actions on all responded risks either. For example, you identified airplane hitting in to your building as a project Risk because your office is next to Airport. Probability of occurrence is .0001. For such kind of risk you need not to find a Response strategy or need not implement a solution.
{{ Overview - 11.1 - 11.2 - 11.3 - 11.4 - 11.5 - 11.6 }}