...

Managing risk: measurement, mitigation – and opportunities

The phrase, ‘There are no problems, only opportunities’ is a cliché – because, we believe, it’s often true. In many cases, when it comes to risks inherent in a project, we can also identify an opportunity hidden within.

Here, we tackle the tricky topic of risk…

Whether you’re developing software or sending a person to Mars, there’s always a fine line to tread at the start of every project: between optimism and pessimism.

Naturally, everyone involved will be hoping and working for the best possible outcome. But unless there’s a keen awareness of what could go wrong – whether you want to call that pessimism or realism – it’s highly likely that some poor outcomes will result.

This is why effective risk management is vital when it comes to delivering great software on time. And, as with many other considerations – such as managing scope and quality – doing it well means taking a holistic approach from start to finish, and beyond.

It’s important to point out that, if you continue reading this article, you may end up with a sense of foreboding, worrying that every project is fraught with dangers waiting to derail it. And it’s true that even the simplest undertaking can have inherent risks that threaten to compromise quality, cost or delivery times.

However, we spend a lot of time predicting and assessing those risks to help avoid problems before they occur; or, if they do materialise, to ensure we can mitigate against them in a way that will result in minimum impact for our customers.

In other words, we spend a lot of time thinking about risks, and how to manage them, precisely so our customers don’t have to.

In every software development project, there are usually three major types of risk to consider, as follows:

1. Scope

This could include changes to the scope, or adding new requirements, once a project has already begun. For more on this, see our article on this topic .

2. Technology

This could involve, for example, incorporating new technologies and new practices, or changing the platform on which we are working.

3. Dependencies

This generally revolves around the interdependencies between teams, and is an area we focus on strongly. We might have, for example, a dozen or more teams working on a single project, so frequent and clear communication is essential to avoid blockers. We’ll therefore sequence and synchronise our schedules so they are complementary to each other, while constantly keeping the lines of communication open. 

At the start of every project, we’ll create a risk mitigation plan based on a combination of our own experience and empirical data.

To do this, firstly we’ll identify the risks and assign each one a score – assessing its possible impact on a scale of one to five, and the probability of it occurring on a scale of one to four. Multiplying those two values gives us a risk score from zero to 20, with 20 being the highest possible.

That gives us a clear idea of what to focus on. Then we’ll plan how to avoid those risks and also pinpoint the signs that help us to spot a problem at the earliest possible stage. Our overall aim is to steer clear of situations where people just hope for the best because they want to report good news to the management – maybe because they’re under pressure to deliver by a certain time.

In our experience, it’s always better to have the risk discussion at the beginning of a project so we can develop a realistic plan, rather than end up making excuses for failure throughout. That’s why it’s so important to think through risks early on, and to keep updating the risk assessments, as risk management is an ongoing process throughout any project.

A good example is the introduction of new technology, which often carries its own risks. A proactive approach, such as ‘spiking’ – in other words, taking a couple of people aside and testing it well in advance of the project deadline – is an effective way of managing it. I’ve worked on many projects in the past where our first choice was wrong and the tech we were planning to use just wasn’t going to work for us – which is exactly the kind of risk that spiking can help to avoid.

The phrase, ‘There are no problems, only opportunities’ is a cliché – because, we believe, it’s often true. In many cases, when it comes to risks inherent in a project, we can also identify an opportunity hidden within.

The methodology we use to assess levels of risk allows us to calculate both negatives and positives. For example, making certain technical changes may pose a short-term risk because we need to alter the scope of a project to accommodate them. But in the longer term, those changes may help us to build a solid platform that will accelerate the development of additional features.

By using the same methodology for opportunities as for risks, we can gauge how one is balanced against the other – and if the gain score is higher than the risk score, it’s probably worth considering.

As always, the great benefit comes from close collaboration with our customers so we can truly understand their requirements and how we can create value for them. Then we can effectively measure the risks worth taking and ensure we deliver the best possible outcomes.

If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now.

Iain Bishop, founder and CEO, Damilah