The title of this article is a quote from Tim Lister, and is a universal principle for the success of any project in the presence of uncertainty. All software development projects are subject to risk and uncertainty because they are unique, constrained, based on assumptions, performed by people and subject to external influences. Risks can affect the outcome of projects either positively or negatively.
“If There’s No Risk On Your Next Project, Don’t Do It”
Greater risk brings greater reward, especially in software development. A company that runs away from risk will soon find itself lagging behind its more adventurous competitors. But by ignoring the threat of negative outcomes project managers and executives can drive their organizations into the ground.
Positive Risk
Risk includes both opportunities and threats. Where negative risk implies something unwanted that has the potential to irreparably damage a project, positive risks are opportunities that can affect the project in beneficial ways. You should manage and account for known negative risks to minimize their impact, but positive risks you should manage to take full advantage of them.
There are many examples of positive risks in projects: you could deliver the project early; you could discover that the problem is easier to solve as expected; you could re-use your solution for other problems; you could acquire more customers than you accounted for; you could imagine how a delay in shipping might open up a potential window for better marketing opportunities, etc. Just be aware that positive risk can quickly turn to negative risk and vice versa.
Risk or Uncertainty?
In project management, or more specifically in risk management, many professionals commonly use risk interchangeably with uncertainty. This is incorrect.
“Uncertainty is risk that is immeasurable.” – Frank Knight
Risk has an unknown outcome, but we know what the underlying distribution looks like. Every game in the casino has a known distribution of winning and losing. Hence you can play and manage risk. Following basic strategy for Black Jack for example. But where the hand of your new and unknown Poker neighbor is a risk, how he plays that hand is an uncertainty. Events of the past are no guarantee for the future.
You cannot manage uncertainty, but you can manage risk. What you can do is reduce the amount of uncertainty. For example by doing a proof of concept or a business case validation for your project.
Risks and Issues
Consider the following circular definition of risk: A risk is an issue that has yet to occur, and an issue is a risk that has already materialized.
Before it happens, a risk is just an abstraction. It’s something that may affect your project, but it also may not. There is a possibility that ignoring it will not come back to bite your ass. Risk management is the process of thinking out corrective actions before an issue occurs. The opposite of risk management is crisis management, trying to figure out what to do about the issue after it happens.
“The opposite of risk management is crisis management” – Tim Lister
Varieties
Risks may be encountered in an almost infinite variety of forms and intensity, it is most useful to consider two varieties:
Incremental risks – These include risks that are not significant in themselves but that can accumulate to constitute a major risk. For example, a cost overrun in one subcontract may not in itself constitute a risk to the project budget, but if a number of subcontracts overrun due to random causes or a common cause affecting them all, then there may be a serious risk to the project budget. While individually such risks may not be serious, the problem lies in the combination of a number of them and in the lack of recognition that the cumulative effect is a significant project risk.
Extreme risks – These include risks that are individually major threats to the success of the project, or even the company as a whole. Their likelihood is typically very low but their impact very large. Examples of such risks are dependence on critical technologies that might or might not prove to work, scale-up of bench-level technologies to full-scale operations, or dependence on single suppliers and employees. And of course aliens, always account for a space attack by aliens…
Transitions
Imagine the moment when something that used to be a risk suddenly becomes an issue. It used to be an abstraction, a mere possibility, and now it is not abstract at all. It has happened. This is the point at which the risk is said to materialize. It is the moment of risk transition.
Transition is a key concept for a project manager—it is the triggering event for whatever is planned to deal with the risk. Well, almost. The actual transition may be invisible to you (for example, your biggest client goes out of business). What you do see is a transition indicator (the client not paying your invoices for a while). For every risk you need to manage, there is some kind of transition indicator. Of course some indicators are more useful than others.
Response Strategies
Depending if a risk is positive (opportunity) or negative (thread) you have following response strategies available to you.
The reason you care about the above-mentioned transition is that when the indicator fires, you intend to take some action. This is defined in your contingency plan. But much work can be done before the transition starts. And you should. Buying a life insurance after your dead is difficult…
Risk Management
So what is risk management? I always explain as the combined outcome of the five activities below.
1) Risk discovery: your initial risk brainstorm and subsequent triage, plus whatever mechanism you put in place to keep the process going
2) Exposure analysis: quantification of each risk in terms of its probability of materializing and its potential impact
3) Contingency planning: what you expect to do if and when the risk materializes
4) Response planning: steps that must be taken before transition in order to make the planned contingency actions possible and effective when required
5) Ongoing transition monitoring: tracking of managed risks, looking for materialization
The first of these is an overall activity, while all the others are done on a per-risk basis.
Risk management is something that most of us practice all the time—everywhere except the office. In our personal lives, we face up to such risks as sickness and early death. We mitigate by buying life and health insurance and by making arrangements for who will look out for the kids if something bad happens.
We don’t pretend to be immortal or that our earning capacity can never be harmed by bad luck. Each time we take on a new responsibility—say, a mortgage—we go over all the awful things that we hope won’t happen and force ourselves to think, what if they do?
You should do the same for your software development project.