What if our project timeline had no constraints? What if we had all requirements neatly laid out before us with no missing detail every time on every project? What if we had no resource constraints, no third party vendor screw-ups, no customer’s trying to ask for more functionality ‘just this one time’? What if there were no risks on our projects? Yeah….like that’s going to happen.
And if project managers had unlimited funding they could always identify a multitude of risk events. Some of the risk impacts may be insignificant, whereas others may expose the project to severe danger. With a large number of possible risk events, it is impossible to address each and every situation. It may be necessary to prioritize risks.
Assume that the project manager categorizes the risks according to the project’s time, cost, and performance constraints. Let's assume, for now that you're using a detailed tool like Seavus' Project Viewer to help you manage the project schedule and that schedule is the top priority for this project. If schedule has been determined to be the highest priority for the project, then the project manager should focus his/her efforts on reducing the scheduling risks first. The prioritization of risks could be established by the project manager, by the project sponsor, or even by the customer. The prioritization of risks can also be industry- or even country-specific. It is highly unlikely that any project management methodology would dictate the prioritization of risks. It is simply impossible to develop standardization in this area such that the application could be uniformly applied to each and every project.
Prioritization of risks
The prioritization of risks for an individual project is a good starting point and could work well if it were not for the fact that most risks are interrelated. We know from tradeoff analysis that changes to a schedule can, and probably will, induce changes in cost and performance. Therefore, even though schedules have the highest priority in our example, risk response to the schedule risk events may cause immediate evaluation of the technical performance risk events. Risks are interrelated.
Let’s also not forget that project opportunities, in turn, can cause additional risks to the project. In other words, risk mitigation strategies that are designed to take advantage of an opportunity could create another risk event that is more severe. As an example, working overtime (an opportunity that can be taken advantage of on most projects) could save you $15,000 by compressing the project schedule. But if the employees make more mistakes on overtime, retesting may be required, additional materials may need to be purchased, and a schedule slippage could well occur, thus causing a loss of $100,000. Therefore, is it worth risking a loss of $100,000 to save $15,000?
To answer this question, we can use the concept of expected value, assuming we can determine the probabilities associated with mistakes being made and the cost of the mistakes. Without any knowledge of these probabilities, the actions taken to achieve the opportunities would be dependent upon the project manager’s tolerance for risk.
Most project management professionals seem to agree that the most serious risks, and the ones about which we seem to know the least, are the technical risks. The worst situation is to have multiple technical risks that interact in an unpredictable or unknown manner.
Although project management methodologies provide a framework for risk management and the development of a risk management plan, it is highly unlikely that any methodology would be sophisticated enough to account for the identification of technical dependency risks. The time and cost associated with the identification, quantification, and handling of technical risk dependencies could severely tax the project financially.
Another critical interdependency is the relationship between change management and risk management, both of which are part of the singular project management methodology. Each risk management strategy can result in changes that generate additional risks. Risks and changes go hand in hand, which is one of the reasons companies usually integrate risk management and change management together into a singular methodology. If changes are unmanaged, then more time and money is needed to perform risk management. And what makes the situation even worse is that higher salaried employees and additional time is required to assess the additional risks resulting from unmanaged changes. Managed changes, on the other hand, allows for a lower cost risk management plan to be developed.
Project management methodologies, no matter how good, cannot accurately define the dependencies between risks. It is usually the responsibility of the project team to make these determinations.