SOFTWARE : STRATEGIES FOR RISK MANAGEMENT

By June 20, 2015

 

In this chapter, we present three strategies for risk management. These strategies are defined in order to support various types of software development projects according to the amount of risk influence. Based on the amount of risk on a software development project, we define three risk management strategies: (1) careful, (2) typical and (3) flexible.

Careful risk management strategy is intended for fresh and inexperienced organizations whose software development projects are connected with new and unproven technology. Typical risk management strategy is defined as a support for mature organizations with experience in software development projects and used technologies, but whose projects carry a decent number of risks. Flexible risk management strategy is engaged in experienced software development organizations whose software development projects are formally defined and based on proven technologies.
Careful risk management strategy should be used on state of the art software development projects, which are completely unknown to the organization. This risk management strategy should be used on a software development project with high acceptable risks, new technology and inexperienced people. Careful risk management strategy could be described as high priority risk management. Risks on software development projects, with an implemented careful risk management strategy, should be taken with utmost importance. This requires rigorous risk analysis on multiple levels. Risks should be analyzed and traced on individual, team and organizational levels. In order to identify important risks as soon as possible and on a wide problem area, every project team member should be involved in risk management. This means that every project member should identify and define risks connected with his problem area, but risks should also be identified and defined on the team and organizational area. Risk mitigation strategies must be defined for each organizational level.

In order to successfully implement the risk management strategy, an organization should define risk management roles on the software development project, i.e. there should be project members whose primary activities are connected with risk management. Since careful risk management strategy is connected with an extremely high number of risks on a software development project, an organization should formally define risk interpretation and ranking policy. This should help to separate the important from the unimportant risks in order to address important risks as soon as possible. Project team members should continuously trace risks and actions connected with risks. Work on software development must be ordered according to project risks, i.e. risks with high importance should be solved first.

This requires constant planning and project supervision, but with this approach, risks will be mitigated in the early phases of software development, when the cost of a software development project is still small. Along with constant risk identification and project planning, the risk list should be reordered every time a new risk is identified because the most important risks should be first on the list. Each risk ought to be formally well-described and risk mitigation and contingency strategies should be defined. Careful risk management strategy is dedicated to the software development project under high-risk influence and, with this approach, risks can be well-understood and addressed on time. Activities of careful risk management strategy are presented in Fig. 1 using UML (Unified Modeling Language) Activity Diagram (Larman, 2002).

Typical risk management strategy is intended for mature software development organizations with experience in software development. This risk management strategy should be used on software development projects with a certain level of known technology and mostly experienced people. The level of acceptable risks for this strategy is medium, i.e. there are risks, which could be considered as too harmful, and projects with those risks would be cancelled. With this strategy, risks should be identified in steps according to project progress.

The main difference between careful and typical strategy is in risk importance because the typical risk management strategy assumes that most of the risks on the project are easily addressed, while the careful risk management strategy assumes a high number of dangerous risks. Risk management should mostly be practiced on the team and organizational level because risks on a well-defined project are connected with the entire project area. This risk strategy does not require project roles responsible for risk management because risks should be identified by the project management team and occasionally by project team members. As with the careful risk management strategy, risks should also guide software development in order to early address important risks, but because a relatively small amount of risks have an influence, project plans should be stable and only sporadically changed. In this strategy, risk interpretation and ranking policy is less formal because risks should be defined and ranked by the project management team. This strategy is intended for software development projects connected with mostly known technologies because this strategy should handle sporadically materialized risks. Activities of the typical risk management strategy are presented in Fig. 2.

Flexible risk management strategy is defined for a mature organization with formally defined software development projects, which use known and proven technology with efficient organization. This strategy assumes a small number of acceptable risks, which are mostly transferred to other organizations. Flexible strategy requires a relatively informal risk definition, with risk mitigation and contingency plans defined only for a few important risks. This is defined in order to minimize the amount of work required for risk management because there is a small level of risk influence in mature and experienced software development organizations. This strategy is based on comparing currently identified risks to previously encountered ones and risk management should be practiced mostly on the organizational level. There is no risk interpretation and ranking policy connected with the flexible risk management strategy, mostly because of the small risk influence and importance on formally defined software development projects. Risks should be identified at the beginning of the software development project and occasionally during the project since there is a small influence of change on these software development projects. Initial project plans should be made according to identified risks, but eventual risk materialization should not change project plans because of the small risk influence. Flexible risk management strategy is intended for mature and experienced organizations in order to achieve efficient risk management and to improve project conditions. Activities of the flexible risk management strategy are presented in Fig. 3.

The selection of a suitable risk management strategy should be primarily based on organizational experience and the quality of project organization, but software development project complexity, use of new technologies, stability of requirements and competencies of project members should also be considered. We believe that the careful risk management strategy should be used in the initial project phase and that the risk management strategy should be reconsidered and possibly changed to typical or flexible on each project milestone. Proposed strategies are the result of a theoretical study based on real experiences from software development projects at Ericsson Nikola Tesla. Activities defined in the careful risk management strategy are a result of experiences from the IP Telex development project, whose project goal was to build a telecom exchange solution based on a commonly used computer platform. The two other strategies are a theoretical proposition for more mature development projects than the current ones at Ericsson Nikola Tesla Company and should be tested in the future.