Risk management is becoming recognized as a best practice in the software industry for reducing the surprise factor. While we can never predict the future with certainty, we can apply structured risk management practices to peek over the horizon at the traps that might be looming, and take actions to minimize the likelihood or impact of these potential problems. Risk management means dealing with a concern before it becomes a crisis.
Symptoms that an organization is not effectively practicing risk management include a continual state of project instability, constant fire-fighting, multiple schedule slippages because of recurring surprise factors, and constantly operating in a high-stress, crisis management role. Formal risk management greatly improves the likelihood of successful project completion, and it reduces the potential negative consequences of those risks that cannot be avoided.
A simple definition of a "risk" is a problem that could cause some loss or threaten the success of our project, but which hasn’t happened yet. (And we’d like to keep it that way.) These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of our software products, or project team morale. Risk management is the process of identifying, addressing, and eliminating these potential problems before they can damage our project.
We need to differentiate risks, as potential problems, from the current problems facing the project, because different approaches are taken for addressing these two kinds of issues. For example, a staff shortage because you haven’t been able to hire people with the right technical skills is a current problem, but the threat of your top technical people being hired away by the competition is a risk.
Current, real problems require prompt corrective action, whereas looming risks can be dealt with in several different ways. We might choose to avoid the risk entirely by changing our project approach or even canceling the project. Or, we could elect to simply absorb the risk and take no specific actions to avoid or minimize it. More often, though, we’ll want to contemplate actions that will either minimize the likelihood of the risk turning into a problem, or reduce the negative impact of that problem on our project.