Risk on Projects

Risk

A risk is simply something that can go wrong (and something usually does on projects), that keeps you from achieving project success.  Of course there are things that can occur that are positive, which can also be referred to as risks.  We will focus on those risks that have a potential negative impact on your project.  Risk management is a discipline that allows you to increase your chances of success by planning how to identify and reduce the likelihood of risks occurring; risk management also helps you identify how to minimize the consequences of the risk if they do occur– in spite of your planning efforts. 

How is it created? 

Risks fall into three categories on a project: scope, resource and schedule.  In the categories of scope and resource risks, innovation is a major risk factor. Any time the project team, the organization or the external stakeholder ventures into unknown terrain or looks to make a significant change to how things are currently being done, the risk factors multiply. The less experience you have with a certain type of application or technology and the more change you try to make to an organization, the likelier you are to run into trouble.

The second most likely set of risk factors is associated with complexity. Complexity introduces relationships among parts of the project, so that there are more dependencies. If something goes wrong in one area, it is more likely to affect some other area. Complexity also often increases project size, since there are more things to be done. And sheer size is a risk factor, because the difficulty of communicating among team members and with stakeholder grows geometrically. Finally, complexity is often associated with lack of experience. Just as, according to Tolstoy, all happy families are alike, but each unhappy family is unhappy in its own particular way, so all simple systems resemble each other, but each complex system is complex in its own unique way. And lack of experience has the same consequences as innovations.

Finally, there are risks that do not vary much from project to project: a fire destroying the developers’ workspace; a key team member is injured and hospitalized; the company is taken over and the new management must be brought up to date before the project is allowed to continue; the sponsor or the organization’s management is indecisive and stakeholders keep changing their minds...  

Once you have identified and assessed the risks on your project, you can start planning how to address them. There are two things you can do to improve the situation: risk reduction, decreasing the probability of a risk materializing, and risk mitigation, decreasing its consequences, should it materialize.

Once you have identified and assessed the risks on your project, you can start planning how to address them. There are two things you can do to improve the situation: risk reduction, decreasing the probability of a risk materializing, and risk mitigation, decreasing its consequences, should it materialize.

Risk Reduction

To reduce risks, you can use several approaches:

• Create an awareness of the risk among your team members and the project stakeholders: “forewarned is forearmed.” For example, you might point out that computers do crash and that it is prudent to save your work from time to time when you are engaged in a long-lasting task.
• Create a specific process to reduce risk. For instance, you may have found in the past that there is a risk of system testing being incomplete (causing defects to slip through) unless you include user representatives in test planning. You would then, as a minimum, require sign-off by a user before the test plan is declared complete.
• Invest resources in risk prevention. For instance, you could have the organization install fire extinguishers. A more relevant example is to install a good computer backup system, which will reduce the risk of losing completed work and also reduce the risks associated with system modifications.

Risk Mitigation

Risk mitigation is how you plan to minimize the impact if any of the risk factors that you have identified should materialize. You will never be able to reduce the risks to a point where it is guaranteed that nothing wrong will happen: at some time, some risk will materialize. (This is popularly known as “Murphy’s Law.”

The two main approaches to risk mitigation are early detection – finding out that an incident has happened before the consequences have had time to spread – and contingency planning. Contingency planning consists in figuring out beforehand how to handle a crisis and setting apart resources to deal with it. For example, you might have a succession plan for key personnel, so that if someone falls sick, you can quickly get a replacement (for example, from a temporary work agency). In all cases, you need to set aside a contingency in both the project budget and the schedule. The contingency does not need to cover the sum of all possible risks, since only a small number of risks are likely to materialize. The most important thing about the contingency is that it is a reserve for the entire project based on the likelihood and impact of the risks identified, not a reserve that you build into each individual activity. If you did, you would soon find that team members would treat the contingency as an addition to the estimated time to complete the task, and they would therefore gradually consume the whole contingency without any risk actually having occurred.

Of course, if the consequences of a risk happening are so minor that they won’t affect cost, schedule, scope or quality, you can remove the risk from your risk management plan.

Risk Management Plan
A risk management plan consolidates in a single document all of the work of identifying, reducing and mitigating risks. The list below was developed for our sample project and represents a typical example of risks on a fairly small project to implement a new system.