What Is Risk Analysis and Why Is It Important?

Risk analysis can mean a variety of things to different individuals. So how do we look at risk analysis as it relates to software development? First, let's consider two examples outside the world of computing.

Early humans

Our ancestors learned about risk the hard way when it came to survival. Whether it was hunting down bigger, tougher wild animals or eating a berry that might be poisonous. Ultimately, they learned the extent of our capabilities as a species through this trial and error. They learned how to take measured risks - what was worth the risk and what wasn't.

Modern life

Today, we are always weighing up options and choices, and sometimes regretting our decisions. When you leave home and see dark heavy clouds overhead - do you take a gamble that it won't rain, so you don't have to carry an umbrella everywhere, or do you take an umbrella just to be on the safe side? That's an example of risk analysis.

What is risk analysis in the world of software development projects?

Risk analysis is a set of activities where risks facing a successful software project are identified, categorized and ultimately acted upon. The aim is to reduce the chance of these risks turning into issues.

Note that I say reduce rather than prevent, because in many situations it's impossible to be 100% certain that a risk will never turn into an actual issue - sometimes mitigating risks is the best we can hope for.

Are there any interesting facts about risk analysis?

Did you know there are a set of international standards defined for the management of risk? The most relevant is probably ISO 31000. You can read ISO's definition or learn more from Wikipedia.

Many training courses and certifications exist and companies sell risk management products as well. Clearly this is an important sector in IT. There is even a conference dedicated to risk!

How do we "do" risk analysis?

1. Identify the risks
2. Determine the impact and probability of the risks becoming issues
3. Take necessary measures to counteract those risks

Let's break things down a little bit to help understand each item better.

Identify the risks

It's useful to know the types of risk that exist. Knowing the categories will help team members bring up a wider set of risk items. 

Notice that the three risk types above are quite broad and have some interlinking between them.

You should consider the outcome if any of the above risks become issues around:

• project;
• delayed delivery/release;
• cost increases;
• product;
• quality compromised;
• technical complexity increases;
• business;
• project is shut down or product cancelled; or
• reputation impact to the company.

When you carry this exercise out as a team, spend 5-10 minutes thinking about, and writing down on sticky notes, any and all risks you think could directly or indirectly affect the project. I recommend you stop when a minute has passed since the last time someone wrote an item down.

Impact and probability

Having a list of all the risks in your project is great. But the value of this is incomplete until you know and understand how serious each risk is and how likely the issue is going to happen.

There's a few different ways to carry out this exercise. Here are two:

• For each sticky note, team members vote on impact and probability separately. The ratings can be on a scale of 1- 5 (low to high). The most common value is the value that is written on the sticky note (this may require a member of the team to explain the risk before voting takes place).
• The team discusses each item and tries to agree upon a value through debate and consensus (this might take some time depending on the number of sticky notes).

Taking action

Next take a look at all the risks as a whole and reorganize them in descending order of critical impact/probability. Take 5-10 of the most urgent items at the top of the list and discuss them as a team. Think about what you need to do to ensure the risk doesn't become a real issue.

What proactive measures can be taken? Consider writing them down as stories/tasks on your team's agile board (perhaps in their own swim lane) and ensure they are assigned to someone. Treat them seriously, like you would any ticket that's on the board.

Ask if everyone agrees on what actions should be considered if the risks do become issues. Sometimes it's important to ensure everyone is on the same page.

Easy and effective

As we've outlined, risk analysis does not have to be complicated. Taking the necessary time and effort required to perform risk analysis can ensure a project's success. The results will speak for themselves.