Project Risk Management
Risk Concepts:
Risk is a combination of the probability of a negative event and its consequences. If an event is inevitable but inconsequential, it does not represent a risk, because it has no impact. Alternatively, an improbable event with significant consequences may not be a high risk. These two factors are combined in what we experience as the possibility of loss, failure, danger, or peril.
An easy way to reduce risk is to have less ambitious goals. 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.
Risks that do not offer the potential for gain (profit?)should be avoided. Risks associated with achieving challenging and worthwhile goals should be managed. 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.
What may look like an unacceptable risk to one person might rightly appear as an attractive opportunity to another. The difference is vision.
Items in the project plan that are important and that are uncertain of success should be considered risk areas and given special attention. Risk should be associated with areas where the scope is not well defined or is subject to change. 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, constitute 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. Conversely, project risks are created if the customer is not involved in periodic review of the system design and project plans.
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.
An organizational culture that has previously had problems executing projects will be likely to repeat the same mistakes. These problem areas should be understood and managed as significant project risks. They must be counteracted by specific bold mitigating management initiatives or repeated failures are guaranteed
The known unknowns are more likely to be project risks than the unknown unknowns. This means you should trust your instincts and pay attention to what seems risky to you. It is more likely you will have problems from known risk areas than be surprised by things completely unforeseen.
Risk Management:
Risk analysis consists of risk identification, probability assessment, and impact estimate. Start by identifying all the risk events that can occur on your project. Then estimate the probability of each event happening. Finally, estimate the impact in hours or dollars if the event occurs. Once you have listed and quantified the project risks, then you should prepare a risk management plan for each significant risk item. The final step would be to formalize this into a risk management activity, establish metrics, and track your top ten risks week by week.
| Risk Event | Probability | Impact | Risk Score | Risk Mitigation Plan |
| Change host operating system | .2 | 100 hours | 20 hours | Work with host support group |
| Redesign data model | .4 | 200 hours | 80 hours | Do early prototyping |
| Data conversion is late | .7 | 300 hours | 210 hours | Request tracking of progress |
Total Risk: |
310 hours |
Schedule Risk Assessment using PERT:
PERT is an acronym for Program Evaluation and Review Technique. A PERT chart is a Critical Path Method (CPM) chart considered statistically. It can be useful in assessing schedule risk, and schedule risk usually turns into cost risk. ((I have never actually seen this used on a project.))
The essential nature of PERT analysis is to determine the expected time for each activity by using a weighted average of the most likely along with the best case and worst case time estimate that can reasonably be imagined. The normal approach to PERT is to weights the "most likely" four times heavier than the extremes, then sum them all and divide by six. When the expected times have been determined for all activities on the critical path, these can be summed to determine the expected time for the entire project.
The standard deviation can be determined for each element in the network using the formula (b-a)/6. The standard deviation for the entire project will be the square root of the sum of the squares of the standard deviations of the individual elements. Having the standard deviation for the total project, one can then assess the probability of different schedule outcomes.
If the standard deviation for a total project is one month, you can consult a Standard Normal Distribution table to see that one standard deviation includes 84% of the population. Therefore, the probability that the project will complete no more than one month late is 84%. The probability that it will complete at least one month early is 1-84% or 16%. You can use the standard deviation for the total project to evaluate probabilities for different outcomes by converting a completion date to standard deviations from the expected time and then using the table to find the probability of occurrence.
While this is an interesting concept, it is only used in practice for projects with often repeated tasks and highly standardized methodologies. In all other projects, there are so many other unknowns, uncertainties, and instabilities that PERT analysis is insensitive to all the most relevant issues driving the schedule risk. In other words, it may be pointless to do statistical analysis if you already understand where your problems are.