Software risk management (SRM) combines a variety of tools, processes, and methods to manage software development lifecycle risks. At SRM, we want to make informed decisions about what can go wrong at different levels within the company (eg business, project and software related).
What is software risk?
Risk is the potential for loss that may or may not occur in the future. This potential is based on the likelihood of occurrence and the impact on the business/project and the software (time delay, financial loss, reduced performance, loss of reputation, etc.).
The five stages of the SRM process
The SRM process usually involves five main stages, which are as follows:
Stage 1: Risk identification
The first and most important step in the whole process is to identify the risks that may arise as part of the development process.
Step 2: Risk analysis
At this stage, the team determines the level of risk for each item identified. Risk probability determines the level of risk that will occur and its impact on the user.
As part of the analysis process, I instruct my teams to follow simple guiding questions. This allows them to obtain the necessary data to determine impact and likelihood, and then prioritize mitigation steps to limit risk. Here are some basic questions.
§ What reasons (design problem, unclear requirements, logic error, etc.) caused the risk?
- How does this risk affect business reputation, stock price, and early liabilities?
- How does the risk affect the project’s resources, schedule, and testing effort?
- How does the risk affect critical aspects of the application (functionality, user experience, etc.)?
- What value will we gain if we reduce risk?
- What is the probability (likelihood) of the risk materializing?
- What is the impact of this risk?
- What is the impact of fixing this risk (design change, additional testing)?
Stage 3: Mitigation
Based on the analyzed information, a plan is created and implemented to handle each risk with an appropriate set of actions.
Phase 4: Track/Monitor
Follow the series of decisions and actions taken.
Stage 5: Control
Correcting any deviations that occurred during the implementation phase.
Sources of risk in development projects
In Agile projects, both business and engineering teams must deal with risks arising from three possible categories:
In this case, the risks are known and become a fact that is transparent to all interested parties. Also, known risks are easiest for the team to handle because they can create a mitigation plan early in the project and avoid negative surprises. Let’s see some examples of such risks.
- Lack of resources to work on the project.
- Lack of automated frameworks to support testing efforts.
- Lack of knowledge and experience of developers.
Known risks with low probability
These risks are known and the team is aware of their existence. However, the team is not aware if this risk will occur in the project or not. Let’s see some examples of such risks.
- The use of new technology, which is not yet stable enough, is mandatory in certain development activities.
- An unresponsive customer means there’s a risk the team won’t get the feedback they need to deliver the right product.
- Working with an external supplier can cause long delays if not delivered on time.
These risks are a disaster waiting to happen, or what I like to call a “Ticket Bomb”. Unknown risks are dangerous because the business has no idea of their existence and where and when they will appear.
Types of risk in software projects
This section will provide examples of the different types of risks associated with software projects.
Risks that affect the business and project schedule
- Risks associated with misunderstanding project complexities.
- To secure a contract with customers, project timelines are shortened to impact software quality.
- Lack of customer feedback and ambiguous customer requirements.
- Risks associated with budget miscalculations.
- Inappropriate allocation of resources or underutilization of current resources.
- Risks related to internal policies that affect the flow of the project.
- Lack of collaboration between key stakeholders involved in the project (eg client, management, development teams, etc.).
- Failure to prioritize conflicts during the project.
- Lack of project planning creates gaps in development and testing.
Technical and technological risks
- Risks associated with poor product design affect the technical aspects of the software (coding, testing, etc.).
- Constantly changing requirements that add great technical risks.
- Lack of knowledge of the development team regarding the technology used in the project.
- Lack of training in unfamiliar technology used in the development process.
- Using new/untrusted/unstable technologies as part of the development process.
- Third-party tools/frameworks that failed to provide the expected solution.
Risks associated with the development team
- Testing and development activities are dependent on external resources.
- Tight deadlines affect the productivity of resources.
- Risks related to HR aspects of team members (e.g. lack of commitment, low motivation, lack of trust, etc.).
- Risks associated with poor engineering practices (eg, code reviews, use of incorrect design patterns, testing practices, etc.).
- Teams that are behind schedule and hope to achieve their result without reporting it.
Risk Assessment in the Scrum Framework
In Scrum projects, we can use the same SRM techniques used in traditional projects to reduce risks to an acceptable level. However, due to rapid releases and high rates of change, we need to adapt those techniques to be more suitable for the Scrum framework.
Using the SRM process helps the team develop a test strategy, identify quality risks, and evaluate the efforts required to mitigate those risks.
In Scrum projects, quality risk analysis occurs in three main places (although it can be used in many other activities as well):
- Release planning – As part of release planning, there is a high-level review of the features involved in the release, making it the perfect time for various stakeholders to share their technical, business, and project risks. Once the risks are identified, the team can start working on a mitigation plan and high-level test/development strategy.
- Sprint planning – The entire team works together to plan the upcoming sprint. During this process, the team identifies and assesses quality risks, which will directly affect which stories are added to the sprint backlog and what their estimates are.
- Sprint retrospective – At the end of this meeting, the team creates a list of obstacles that will be prioritized. The SRM process fits in perfectly here because it allows the team to prioritize obstacles based on the risk they add and their impact on the team.
Have questions Leave them in the LambdaTest community? Visit now!