Software Project Risk Management

1. Introduction

Software Project risks refer to the budget and progress problems encountered during software development and the impact of these problems on software projects. Software Project risks may affect the implementation of the project plan. If the project risk becomes a reality, it may affect the project progress, increase the project cost, or even make the software project impossible. If you manage project risks, you can minimize the risk. However, software enterprises in China are not very concerned about the risk management of software projects. As a result, software projects are regularly postponed, budget exceeded, or even fail. Successful project management generally manages project risks well. Therefore, risk management should be an important part of software project management in any system development project. [1]

There are a variety of risk management methods and tools in project risk management. software project management can minimize software project risks only by finding and applying the most suitable methods and tools to risk management, promote project success.

2. Project Risk Management

Project Risk management refers to the science and art of identifying, allocating, and coping with risks within the project life cycle in order to achieve the best project objectives. The goal of project risk management is to maximize potential opportunities or returns and minimize potential risks. Risk management involves the following main processes: risk identification, risk quantification, risk response plan formulation and risk monitoring, as shown in [2] [3]. Risk identification should be carried out at the beginning of the project and should be carried out continuously during project execution. That is to say, risk identification is a continuous process throughout the project's lifecycle.

Figure 1 project risk management process

(1) Risk Identification: Risk Identification includes determining the source and conditions of risks, describing their risk characteristics, and determining which risk events may affect the project. Risk identification is not a task that can be completed once. It should be conducted regularly from beginning to end of the project.

(2) Risk Quantification: An Evaluation of the interaction between risks and risks is a process to measure the impact of risk probability and risk on the project objectives. The basic content of risk quantification is to determine which events need to develop countermeasures ..

(3) risk response plan formulation: the process of formulating risk response policies and technical measures to reduce the negative effects of project risks based on the risk quantification results. Based on the risk management plan, risk sorting, and risk cognition, the risk response plan, residual risks, secondary risks, and other processes are provided.

(4) Risk Monitoring: it involves coping with risks throughout the project management process. The output of this process includes the rectification measures to cope with risks and updates of the risk management plan.

For the tools and methods used in each step, see table 1:

Table 1 tools and methods used in risk management

risk management steps	tools and methods used
risk identification	brainstorm, interview, Delphi, checklist, and SWOT
risk quantification	risk factor calculation, pert estimation, decision tree analysis, and Risk Simulation
risk response plan formulation	avoidance, transfer, easing, and acceptance
risk monitoring	checklist, regular project evaluation, and Earned Value Analysis

3. Risk Management in software projects

3.1 risks in software projects

The risks of software projects are embodied in the following four aspects: Demand, technology, cost and progress. I t project development has the following common risks: [4]

(1) demand risks

① The demand has become the project benchmark, but the demand is still changing; ② The requirement definition is not good, and the further definition will expand the project scope; ③ add additional requirements; ④ The ambiguous part of the product definition takes more time than expected; ⑤ the customer is not involved enough in the demand creation; ⑥ there is no effective demand change management process.

(2) Planning risks

① The plan, resources, and product definitions are based on the verbal instructions of the customer or upper-level leaders and are not completely consistent; ② the plan is optimized and "best", but the plan is unrealistic, it can only be regarded as "Expected state"; ③ it is planned to use a specific group member, but that specific group member is not expected; ④ product scale (CodeThe number of rows, function points, and percentage of the scale of the previous product are larger than the estimated value. ⑤ the target date of completion is advanced, but the product range or available resources are not adjusted accordingly; ⑥ getting involved in unfamiliar product fields takes more time in design and implementation than expected.

(3) organization and management risks

① Only technical decisions are made by the management or market personnel, resulting in slow progress and extended planning time; ② Inefficient project team structure to reduce productivity; ③ the management review decision-making cycle is longer than expected; ④ reduce the budget and disrupt the Project Plan; ⑤ the management has made a decision to combat the enthusiasm of the project organization; ⑥ lack of necessary specifications, leading to mistakes and repetitive work; 7. Non-Technical third-party work (budget approval, equipment procurement approval, legal review, security guarantee, etc.) has been extended as expected.

(4) personnel risks

① Tasks as prerequisites (such as training and other projects) cannot be completed on time; ② the relationship between developers and management is poor, resulting in slow decision-making and affecting the overall situation; ③ lack of incentive measures, low morale reduces productivity; ④ some people need more time to adapt to unfamiliar software tools and environments; ⑤ new developers will be added to the project later, training is required and communication with existing members is required to reduce the efficiency of existing members; ⑥ due to conflicts between members of the project team, this results in poor communication, poor design, interface errors, and extra repetitive work. 7. Non-staff members are not transferred from the project team, which affects the enthusiasm of other members of the project team; the supervisor did not find anyone with specific skills badly needed by the project.

(5) Development Environment Risks

① The facilities are not in place in time; ② the facilities are in place, but not supporting facilities, such as no telephones, network cables, office supplies; ③ the facilities are crowded, messy or damaged; ④ the development tools are not in place in time; ⑤ development tools are not as effective as expected. developers need time to create a work environment or switch between New Tools. ⑥ The learning period of new development tools is longer than expected, with a wide range of content.

(6) Customer risks

① The customer is not satisfied with the final delivery of the product and requires re-design and redo; ② the customer's opinion is not accepted, resulting in the product cannot meet the user's requirements, so it must be redone; ③ The customer's decision-making cycle for planning, prototype and specification is longer than expected; ④ the customer does not or cannot participate in the review of the planning, prototype and specification phase, resulting in unstable requirements and changes in the product production cycle; ⑤ the time for the customer to reply (such as the time for answering or clarifying questions related to the demand) is longer than expected; ⑥ The component quality provided by the customer is poor, lead to additional testing, design and integration work, as well as additional customer relationship management work.

(7) product risks

① Rectification of unacceptable products with low quality requires more testing, design, and implementation work than expected; ② development of additional unnecessary functions (gold plating), extended the planned progress; ③ strict requirements for compatibility with existing systems and more tests, designs, and implementations than expected; ④ requirements for connection with other systems or systems not controlled by the project team, leading to unpredictable design, implementation and testing; ⑤ unexpected problems arising from running in unfamiliar or untested software and hardware environments; ⑥ developing a brand new module will take longer than expected; 7 depending on the technology being developed will extend the schedule.

(8) design and implementation risks

① Design quality is low, leading to repeated design; ② some necessary functions cannot be implemented using existing code and libraries. Developers must use new libraries or develop new functions on their own; ③ The quality of codes and libraries is low, leading to the need for additional tests, correction errors, or re-production. ④ This overestimates the savings of enhanced tools on the schedule; ⑤ The modules developed separately cannot be effectively integrated and need to be re-designed or created.

(9) process risks

① A large number of paper work lead to a slower process than expected; ② the Quality Assurance behavior in the early stage is untrue, leading to repeated work in the later stage; ③ too informal (lack of compliance with software development strategies and standards), resulting in insufficient communication, poor quality, and even re-development; ④ too formal (adhere to software development strategies and standards in a systematic manner), resulting in excessive time consumption and useless work; ⑤ writing process reports to the management layer takes longer time for developers than expected; ⑥ careless risk management, leading to failure to discover major project risks.

3.2 Software Project Risk Management Model

Many experts and organizations have put forward their own risk management models for risk management issues in software projects. The main risk management models are: Boehm model, CRM model and serim model [5].

3.2.1 Barry Boehm model

Model: Re = P (UO) * l (UO)

Where Re indicates the impact caused by the risk or risk, P (UO) indicates the probability of occurrence of unsatisfactory results, L (UO) it indicates the extent to which bad results will produce destructive results. The core of Boehm is the list of 10 risk factors. A series of risk management policies are provided for each risk factor. In actual operations, Boehm summarizes the specific risk factors of the current project based on the ten major risks list, and plans and implements the evaluation, at the next scheduled meeting, we will summarize the solutions to these 10 risk factors to generate a new 10 risk factors table, and so on.

3.2.2 sei CRM (continuous risk management) Model

The sei crm model's risk management principles are: constantly evaluating factors that may cause adverse consequences, determining the most urgent risks to be addressed, and implementing risk control policies; evaluate and ensure the effectiveness of risk policy implementation. The CRM model requires that you focus on risk identification and management at all stages of the project's life cycle. It divides risk management into five steps: risk identification, analysis, planning, tracking, and control.

3.2.3 serim (Software Engineering Risk Model) Model

Serim analyzes software risk management from both technical and commercial perspectives, and considers issues such as overhead, progress, and technical performance. It also provides some indicators and models to estimate and predict risks. Because the data comes from a large amount of practical experience, it is very convincing.

4. Conclusion

In a sense, software project management is risk management. We try our best to define clear requirements for planning and efficient management, but the business environment is always changing rapidly, or even disorderly. Therefore, in the process of project management, software enterprises must adopt appropriate risk management methods for risk management to ensure that the software project completes the project within the specified budget and period.