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.
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.
