In this article, we discuss approaches to risk management in the software development process. We also pay attention to the importance of risk management from the business and development perspectives and even give an example of a risk management plan.
On November 12, 2019, Disney launched Disney Plus, a Netflix-like streaming service with original content. Thousands of users were ready to pay $7 per month or more to enjoy content by Pixar, Marvel, Star Wars, and many other franchises.
Eager viewers were disappointed to watch outage screens for days instead of the content they had paid for. Complaints ran the gamut, from difficulties logging in to an inability to stream, app failures, and shows and movies disappearing from the library.
Disney attributed these problems to demand exceeding its “high expectations.”
This is a classic example of poor technical risk management in software development.
Could Disney have avoided these outages? Yes.
Can you avoid similar issues? Also yes.
In this article, we’ll dive into risk management and risk mitigation in software development.
The importance of risk management
Every business is unique, and not all risks can be fully anticipated. But there are some approaches that help you to identify bottlenecks, calculate the possibility of risks occurring, and predict the negative impact if they do.
Risk management is a complex set of activities businesses can perform in order to avoid or ameliorate the effects of risks.
The purpose of risk management in software developmen is to know what can go wrong, why it can go wrong, what the impact would be if it did, and how to fix it. Forewarned is forearmed.
The advantage of proper risk management is that it helps a business to suffer less even when a risk materializes.
Risk management can bring the following advantages:
- Cost savings by cutting expenses on foreseeable and avoidable emergencies
- The ability to work faster by allowing development teams to concentrate on development, not on fixing unpredicted issues
- Smarter spending by not needing to attract additional funding to solve unpredicted problems
- A better reputation by ensuring clients that you’ve got everything under control even in an emergency
Types of risks
An inexperienced entrepreneur hopes that nothing bad will happen to their business. An experienced entrepreneur knows that something bad will happen and gets ready for it in advance.
So what could go wrong? Basically, anything. Various risk management approaches cover various types of risks. The most common categories of risks for businesses are:
-
Human risks — The sudden illness, pregnancy, arrest, death, or career change of a team member can lead to numerous consequences, from delays in performance to delegating functionality to other team members.
-
Location or geographical risks — Every location has its specific issues like the climate, political situation, time zone, and work traditions that can affect the workflow.
-
Strategic risks — Things like planning issues, choosing the wrong strategy, and poor management can’t be foreseen from day one, but should definitely be considered as a major risk factor.
-
Operational or management risks — These are very close to strategic risks but are more about execution: implementation issues, incorrect work dependencies, poor management, slow decision-making, wrong prioritization, and many other operational issues can delay business development or cost a fortune to overcome.
-
Legal risks — It’s good to study laws and regulations of particular regions at least to find out if you can do business there. Also, laws tend to change, which can often lead to tax changes and formalization issues. Legal risks also include changes to rules and regulations of business platforms like Amazon, the Apple App Store, and Google Play.
-
Technical risks — A chosen technology can look perfect on paper but behave differently in action. Constant updates, changes in operational environments, maintenance issues, and many other technical aspects can have a big effect on the business.
Depending on the type of business, many other risk factors may appear, and the factors listed above can change. But knowing these risks helps you choose a fitting risk management strategy.
Risk management strategies
Approaches to risk management differ according to numerous factors, but here are some of the most common risk management strategies:
Risk avoidance
This is a radical strategy where a business refuses to take a risk and declines to perform an activity.
There are kinds of risks where the price of a mistake is too high. For example, if you know the limits of a solution’s technical capabilities, it’s wise not to overload the solution with a high-load project. In this case, the cost of failure may be higher than the possible revenue.
In brief, sometimes it’s okay not to engage in some business activities in order not to fail.
Pros: Fast to implement — you just decline or accept the activity.
Cons: Leave potential revenue on the table.
Good for: Businesses with multiple branches and sources of income.
Use when: The harm from the possible risk is greater than the possible profit from the activity.
Risk mitigation
This is a strategy of making the negative consequences less severe rather than avoiding them altogether.
When operating a business that’s more complicated than selling lemonade in your front yard, you may face issues that you can’t avoid. In this case, it’s recommended to identify and mitigate the consequences of those risks.
This works for known specific risks, especially in software projects. Warn your clients about upcoming issues or offer a temporary solution. Clients may not leave satisfied, but at least they’ll feel the care you have for them. For example, McDonald’s gives out a coupon for free ice cream if you wait more than 90 seconds for an order.
Pros: You don’t waste your resources to eliminate the risk. Instead, you work with its consequences, trying to make them less severe, which is often much easier to do.
Cons: You and your client still have to deal with the negative consequences of the risk.
Good for: Businesses with loyal clients, businesses that are sensitive to timing, service providers.
Use when: The risk can’t be avoided completely but the service should still be delivered on time; emergency situations.
Risk transfer
With this strategy, you pay someone else to deal with the negative consequences.
If your business can’t handle a certain risk, get some help with it. This may be a very costly approach to risk management in software development, but the results can meet the client’s expectations and keep your business on the road. It’s also good in the context of freeing your crew from the dirty work they don’t want to do, leading to better concentration and resulting in better quality.
Pros: Simple and mostly fast to perform.
Cons: May cost a fortune, and you’ll have less control over part of your business.
Good for: Businesses with high load on some of it’s componentsor for implementing features for which you don’t have a lot of expertise.
Use when: An activity should be done well and fast, with no time to gain your own expertise or train your own professionals.
Risk acceptance
As the name suggests, with this strategy you just accept all the negative consequences of a risk.
There can be cases when the profit from a business activity is much greater than the impact of the possible risk. In this case, it’s okay for a business to just accept the risk. But users should be warned about the consequences of accepting the risk.
Microsoft uses this strategy when they stop maintaining old versions of products, like Windows XP.
Pros: Requires almost no resources.
Cons: You get all the negative consequences.
Good for: Established businesses where implementing new features is more important than supporting old ones.
Use when: An activity does no harm for the majority of users or when profit from delivered activity for user is higher, than possible inconvenience.
Note that none of these strategies is a panacea. Any other kind of risk can go along with technological risk and influence the result of your work. And in most cases, the risk management strategy for a particular project will be a mixture of the strategies above, taking into account the special aspects of the business.
How to manage risks using an agile methodology (example)
This is how a software development risk management strategy may look at Mind Studios.
Phase 1. Identifying the risk
When: During the project evaluation stage
During this phase, the project manager gathers the team of developers and designers for a brainstorming session, looking for all the possible risks and what can trigger them.
Necessary steps:
- Recall the problems we’ve had in previous projects; try to discover all known unknowns
- Define the areas where any kinds of risks are likely to occur in this particular project
- Evaluate the impact of every factor we might face while developing the product
Phase 2: Analyze and assess the risks
When: Right after the project evaluation stage
In this phase, risks are identified and then categorized. Here, project managers also analyze the possible impact of a risk and the probability that it will occur. In this phase, it’s good to take into account the complexity of the project, testing qualities, and dependencies between development teams.
The result of this phase is a list of defined consequences for every kind of risk:
- Possible losses for the customer
- Possible issues for the business
- Reputational losses
- Legal issues
Phase 3: Create a risk management plan and approve it with the client
When: Right before the start of development
During this phase, project managers formalize risk management activities into plans. Usually, the risk management plan for a project is a table with the following columns:
- Risk definition
We define the problem that could occur and describe them in one short sentence. The definition should clearly be understood even at a glance, so we tend to describe the problem in the shortest way possible: “lack of server power,” “unable to upload user content,” “Play Store release delay,” and similar descriptions are clear and focus on the problem.
- Trigger
We describe how we can know if the risk has materialized. What exactly will tell us about the problem and how it may look? If the trigger can come from different sources, we should name them all. It’s okay to prioritize the list of trigger sources by probability or value.
- Probability (score)
We define the possibility of a risk occurring. Depending on the number and importance of possible risks, we suggest the maximum and minimum score — for example, 100 and 1. A more probable risk gets a higher score.
- Impact (score)
In this column, we score the severity of each type of risk.
- Value (score)
We define how significant a particular risk is for the project. A higher number means a higher priority. At Mind Studios, we usually define the value of a risk by multiplying its impact and probability scores. But you’re free to define this value as you wish based on the requirements in software development and particularities of your business.
- Main strategy
We name the primary strategy or approach we’re going to use in order to manage the risk — for example, transfer, mitigate, or accept.
- Alternate strategy (if available)
In case the main strategy is not acceptable, we name a secondary strategy. For example, if a risk can’t be transferred at the moment, we can launch the mitigation process. We recommend creating as many strategies for every kind of risk as possible.
- Action plan for the chosen strategy
This is the most detailed part of the strategy, where we create a step-by-step guide for its implementation. As a result, we should get a clear plan for what we’re going to do in case every kind of risk occurs. We number the steps, include contacts of involved and responsible people, and write out every step as clearly and in as much detail as possible.
We create action plans for all the main and alternate strategies we consider for our projects.
Here’s an example of the technical risk management plan we use at Mind Studios:
Phase 4: Monitor the risks
When: In the background from day one; check after every development sprint
There’s no guarantee that a solved risk won’t come up again. That’s why risk monitoring should be integrated into the list of activities for software projects. Triggers can also be identified from user feedback and QA reports. Include risk monitoring activities into every further development sprint.
All risk management activities should be agreed with the client, especially when outsourcing software development. All costs, materialization probabilities, and degrees of severity should be as clear as possible — the client should know what they’re paying for and who’s in charge of every type of risk. Find an acceptable compromise with the client’s expectations and client’s budget.
Business risks
The conversation about risk management in software development can’t be complete without mentioning business risks. It’s good when you’ve coped with project risks like those mentioned above. But imagine being in the middle of development and finding out your competitor is going to release a similar product faster or with a killer feature. Finding yourself in this situation means you’ve forgotten to take care of your business risks even if you've also not been doing well with your project risks?.
A business risk is anything outside of your business that threatens the goals or targets of your business. It may be a sudden change by a competitor, by a regulatory body, or in the economy — or any number of other things.
Managing business risks entails a whole bunch of other steps and phases that are worth another article. But here are some general tips:
- Keep an eye on the market
Having a brilliant business idea doesn’t guarantee that someone else doesn’t have a similar idea. Do regular market research and analytics in order to know the state of the market and keep an eye on your potential and active competitors.
- Work on your product–market fit
Be sure your product will satisfy strong market demand. If new market conditions affect the performance of your business, you should reconsider your product-market fit. Be agile not just in product development but also in business development. Improve, innovate, and don’t hesitate to pivot.
Risk mitigation in software development: Conclusions
In general, proper risk management in software engineering helps you concentrate on working on your product. With proper risk management, more resources are focused on creating better functionality and higher quality products instead of overcoming the consequences of risks.
Developers who perform risk management can work more on what they love, and business owners who perform risk management get happier clients, a better reputation, and more place for creativity.
Still curious about how to manage risks in your particular business? We can help!
If you’re concerned about the risks in your software projects, Mind Studios project managers will be happy to share their expertise! Get in touch.
Written by Tymur Solod and Alexander Vasyliev.
