Risk avoidance: Risk is avoided by obviating the possibility that the undesirable event will happen. You refuse to commit to meeting milestone M by feature F – don’t sign the contract until the software is done. This avoids the risk. As long as you enter into the contract to deliver specific scope by a specific date, the risk that it won’t come about exists.
Risk reduction: this consists of minimizing the likelihood of the undesirable event. XP reduces the likelihood that you will lack some features at each milestone by reducing the amount of “extra” work to be done, such as paperwork or documentation, and improving overall quality so as to make development faster.
Risk mitigation: this consists of minimizing the impact of the undesirable event. XP has active mitigation for the “schedule risk”, by insisting that the most valuable features be done first; this reduces the likelihood that important features will be left out of milestone M.
Risk acceptance: just grit your teeth and take your beating. So we’re missing feature F by milestone M – we’ll ship with what we have by that date. After reduction and mitigation, XP manages any residual risk this way.
Risk transfer: this consists of getting someone else to take the risk in your place. Insurance is a risk transfer tactic. You pay a definite, known-with-certainty amount of money; the insurer will reimburse you if the risk of not completing feature F by milestone M materializes. No provision in XP. Has anyone ever insured a software project against schedule/budget overrun ?
Contingency planning: substituting one risk for another, so that if the undesirable event occurs you have a “Plan B” which can compensate for the ill consequences. If we miss critical milestone M1 with feature set F1, we’ll shelve the project and reassign all resources to our back-burner project which is currently being worked on by interns.
Key point from all the above: risk management starts with identifying specific risks. Also, I think you can perform conscious risk management using any process, method, technique or approach. It’s important to recognize that any process, etc. simply changes the risk landscape; your project will always have one single biggest risk, then a second biggest risk, and so on.
Also: risks, like requirements, don’t have the courtesy to stay put over the life of a project. They will change – old ones will bow out as risk tactics take effect, new ones will take their place.
Risk management is like feedback. If you’re not going to pay attention to it, you’re wasting your time. More than once I’ve tried to adopt a risk-oriented approach to projects, only to have management react something like, “Oh, you think that’s a risk. Well, thank you for telling us. We’re happy to have had that risk reduced. Now proceed as before.”
One risk I often raise in projects is skills risk. Developers are supposed to crank out Java code who have only ever written Visual Basic, that sort of thing. Not once have I seen a response of risk avoidance (substituting other, trained team members for the unskilled ones), reduction (training the worker in Java), or mitigation (making provision for closer review of the person’s code). It’s always been acceptance – “We know it’s less than ideal to have this guy working on that project, but he’s what we’ve got at the moment. Can’t hire anyone on short order, no time for training, no time for more reviews.”