Risk Management

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

If you only ever have one tactic for dealing with risk, your risk "management" is a no-brainer.

---- From the Laurent Bossavit weblog

posted on Tuesday, November 04, 2003 1:56 AM

Feedback

# re: Risk Management 7/19/2004 9:02 PM Manikandan.A

Hi
This is very nice.
But can u put the types of Risks in real time s/w Testing?

Thanks & Regards
Manikandan.A

# re: Risk Management 11/22/2004 11:10 AM Krishna Geete

Hi
Risk Management topic is very good and it is very usfull for implementing in my orgenization.

Krishna Geete
Axis Software Pvt. Ltd.

# re: Risk Management 2/8/2005 10:49 AM Ashish Vijay Borikar

Definitely a good article on Risk Management.
In addition to the above, it will help if links to certain tools used for Risk Management are provided. That can give insight towards managing risks in a better way.
One can have an Excel sheet based template for Risk Management, which is combined with Issues management, since Risks can typically be treated as "Issues likely to be faced in the Future" and a complete plan and schedule can be prepared accordingly. Tools like "Risk Radar" can also be used in an effective manner.

# re: Risk Management 2/12/2005 2:32 PM Mohiddin

What is difference between contigency and mitigation test plans?

# re: Risk Management 3/9/2005 3:35 AM Veener

"What is difference between contigency and mitigation test plans?" That was my question. I hope someone comes to our rescue. :)

# re: Risk Management 4/6/2005 3:27 PM P.Umamahesh

Contingency plan is an alternative plan of action if the existing plan fails. Mitigation plan is a plan to mitigate the risk.

# re: Risk Management 11/29/2005 9:06 AM Shashi

Mitigation:

Reducing the impact of risk asssociated. Surely one cannot avoid risk but efforts can be put in to reduce the impact of it with some measures.

Contingency:

This is an alternative path to combat risk which is an unforeseen event.

E.g:

Fire is a risk.

Mitigation Plan: Make the specified area as prohibited for smoking, letting people carry match boxes and lighters etc, which may cause fire.

Contingency Plan:

Have fire extinguishers ready in all places, and train people on how to use the same. Even if fire breaks down that can be put off by fire extinguishers.

Post Feedback

Title:
Name:
Email: (never displayed)
Url:
Comments:
Please add 6 and 4 and type the answer here: Remember Me?

Test Notes

News

Archives

Post Categories

Image Galleries

Friend's Blog's

Groups

Sites

Testing Blog's

Feedback

Post Feedback