Risk Management in Software Development
If you were to ask a group of IT, project managers, for their very best piece of advice for those running a software development project, it’s highly likely they’d say: “Make sure you have a risk management plan in place”. And it better be a GREAT one, at that!
- Risk management is an indispensable part of any successful software development project. Today we introduce a list of best practices for risk management in software development.
In fact, many a cautionary tale can be found online when you search for examples of bad risk management planning.
There’s the famous Wells Fargo fiasco, where the CEO admitted to not knowing about a major data breach until it had already scaled to a nation-wide crisis. And then there’s also the Panama canal failure, where engineers thought they knew how to build a marine passage through the depts of the jungle just because they’d previously drilled the Suez canal. The list of poor risk management examples goes on and on.
Point being — make sure that you’re not merely learning from your mistakes, but are also prepared for handling them in a timely manner when they do happen.
With this in mind, we’ve put together a list of best practices for risk management in software development. Whether you want to control risk on an internal project or are looking for a way to work with external contractors, follow the tips below to minimize the occurrence of software development disruptions.
Let’s get to it!
Risk management — software development best practices
For starters…
#1. Create a list of potential risks on your project
You’ll likely be able to list down a couple of risks right from the top of your head. Others will require scrutinizing all aspects of the software you’re developing — perhaps, together with other members of your team who have more expertise.
Once you’ve listed all the potential risks, you should categorize them according to type. This is the first step you need to take to track risks throughout the entire project.
So, how do you categorize them best?
Ian Sommerville, a software engineering professor and systems engineering researcher, suggests breaking them down into the following groups: technology, people, organizational, tools, requirements, and estimation.
You can read more about the categorization process in this great resource.
#2. Analyze the probability of each risk
Think of it this way:
If the risk were to turn into an actual problem, would it entirely halt software development, slow it down, or merely provoke a quick change here and there?
While you can find many prioritization methods online, one recommended way of ordering risks according to their potential impact is: catastrophic, serious, tolerable, and insignificant.
Once you’ve given an appropriate ‘grade’ to each risk, also make sure that you can easily sort them from most threatening at the top to those of trivial importance at the very bottom.
#3. Create an action plan for each risk you define
Do you know the saying “hoping for the best, but expecting the worst?”.
Sometimes, despite our best efforts to foresee and nip problems in the bud, we will have to take action.
Use the list of risks you’ve prepared and made sure you have a mitigation strategy listed down in case any of the risks turn into a burning problem. This way you’ll also be able to quickly onboard anyone else engaged in solving the issue.
We recommend that you create a spreadsheet that features the following columns:
- Potential risk description
- Risk likelihood (you can use the scale we mentioned above or a scale from 1–10)
- Owner of the subject
- Actions that need to be taken to reduce the risk
- Actions that need to be taken if the risk turns into a problem
- Future control measures (if the risk came into life, how it can be prevented in the future)
In most software development teams, it is the Project Manager’s or QA Specialist’s job to maintain and update such a file on an ongoing basis. Which leads us to…
If you want to read more, click here.
