Risk analysis in software development

Risk is something that can unite a business. Getting risk analysis right means talking about risk in ways that speak to your board, finance team, product team, operations team, software team, hardware team, marketing team, and sales team. 

What risk gives us is a ubiquitous language to talk with everyone and unite them in achieving the same goal. 

So, it pays to get it right from the outset. Here’s how. 

What is risk analysis in software development? 

First, we need to consider what risk is. 

Risk in software development 

In the book Embedded Software Development for Safety-Critical Systems, Chris Hobbs points out that depending on the standards you’re familiar with, how you see “risk” discussed in one standard may vary in other standards. 

But for our purposes: 

Risk is the assessment or probability of a hazard happening, and the overall damage it might cause to your organisation or the end customer/user (harm). You complete “risk management” and “risk mitigation” to decrease the chances of hazards and harms. Hazards and harms could lead to: 

• Loss of reputation 
• Loss of market share 
• Financial loss 
• Legal action
• Damaged health 
• Destruction of property or environment 
• Project delivery delays 
• … and more 

The language of risk offers an effective communication tool for use across all your stakeholders, along with product and software teams, and other groups or levels in your business. You might use a risk register to help communicate hazards, harms and the probability and impact of these things. 

A hazard is something that could happen and cause harm. Hazards are not all equal, because some are more likely to cause or could cause worse harms than others. 

A harm is the potential outcome of a hazard occurring. Such outcomes could include system errors that just limit normal function or temporarily stop it, and go all the way up to injury, or death. 

Hazards and harms can be caused by software bugs or poor usability. They can also be caused by not paying enough attention to a product’s market space and what competitors are doing. 

So, what is risk analysis in software development? 

Risk analysis in software development is a safeguard to innovation. It offers an overview of what could happen and its impact. It considers: 

• Risk assessment (identifying hazards and harms) 
• Risk management (policies and processes for handling risk) 
• Risk communication (talking with the wider business about risk) 

It’s not about stopping innovation; it’s about ensuring teams have the right conditions to make it happen. 

It’s impacted by internal and external conditions. Internal goings on in the business (for instance, team dynamics), and external goings on in the wider world (markets and regulations). So, risk analysis looks at those internal and external factors and sets them out in a way that all teams can understand. 

Why do you need risk analysis? 

Risk analysis helps to get you to think about and see where there might be risk, helping you to gather evidence for how you solve a problem. And while it has a bad reputation, risk is not, in and of itself, scary. You’re doing an analysis so that you’re better prepared for what might be out there. 

A good risk analysis brings a layer of protection against unknown unknowns (things you don’t know about but could affect your project) coming to destroy innovation. So, it’s a lot like the start of 1986 videogame The Legend of Zelda where an old man gives Link a wooden sword, telling him: 

“It’s dangerous to go alone! Take this.” 

Your risk analysis is that wooden sword and it’s going to help you take on the monsters that can stomp all over a project. 

(Plus, it can help you to get funding if you’re a startup, or convince your board to invest in a new project if you’re an established company.) 

Discussions around risk benefit from psychological safety 

Regardless of how you go about completing your risk analysis, to have an open conversation about it you need psychological safety in the workplace. 

By having psychological safety in place, where people feel comfortable helping you to innovate and challenge you or the wider business, you can de-risk the conversations you have about risk. 

People will be more honest and open when you have psychological safety present. With it in place, you’ll have productive conversations that people want to take part in. 

The temptation to go technical only 

There’s a temptation to see risk analysis as something that focuses only on the technical side of a product, at least when you come at it from a software or hardware team. But the problem with only taking it from that approach is that you lose access to having ubiquitous language that can help you get stakeholders on board when you need them most. 

Sure, your software team might need to carry out a failure mode and effects analysis (FMEA) to highlight hazards and harms from a technical perspective. And you can still do that, but it’s worth looking to another form of analysis to ensure everyone across the organisation is on the same page. 

We’re talking about a SWOT analysis. 

How to do a SWOT analysis 

A risk analysis tool most often found at home in the depths of marketing teams, a strengths, weaknesses, opportunities and threats (SWOT) analysis offers an easy starting place to identify risks. Strengths and weaknesses are internal factors, while opportunities and threats are external factors. 

In fact, your marketing team could very well have one ready to go on your product. (You should go ask them.) If not, here’s how to do one. 

And by the way: don’t make your grid restrictive. Allow for plenty of room to thoroughly analyse each square. You could consider using a virtual board like Miro to enable plenty of adjustable space. 

Start with threats and opportunities 

If you’re familiar with SWOT, you might be confused by why we’re reversing the order here. As Laurence Minsky and David Aron explain in this article for the Harvard Business Review: 

• The “environmental conditions” you face exist for you and your competitors. 
• Because your business does not work in a “vacuum” understanding its “context” helps you figure out what internal factors are applicable to a project. 
• By looking outwards first, you should end up thinking “more broadly” about what’s happening internally, reducing bias and stopping yourself from jumping to solutions first. 

Or 

“In other words, taking this approach can lead you to uncover internal factors that you might not have otherwise considered.” 

Source: HBR 

So, gather up your points around these external issues, ignoring whether they are positive or negative. As Minsky and Aron suggest, you could use techniques like PEST, PESTEL or STEEP, or others, to discover these issues. 

After getting these together, it would be good to work as a team to develop the rest of the SWOT and making sure you didn’t miss anything out. 

Add strengths and weaknesses 

Again, at this point you should ignore whether these points are positive or negative. Detail the internal issues or conditions that affect this project, like Minsky and Aron say: 

“Don’t settle for one- or two-word descriptors like ‘price’ or ‘technology.’ Explicitly spell out the situation with a detailed phrase or a sentence.” 

Source: HBR 

For instance, aside from you and your team, no one else might understand what “technology” means as a strength or weakness. Is it a specific patent? Is it an existing stockpile of a particular piece of hardware that would help you balance the books by being used instead of buying in new? 

By being verbose you and your team ensure that other people in the business understand what the issue is. 

Once you’ve filled out the full SWOT, you can use it to make recommendations. 

Write recommendations based on SWOT analysis 

The format these recommendations take should borrow from the items you’ve put on your SWOT grid. 

Minsky and Aron recommend wording your recommendations like so: 

“Given the condition of [external factor], our ability to [internal factor] leads to our recommendation that we [recommendation].” 

Source: HBR 

An external factor will be from your items aligned on opportunities and threats, while internal will be from strengths and weaknesses. 

For example: 

Given the condition of the semiconductor shortage and how much it is hampering supplies of newer chipsets, our ability to use existing chipsets leads to our recommendation that we work to ensure the device can run on our existing stock helping us to combat supply issues and keep costs down. 

(Here, the risk is lead time schedules for manufacturing. The semiconductor shortage is a hazard that could lead to harming manufacturing ability.) 

And that could lead to: 

Given the condition of the semiconductor shortage and how much it is hampering supplies of newer chipsets, our ability to develop software with habitable code leads to our recommendation that we ensure we write software with high conceptual integrity so that we can more easily port the software when supply issues are resolved. 

(Here, the risk is creating code that can’t be ported to other chipsets. The semiconductor shortage is a hazard that could lead to harming software portability.) 

Keep looking through the factors you’ve listed out until you think you’ve made as many reasonable recommendations as you can. Check these recommendations with your team before presenting them to the wider business.