What is the process of software development risks management?

Question

Could someone please describe what is exactly risks management in software development? What are the main tasks, goals, strategies, tools, e.t.c.?

Update:

This is not a homework question. I am being put into the position of one-man project management and development team and i have no prior experience in the management part. I am currently collecting "keywords" and risks management is the one i have a hard time understanding now.

Answer 1

It means that you create five columns and five rows in a "risk matrix". From top to bottom, you have

"Disaster"
"Huge Chaos"
"Annoying"
"Minor issue"
"No problem"

from left to right you have

"Never happens"    "Rare"     "Sometimes"      "Frequent"      "Always"

Then, you mark in the proper cell each thing that can go wrong, its impact on the project, and its frequency.

• lead developer dies in a car accident: frequency rare, outcome huge chaos
• crash of hard drive on the storage server: frequency sometimes, outcome minor issue.

and so on.

Now, draw a line from the "disaster" to the "always" points on the axes of the matrix

• Any point falling below this line are safe, and you should not worry too much about them.
• Any point falling above this line are a danger for your project, and you should do everything you can to bring them below the line.
• Any point on the line is worth keeping an eye on it.

You have therefore two ways of minimizing risk: reduce frequency and reduce impact. For example: you can reduce frequency of disk crash by buying solid state disks. Reducing impact would be to have a RAID system, but as the impact is already low, that was because I assumed the server already has a RAID system.

For the developer, you can reduce impact by disseminating knowledge, so even if he dies (or quits) the project will continue anyway. You can reduce occurrence by closing him into a sealed room. So as you can see there are things whose occurrence you cannot reduce.

Answer 2

Stefano's answer talks about identifying risks.

Managing risks means more than just identifying them: after you've identified risks, to manage these risks you should then do things to reduce their likelihood and/or to reduce their severity.

For example:

Risk: crash of hard drive on the storage server

• Reduce severity: take backups of the storage server
• Reduce likelihood: buy high-quality hardware, store in a secure location, administer well, etc.

Risk: lead developer dies in a car accident

• Reduce severity: have a backup for the lead developer (e.g. have written documentation, and/or have other competent/knowledgeable people on the same team)
• Reduce likelihood: get a chauffeur and limousine, work from home, etc.

Risk: don't know what the customer wants

• Reduce severity: deliver an early/cheap prototype
• Reduce likelihood: talk with the customer

To be effective and efficient, the ideal is to find cheap and effective ways to reduce the severity and/or likelihood of the project's greatest risks.

Answer 3

Hi

Risks, in project management terms, are events outside the control of the project which have a potential impact on time, cost or deliverables. The impact might be either good or bad, effort and attention is usually only paid to the risks which have a bad impact -- a good PM can easily pass off the beneficial impact of a risk as the result of careful planning and management.

The risks you identify for your project are perspective dependent, by which I mean that there is no (even hidden, secret, known only to the initiated) list of 'All Project Risks', it's part of the PM's job to draw up the right list for a new project. For example, to pick up on one of Stefano's risks -- hard disk drive failure. I suggest that for the usual software development sort of project this is a low-impact medium-frequency risk. For a high-availability, ultra-large volume data, multi-site server-farm development hard disk failures are not a risk because such a project will have to take control over these events, one of the project's deliverables will be resilience.

The following are not usually project risks, 'cos they should always be inside the control of the PM (and yes, this is all contentious so if your opinion differs I'm cool with that, but this is my opinion):

• Loss of key staff -- don't set up a project with critical dependencies on individuals.
• Customer uncertainty about requirements -- set up your project to elicit these as you go rather than to commit to activities in advance of being ready for them. Agile, not waterfall, perhaps.
• Loss of source code due to hardware failure -- whaddya mean you don't put all files on systems which are backed up hourly ? And you are using a source code control system aren't you ?
• Others too, if only I had more time.

When you come to identify risks don't start your list like this:

1. Fire destroys offices.
2. Airplane crashes into offices, destroying them.
3. Floods destroy offices.

If it's appropriate for your project then the event which creates a risk is 'Loss of offices'. Incidentally, for most of us for most of the time this is not a risk to bother including. Likelihood is so low, and the worries in the event that it does happen so overwhelming that it's a waste of paper and PM time doing anything about it. But you decide for your project.

Having identified your risks and classified them as Stefano suggests (I always go for 3x3 matrix, with Hi, Mid, and Lo likelihood and impact, but 5x5 is OK too, though it's 25 boxes to fill in rather than 9) then for all the risks which it's worth bothering about (which is what your matrix tells you) then you have to define a risk mitigation plan -- what will the project do if the risk comes to pass ? Since risks are, by my definition, outside the control of the project, you can't plan to reduce the likelihood of a risk, you can only plan to reduce the impact or severity of a risk.

Never forget the following options for mitigation plans:

• Do nothing but worry (appropriately), plan and act in reaction to realised risk;
• Plan to let deadlines slip, costs to increase or deliverables to vary from specification.

Finally, make sure that your project sponsor (or whatever oversight layers you define) are fully briefed and completely in agreement with your risk assessment and mitigation plan. CYA.

There's lots lots more, but I hope that gets you started.

Regards

Mark

Answer 4

Great answers, great accepted answer from Mark, up-voted. Just a few extra words.

I disagree with the risk definition that includes only events outside of project manager's control. Risk is a possibility of any deviation from what is planned.

Risk management (apart from identifying potential deviations from the plan and appraising them using probability and impact) involves answering the two following questions:

1. How are we going to know if risk ever occurs or its likelihood and impact goes up or down? How are we going to know when some additional risks will emerge?

2. How are we going to handle any departure from the plan?

Both answers will be specific to your project.

Risk Monitoring

The first bit is also known as risk monitoring: putting mechanisms in place (i.e. regular reviews, feedback and feedforward loops, assessments and scheduling check points) to keep an eye on the risk profile. Monitoring the risks is actually by far the most labourous part of the risk management.

Risk Management Options

The question of how to handle an individual risk has a few broad options that might be combined to form an answer:

• Avoid the risk (i.e. if Jenny commutes to work and there is a risk of heavy snow that might prevent her from getting to her desk, telecommuting will eliminate the risk altogther).

• Mitigate the risk likelihood or its impact (move into warmer climate, install winter tyres, set up the dev enviroment in the way that Jenny can work from home when necessary)

• Transfer the risk (buy insurance policy, let a suitable external entity to do the risky bit, whereas telling Jenny to come to work no matter what won't really transfer the risk as it will remain with your project).

• Have a contingency plan (also known as Plan B: Bruce who normally sleeps under his desk anyway, will have to do Jenny's work in the event of heavy snow).

• Accept the risk. Frequently a low impact or likelihood might not be worth an effort, sometimes even though the risk cannot be managed in any other way the reward is still worthwhile giving the project a go risking to lose the investment.

Positive Impact

Since risk can be defined as any deviation from what is planned, the actual deviation may be favourable. I strongly recommend paying attention to such risks as well and including them within the overall risk management process.

If an opportunity comes you want to be prepared and able to seize it. If a Jenny finishes her piece two weeks early you don't want her spending two weeks idling when she could set up a project wiki, improve build process or re-work the installation routine.

If there is an unexpected opportunity to use an expensive piece of equipment (even if informally) for additional testing or meet up with a group of real users, you want to have the time and the man power to grab it by both hands.

Selecting Project Based on the Risk Profile

Another useful aspect of risk management is being able to select project portfolio based on project risk versus expected return.

Apart from comparing the potential projects to each other in terms of the risk and return, it's possible to set a hurdle rate — a higher return threshold for risky projects. The expected return of the project would need then to pass the hurdle rate before it is considered.

Risk management techniques can be applied to the entire portfolio, where a risk of entire project failing may be, for instance, deemed acceptable, as long as most of the remaining projects succeed, covering the losses made as the result of failure.

Answer 5

Great answers (up-voted). I have an addition regarding risk monitoring.

Usually every risk is judged by two parameters: impact and probability (as in Stefano answer). To assess which risks hurt us most we count risk exposure. It we use numbers e.g. 1-5 scale for impact and 0%-30%-60%-90% scale for probability we can just multiply both values to get exposure.

Among project team people would judge risks differently so everyone should give enter their own impact and probability values. Now you can count risk exposure set by every person in the team and find an average exposure for the risk. That's how team collectively perceives the risk. You can sort them descending to get top 5 or top 10 risks for the moment.

Risk exposure changes over time. Actually team has control (to some point) over risks. There are mitigation plans etc. What you need to do is to assess risks regularly e.g. weekly or bi-weekly. It takes everyone in the project team to give their "votes" for probability and impact for each risk. The list of risks with biggest exposure should change over time. At least if you deal with top few properly.

And the last thing - it's hard to deal actively with all risks. Most of the time you should focus on top few. When you're done with them their likelihood and/or impact should go down so they should leave a place for some other risk to make its way to the top.