Software Project Risk Management

1 Preface
In general, software engineers are always very optimistic. When they plan software projects, they often think that everything will run as planned, or they will go to another extreme. The creative nature of software development means that we cannot fully predict what will happen, so it is difficult to determine the key points of developing a detailed plan. When unexpected events cause the project to be off the normal track, the above two ideas will lead to the failure of the software project.
Currently, risk management is considered an important means to reduce failures in IT software projects. When you cannot predict future events with certainty, you can use structured risk management to discover planned defects and take actions to reduce the likelihood and impact of potential problems. Risk management means that the crisis is handled before it occurs. This increases the chances of project success and reduces the consequences of unavoidable risks.
2. What is risk?
The so-called "risk" mainly involves two kinds of opinions. The subjective opinion is that risk is the uncertainty of the loss. Objectively speaking, risks are the differences between various results that may occur in a given period. Its two basic features are uncertainty and loss. Software Project Development in the IT industry is a potential loss activity, regardless of how the development process is carried out may exceed the budget or time delay. The method of project development rarely ensures that the development work is successful, and risk analysis is required. During project risk analysis, it is important to quantify the degree of uncertainty and the loss of each risk. To achieve this, you must consider the following:
In the future, what kind of risks will lead to software project failure?
Consider changes. What impact will changes in user requirements, development technologies, goals, mechanisms, and other project-related factors have on timely delivery and system success?
The selection problem must be solved. What methods and tools should be used, how much manpower should be provided, and to what extent should the quality be adjusted to meet the requirements?
Should we consider the risk types, such as project risks, technical risks, commercial risks, management risks, or budget risks?
These potential problems may have a negative impact on the planning, cost, technology, product quality, and team morale of software projects. Risk management is to identify, process, and eliminate potential problems before they damage the project.
3. Risk management
Project risk management is a series of management steps throughout the project development process, including risk identification, risk estimation, risk management policies, Risk Resolution and risk monitoring. It enables risk managers to take the initiative to "attack" risks for effective risk management.
In project management, it is very important to establish risk management policies and continuously control risks in the project lifecycle. Risk management involves four phases:
Risk identification and risk identification methods are commonly used: Risk Identification inquiry method (discussion method, expert method), financial statement method, flowchart method, on-site observation method, related department coordination method and environmental analysis method.
Risk assessment estimates and evaluates identified risks. The main task of risk estimation is to determine the probability and consequence of a risk, risk assessment is to determine the economic significance of the risk and the cost/efficiency analysis of the risk. Common methods include probability distribution, external push method, and multi-objective analysis method.
In general, there are three methods to deal with risks: ① risk control method, that is, take the initiative to avoid risks, eliminate risks, moderate risks or adopt emergency solutions to reduce risks. ② Leave risks on your own. When the risk volume is small, you can leave the risk. ③ Risk transfer.
Risk Monitoring includes risk monitoring and risk management. The former monitors and controls identified risk sources, the latter is the organization and technical measures that supervise people to seriously implement risk management during project implementation.
In IT software project management, a risk manager should be appointed. The main responsibility of the manager is to design and evaluate the plan, from the perspective of risk management, review and comment on the Project Plan or plan, constantly look for any unexpected situations, and try to point out the management policies and common management methods for each risk, to handle the risks at any time, it is best for the risk manager to be held by persons other than the project supervisor.
4. Risk Identification
Risk identification is an attempt to use a systematic method to identify known and predictable risks of a specific project. The common method is to create a "risk entry checklist" and use a group of questions to help the project risk manager understand some risks in the project and technology. The risk entry checklist lists all possible questions related to each risk factor, allowing risk managers to focus on identifying common, known, and predictable risks, such as product scale risks, dependency risks, demand risks, management risks and technical risks. The risk entry checklist can be organized in different ways to help managers or planners estimate the impact of risks by giving answers to these questions through judgment analysis or hypothetical analysis. Software projects generally have the following five risks:
4.1 product scale risks
Experienced project managers know that project risks are directly proportional to the scale of products. Common risk factors related to software scale include:
Method to estimate the scale of a product (LOC or code line, FP or function point, number of programs or files ).
Product Scale Estimation Trust
Deviation between product scale and Average Scale of previous products
Number of users
Number of Reusable Software
How many changes are required?
4.2 demand risks
Many projects are faced with uncertainty and confusion when determining their needs. When these uncertainties are tolerated in the early stages of the project and cannot be resolved during the project's progress, these problems will pose a great threat to the project's success. If you do not control the risk factors related to the demand, it is very likely that wrong products will be generated or the right products will be constructed poorly. Every situation can lead to unpleasant people.
Customer-related risk factors include:
Lack of a clear understanding of the Product
Lack of identification of product requirements
Insufficient customer participation in demand
No priority requirements
New market due to uncertain needs
Changing demands
Lack of effective demand change management process
Lack of Relevant Analysis on demand changes
4.3 correlation risk
Many risks are caused by the correlation of the project's external environment or factors. We often do not have good control over external relevance, so mitigation strategies should include a possibility plan to capture necessary components from second resources or collaborative work resources and detect potential problems. Factors related to the external environment include:
Customer supply entry or information
Internal or external forwarding relationship
Interaction member or interaction group dependency
Availability of experienced personnel
Project reusability
4.4 management risks
Although management issues constrain the success of many projects, do not be surprised because the risk management plan does not include all management activities. In most projects, project managers often write project risk management plans, and most people do not want to expose their weaknesses in public. However, problems like these may make project success more difficult. If you do not face up to these thorny issues, they are likely to affect the project at a certain stage of the project. When we define the project tracking process and clarify the project roles and responsibilities, we can deal with these risk factors:
Insufficient plans and task Definitions
Actual Project Status
Unclear project owner and decision makers
Unrealistic commitment
Conflicts between employees
4.5 technical risks
The rapid development of software technology and the lack of rich employees mean that the project team may be affected by technical reasons. In the early stages, identifying risks and taking appropriate preventive actions are critical to addressing risk issues, such as training, hiring consultants, and recruiting appropriate talent for the project team. There are mainly the following risk factors:
Lack of training
Insufficient understanding of methods, tools, and technologies
Insufficient experience in the application field
New technologies and development methods
Incorrect Method
5. Risk Estimation
Risk Estimation, also known as risk prediction, often uses two methods to estimate each risk. One is to estimate the likelihood or probability of a risk, and the other is to estimate the consequences of a risk. Generally, risk managers should carry out four types of risk activities with project planners, technicians, and other managers:
(1) Establish a standard (scale) to reflect the possibility of risk occurrence.
(2) Describe the consequences of the risk.
(3) estimate the impact of risks on projects and products.
(4) determine the risk accuracy to avoid misunderstanding.
In addition, the performance, scope, and time of each risk should be judged as accurately as possible. Different types of risks are analyzed.
1. deterministic Risk Estimation
(A) breakeven analysis
Break-Even Analysis (Break-Even Analysis) is also known as volume-based Profit Analysis or profit-Loss Balance Analysis. It is based on the data of the product production or sales volume, cost, product sales unit price, and sales tax of the software project in the normal production year, calculate and analyze the relationship between production, cost, and profit, find out their rules, and determine the breakeven point when the project cost and income are equal. At the breakeven point, software projects have neither profit nor loss. The breakeven analysis shows the adaptability of software projects to market demand changes.
(B) Sensitivity Analysis
The purpose of Sensitivity Analysis is to evaluate the impact of one or more major factors related to a software project on the project's investment value indicators when they change. Through sensitivity analysis, we can understand and grasp the extent to which the impact on investment value indicators may be caused by incorrect estimation of certain parameters or unreliable data used in the economic analysis of software projects, this helps us determine the factors that need to be investigated, researched, analyzed, and calculated in the project investment decision-making process.
(C) Probability Analysis
It uses probability theory and mathematical statistics to predict and study the impact of various uncertainties on software project investment value indicators. Probability analysis can be used to accurately determine the risks of a project. It mainly includes the analytical method and simulation method (Monte Carlo technology.
2. uncertain risk estimation
There are mainly the principles of small, medium, and small, the principle of regret, the principle of maximum mathematical expectation, and the principle of maximum possibility.
3. Random Risk Estimation
The principles include the maximum possibility principle, the maximum mathematical expectation principle, the maximum utility mathematical expectation principle, and Bayesian posterior probability method.
5.1 create a risk list
The risk list is a key risk prediction management tool. It lists the names, categories, probabilities, and impacts of the risks at any time. The overall impact value can average the impact categories of four risk factors (performance, support, cost, and progress) (sometimes the weighted average value is used ).
Once the content of the risk table is completed, the probability and impact can be considered comprehensively. From the perspective of risk management, the risk impact and probability appear, they play different roles (see figure 1 ). A risk factor with a high impact but a low probability should not take too much risk management time, but should have a medium to high probability, a high impact risk and a risk with a high probability and a low impact, risk analysis should be conducted.
5.2 risk assessment
During the risk analysis process, we can establish the following four element group during risk evaluation:
[Ri, li, xi, yi]
Ri indicates the risk, li indicates the probability of risk occurrence, xi indicates the risk loss, and yi indicates the expected risk.
A common technique for risk assessment is to define a reference level for risks. For most software projects, risk factors-cost, performance, support, and progress-are typical risk references. That is to say, there is a horizontal value that leads to project termination for cost overruns, performance degradation, support difficulties, and schedule delays. If the problem caused by a combination of risks exceeds one or more reference level values, the work of the project will be terminated. In the project analysis, risk level reference values are composed of a series of points, each of which is often referred to as a reference point or a critical point. If a risk falls on the critical point, you can use performance analysis, cost analysis, and quality analysis to determine whether the project continues to work. Figure 2 shows this situation.
However, in actual work, a reference point rarely forms a smooth curve. In most cases, it is a region and a variable area. Therefore, perform the following steps during risk assessment:
(1) define the horizontal reference value of the project
(2) Find the relationship between each group of [ri, li, xi, yi] and each horizontal reference value.
(3) estimate a set of critical points to define the project termination Region
(4) estimate how the risk combination affects the risk level reference value
5.3 estimated loss
Table 1 is an example of a risk analysis table. A risk evaluation table such as risk, loss probability, loss size, and expected risk can be created.
In the risk valuation example shown in table 1, a theoretical project has identified several potential risks from 1 to 20 cycles, with a probability range of between 5% and 50%. In real projects, you may identify more risks than this table.
The loss is often more controllable than the probability. In the above example, we can accurately estimate that the time for automatically updating data from the host is 20 months. According to the time when the management will discuss the project proposal, we can know that the project will be approved either in February 1 or March 1. If it is assumed that the project will be approved on April 9, February 1, the risk of project approval will be longer than expected, that is, one month.
If the loss is not easily estimated, the loss can be divided into smaller parts, and then evaluated. Then, the evaluation results of each part are accumulated to form a total evaluation value. For example, if three new programming tools are used, you can independently evaluate the loss of each tool that fails to achieve the expected results, and then add the loss together, which is much easier than the overall evaluation.
5.4 estimate the probability of loss
The probability of evaluating a loss is more subjective than evaluating the loss. There are many practical methods to improve the accuracy of subjective evaluation. You can use the following methods:
The people who are most familiar with the system assess the probability of occurrence of each risk, and then keep a risk assessment audit document.
Use the Delphi method or a few methods that follow the majority. Using the Delphi method, each person must be asked to evaluate each risk independently and then discuss (orally or on paper) the rationality of each assessment, especially the highest and lowest. Wait until consensus is reached. ? Use the adjective standard ". First, let everyone select the level of risk with the adjective phrase indicating the possibility, such as very likely, very likely, possible, maybe, unlikely, impossible, and simply impossible. Then, the probability evaluation is converted into a quantitative evaluation (Boehm1989 ).
5.5 The entire project is out-of-limit and buffered
In fact, the expected risk calculated in Table 1 comes from a statistical term called "Expected Value. Risks caused by poor design will take 15 weeks if they occur. Since it does not happen in 100% locations, of course it cannot be estimated that the loss will take 15 weeks. However, it is neither impossible nor expected to cause losses. Statistics show that the expected loss quantity is the probability multiplied by the loss size, that is, 15% multiplied by 15 weeks. Therefore, in this example, the expected loss is 2.25 weeks. Because we only talk about planning risks, we can accumulate all risk exposures to obtain all the predictable exceeding values of the project. This project is expected to exceed 12.8 to 13.2 weeks, which means that if no risk management is performed, it may exceed the planned number of weeks.
The amount exceeding the expected value provides a basis for determining the risk control level of the entire project. If the project in this example is a 25-week project, the risk management needs to be performed from 12.8 to 13.2 weeks that exceed the expected value.
6. Risk management strategies
The risk management policy is used to assist the project team in establishing a strategy to deal with project risks. Project development is a high-risk activity. If a project adopts an active risk management strategy, many risks can be avoided or reduced. Otherwise, the project may be paralyzed. Generally, a better risk management policy should meet the following requirements:
(1) plan Risk Management in project development to avoid risks as much as possible
(2) designate risk managers to monitor risk factors
(3) establish a risk list and Risk Management Plan
(4) Establish Risk feedback channels
7. Risk Control and Monitoring
Risk Control and Monitoring mainly rely on the experience of managers. It uses project management methods and some other technologies, such as primitive method, software psychology, and reliability, to avoid or transfer risks. Risk Control and monitoring activities can be expressed in figure 3.
7.1 establish risk control and monitoring plans
As shown in figure 3, Risk control and Monitoring activities should be written into the RMMP (Risk Monitoring and Management Plan Risk control and Monitoring Plan ). RMMP describes all the work of risk analysis and is used by project managers as part of the entire project plan.
Risk management policies can be included in software project plans or organized into an independent risk mitigation, monitoring, and management plan (RMMP plan ). RMMP plans document all risk analysis work and are used by project managers as part of the entire project plan. Once the RMMP plan is established and the project starts, the risk mitigation and control and monitoring steps are also started. As discussed earlier, risk mitigation is a problem avoidance activity. Risk Control and monitoring is a project tracking activity. It has three main objectives :? Determine whether a predicted risk is true or not.
Carries out risk estimation to ensure that risk elimination activities developed for a specific risk are in use.
Collect information that can be used for future risk analysis.
The risk control and monitoring policies are as follows:
Negotiate with in-service personnel to determine the reason for the flow of personnel.
Before the project starts, include the work to mitigate these flow causes in the risk control plan.
At the beginning of the project, we should prepare for the flow of people and take some measures to ensure that the project can continue once the personnel leave.
Develop document standards and establish a mechanism to ensure that documents are generated in a timely manner.
Conduct a detailed review of all the work, so that more people can complete their work as planned.
Train reserve personnel for each critical technical personnel.
After considering the risk cost, decide whether to adopt the above strategy.
7.2 software project risk tracking tools
One way to track risks is to input the risk into the defect tracking system. The defect tracking system can mark the risk items as resolved or not handled, and can also specify the project team members who solve the problem, and arrange the processing order. Software risk items can be listed in sequence, according to the time of occurrence of defects and the persons responsible for such information. In this way, the defect tracing system is able to better track risks and be less monotonous.
8 conclusion
Software project risk management is a special planning method. When there are high expectations for software projects, risk analysis is generally required. People who have performed large and medium-sized project development experience many things that may go wrong. The most successful project is to take positive steps to manage the risks that will occur or will happen soon. You can have the best expectations for any software project, but you should have the worst preparation. "The worst preparation" is the risk analysis of the project in project management.