Risk management in software engineering projects

Thus, every software development project potentially faces a significant amount of uncertainty. That is usually manifested in delayed deadlines, a high number of software bugs and defects, software does not meet customer expectations and thus not deliver customer satisfaction, to name a few. This aspect of uncertainty during a development project is considered a risk. Risk can be defined as a consideration that has some degree of probability of compromising the success of a software development process. That means the success of a project is somehow connected to the involved risk. Thus, risk needs to be reduced to a maximum.

Types of risk that can occur during a software development project

Thus, Managers use project plans, timelines, and budgets to reduce what we call “execution risk”. It means the risk that designated activities won’t be carried out properly. However, they often neglect the two other critical risks: The “white space risk” caused by the fact that some required activities won’t be identified in advance, leaving gaps in the project plan, as well as the “integration risk”, meaning that the disparate activities won’t come together at the end. So, project teams can execute their tasks flawlessly, on time and under budget, and yet the overall project may still fail to deliver the intended results.

Especially the use of advanced, and in some cases, beta technology on software development projects leads to many unforeseen risks. To complete a complex software development project within planned boundaries, risk on the project should be well understood and mitigated. But also minor aspects of software development projects could be influenced by risks, that could ultimately lead to project failure. For example, a developer might request vacation or sick leave, posing a risk for the project success if no other can take over their duty. Or in the other case, cost estimation from the beginning turns out to be completely wrong as the system architecture will require an additional hardware upgrade to keep up with customer’s webpage load. Further, other possible risks due to a missing backup policy or security policy can occur.

The main impact areas of risk

Formally, risk can be described as project variables that designate process success. The risk in this case, is the possibility of suffering a loss that described the impact on the project, for example, poor quality of the software solution, hard to use, increase cost, not scalable solution, a hard-coded solution of a more generic problem that requires a major software rewrite, delayed completion. That is why risk management should be an essential part of a software development project.

For most software development projects, we can define five main risk impact areas:

Avoiding risk during development projects

Several risks can be completely avoided by using different technologies, changing requirements or project plans. Risk can be confined in order to restrict the risk impact area to affect only a small part of the software development or to affect only a small percentage of customers using the product. One example is to apply the so-called “release revert policy”. That means, if something goes wrong after the deployment, the release could be undone, even before the customer could get affected by the error. This strategy could be applied when deploying a release outside of business hours (at night for example). Nevertheless, there are many risks that cannot be avoided or confined. In these cases, risk needs to be mitigated or monitored. Some risks during a project can be mitigated by creating a Proof of Concept (POC) and Software Prototypes to try out what risk can affect that piece of software and how likely it will materialize during production.

Risk can be identified and addressed in different phases of a software development lifecycle. However, it is essential to identify risks as early as possible and address them promptly because the related costs could be tremendous.

This process is very lightweight and very quick to perform. Identifying Risks early and implementing appropriate Risk Mitigation Strategies for each risk identified is essential to the success of projects. Done properly, it is a continuous virtuous cycle of Assessment and Action to constantly identify, manage and minimize Risk.

Software Risk Management

The process of risk management should start with risk identification. The purpose of risk identification is to discover all factors that could lead to project failure. Possible factors might relate to the technology and software language used on the project, the software development process (Scrum, Kanban, Waterfall, RURP, etc.) or organizational factors. These areas should be observed and assessed in order to capture all of the potential risks.

The second step of the software risk management process is to assess the level of exposure for each risk and prioritize them based on the impact they have on the project. Clear enough, the risk with a devastating impact should be assessed before risk with a low impact.

The next step is risk mitigation. Risk mitigation is an attempt to avoid or prevent the consequences of risk materialization. There are three main strategies for risk mitigation:

1. Risk avoidance
2. Risk reduction
3. Risk transfer

The best way to avoid risk is to completely reorganize the software development project, which is sometimes impossible. Risk reduction is the second-best approach and relates to preplanning the software development project. This helps to reduce probability of occurrence, introduce software resilience, monitor software performance and other strategies. Risk transfer could be described as a project reorganization strategy. The aim is to forward risk to areas where it would cause less damage.

The final step in the risk management process is risk conclusion. This step is taken after the definition of a risk mitigation plan and included in all the actions required for risk avoidance or actions, which are required after the risk materializes. The actions taken in the monitoring and reporting step should be defined in the contingency plan. The contingency plan should describe actions, which are taken once a risk becomes a reality.

A proper software risk management is important to deliver good software at a high-quality level. It will help to deal with threats and to exploit opportunities during the development process. By implementing a proactive risk management system, this support is provided and the risk of failing a project is reduced.