How do you identify and manage risks in software development?

Having considered the top 10 risks in software development, particularly those existing around the scoping and estimation process, we must ask ourselves - how can these risks be best identified and most effectively managed? Murphy’s Law famously states that “anything that can go wrong, will go wrong.” Applying this to software development, any project can overrun a budget, fall behind schedule, or fail to meet a customer’s requirements and expectations in an indeterminate number of ways.

Typically, any risk in a software project can arise from three possible cases. Known knowns refer to those risks that are facts known to the team and entire project, whilst known unknowns represent those that the team might be aware of, although it is unknown whether or not such a risk exists in the project. Finally, unknown unknowns are those risks about which the organisation has no idea, explored further in our article on how to manage expectations around uncertainties in software development.

For a successful systematic risk management plan, you must consider measures for both risk assessment and risk control. As an example, Dr. Richard Fairley, principal associate of Software and Systems Engineering Associates, identified the following seven steps of his own risk management process in software development:

1. Identify risk factors. Any risk is a potential problem, and so if it eventuates, it can be properly mitigated by relevant planned corrective actions.
2. Assess risk probabilities and effects on the project. For instance, a failure to meet one or more of these criteria within the constraints of schedule and budget can be indicative of a crisis for the developer, customer and/or user community.
3. Develop strategies to mitigate identified risks. As a risk typically becomes a problem when the value of a quantitative metric crosses a pre-determined threshold, it is essential to not only set these thresholds, but also plan the relevant corrective action(s). Within this, action planning aims to address any risks that can be mitigated by immediate response, whereas contingency planning should handle risks that require monitoring for some future response should the need arise.
4. Monitor risk factors. Monitoring the values of your risk metrics is crucial, ensuring that the data is objective, timely and accurate.
5. Invoke a contingency plan. This should represent your threshold plan that is invoked when a quantitative risk indicator crosses a pre-determined threshold.
6. Manage the crisis. In the situation that your contingency plan fails, there must be an additional plan for seeing a project through as it enters crises mode.
   Recover from a crisis.

Risk assessment using a multiplier

For any software project, a significant amount of risk can arise from the implementation of requirements or user stories that may be more complex and unfamiliar than usual.

Using both complexity and unfamiliarity as multipliers, the risk associated with implementing a particular requirement can be effectively quantified using a number rating between 1 and 5 for each. Once you have considered each of these factors, both can be multiplied together to give a total risk score out of 25 that can be applied to the time estimation process.

Unfamiliarity

The unfamiliarity component in the following risk multiplier takes into considerations the unknowns your team may encounter during a project. As part of the estimation process for each task, the team members should consider their experience with similar tasks, available resources, and whether it uses new or existing technologies. For example:

• If the developers have worked with the technology before and are quite confident, then the risk score would be low (probably 1).
• If the developers haven’t worked with the technology, but someone else in the company has, then the risk score would be moderate.
• If no-one in the company has ever worked with the technology before, then the rating would be quite high (probably 5).

Complexity

The complexity multiplier quantifies how intricate or challenging a certain task might be. When estimating, the team should consider how many other parts of the product are affected by this task, how complicated the development will be, and how likely this requirement is to change (i.e. how confident the customer is about this task, and whether new information may come to light and change it). For example:

• If the story uses a feature which has been developed in the past and it won’t require any changes, then the complexity would be low (probably 1).
• If the story can use an old feature, but it would need modifications to meet the requirements, then the complexity score would be moderate.
• If the story requires completely custom development and extensive testing, then the complexity score would be quite high (probably 5).

Why a successful risk management plan is crucial for any software project

As software projects by their nature are high risk activities, you should always consider implementing a systematic risk management plan, which can lead to a range of project and organisational benefits including:

• identification of favourable alternative courses of action;
• increased confidence in achieving project objectives;
• improved chances of success;
• reduced surprises;
• more precise estimates (through reduced uncertainty);
• reduced duplication of effort (through team awareness of risk control actions).

Software development is like any other project with inherent risks of not achieving its objectives, and so a risk management plan is crucial towards ensuring time, cost and quality of your project.

Written by Christine Chien

Marketing Operations and Partnerships

Our very own Christine is a marketer by day, nerd by night. If she isn’t developing our marketing strategy, she is usually found by her 3D printer or at a local plant shop.