- What are the 5 phases of the system development life cycle?
- What practices will help you mitigate risks?
- Core problems with software risk management
Risk is the potential for a problem that can cause the loss of something valuable. Unnecessary risk can cost you time and money, especially in the IT industry where most software projects have some element of risk. In this article, we’ll provide you with an overview of risk management in software development, and share the experience of our project managers who are experts at identifying, assessing, and mitigating software risks.
The best practices of IT risk management include minimizing risk factors in the software development lifecycle (SDLC) in order to develop a system able to counter and mitigate risks when necessary.
What are the 5 phases of the system development life cycle?
The SDLC has five phases: inception, design; implementation, maintenance, and audit or disposal, which includes an assessment of the risk management plan.
- The phase of inception includes the planning and requirement analysis, and the creation of a rough draft of the system including identification of the possible risks. This is also the first step for risk management where project managers identify and prioritize risks.
- The design and prototyping phase of SDLC is when the system designers take into account possible risks, so the list of potential risks the system has to deal with is formed at this stage.
- The implementation of the software development phase includes the system configuration and creation of functional software, testing, and verification. Here the system is tested against the risks identified in the previous two phases.
- The maintenance phase includes debugging and updating if new risks are identified they have to be included in the system modules.
- The audit phase includes the risk management plan assessment and any necessary refinements. Any substantial changes in risk management are then incorporated into the updates based on system audit results.
What practices will help you mitigate risks?
First, you have to assess risks and build a risk breakdown structure, which facilitates better and more enhanced analysis.
Phase 1: Identify the risks and their sources
Here are simple drills that will help you in the process of risk identification:
Drill 1 – Do these scenarios entail positive, negative, no risk at all, or a critical risk?
Drill 2 – Where does this risk come from?
Phase 2: Identify the risk response strategy
Drill 3 – Select the risk response strategy
Drill 4 – Reserve for possible losses
PMI lists 6 basic strategies for negative risk response:
- Avoidance is the most preferable strategy which implies complete avoidance of possible risk or its impact on the project. Prototyping can be a good example of this strategy.
- Mitigation strategy allows for decreasing the risk impact on the project. For example, proper planning and involving people with similar skills allows for the substitution of team members in case of illness.
- Transfer strategy implies transferring/delegation of responsibility for the risk to a third party. For example, the risk of fire on the premises can be delegated to an insurance company.
- Escalation strategy usually refers to the level of programs or portfolios, not a project. It refers to risks that are identical or similar for a customer’s whole portfolio so it is reasonable to solve such problems at that level.
- Active acceptance is the creation of reaction plans that help you determine what to do if this risk occurs, and how to allocate proper resources to it. It is the simplest and the most wide-spread strategy.
- Passive acceptance strategy means accepting the risk. It may sound apocalyptic, but these days we face a similar situation as the coronavirus pandemic impacts economies around the globe.
Phase 3: Software risk planning
Software risk planning includes finding preventive measures that can decrease the likelihood or probability of various risks. Here we also define measures to decrease risk impact if it occurs, while constantly monitoring the development process to identify new risks as early as possible.
Phase 4: Software risk monitoring
Software risk monitoring is included in all phases of product development, and checks must be done on a regular basis. The team should track major changes in the risk management plan, and prepare reports for project management. The risks should be reviewed, and those with the lowest possible level of impact probability should be closed. New risks should be researched, and avoidance, mitigation, and contingency plans should be formed.
Core problems with software risk management
We asked Vladimir Tutov, an Archer Software Project Manager, to comment on core problems arising out of inadequate software risk management.
The core problem when working on risk management is that most people don’t use a systematic and consistent approach to risk management. Very often, software development companies try to manage risks when they have already occurred, and this is a fundamental error. You have to manage risks constantly, identify new risks/threats at the start of a new sprint (in Agile teams), create risk management plans, and provide resources. (I.e. you have to manage the possible risks irrespective of how well or bad it looks to the business.)
You have to involve the whole Agile team in the risk management process as every member of the team has a piece of knowledge that can identify possible risks of the project. This is a good opportunity to uncover the problems which can be missed otherwise.
Every new sprint starts with the identification of tasks and possible problems related to them. There are several questions you need to address:
- What does the task consist of?
- What can go wrong?
- What are the key risk sources? For example, the problems related to communication with the client, the problems related to insufficient requirement descriptions, problems related to third-party services, or external factors (for example, COVID-19 related problems). The list of risk sources must be updated on a regular basis.
After the risks are identified, risk management measures are included in the sprint plan. For example, if you identified a risk where there are inconsistencies between the front and back end of the system what actions should you take? You have to clearly define APIs and formulate a corresponding document, add the task to your sprint so your team sees it, and determine who takes part in the risk management process.
If you want to know more about risk management assessment, get in touch with us at firstname.lastname@example.org.