Software Project Management – Risk analysis and management

I. Risk and the meaning of risk management

1. The meaning of risk

Risk is anything that has a negative impact on the software development process and is a potential problem.

2. Meaning of risk management

Risk analysis and management is a contingency plan for identifying risks, assessing their probability of occurrence, estimating their impact, and establishing problems in actual situations. It is a series of steps to help software teams understand and manage uncertainty.

Understanding the risks and taking proactive measures to manage them are key to good software project management.

Second, passive and active risk strategies

1. Passive risk strategy

(1) Definition: Passive risk strategy is a fire-fighting mode, in which the project team pays no attention to risks until mistakes occur and then takes actions to correct them quickly.

2. Active risk strategy

(1) Definition: the technical work has been started before the start, identified potential risks, assessed the probability of occurrence and impact, and ranked in order of importance.

(2) Main objective: The main objective is to prevent risks, but not all risks can be prevented. Therefore, an emergency plan needs to be established so that it can respond in a controlled and effective way when necessary.

Third, the characteristics of risk

Risk has two characteristics, namely uncertainty and loss. Details are as follows:

1. Uncertainty — risks may or may not occur;

2. Loss — If the risk becomes a reality, there will be bad consequences or loss.

4. Types of risks

There are three types of risk, namely project risk, technical risk and business risk. Details are as follows:

1. Project risk

(1) Main threat: Threat to the project plan.

(2) Risk factors: ① Potential budget, schedule, human resources, customer and demand problems and the impact of these factors on the software project; (2) Uncertainty of project complexity, scale and structure.

2. Technical risks

(1) Main threats: threats to the quality and delivery time of the software to be developed.

(2) Risk factors: ① Potential problems in design, implementation, interface, verification and maintenance; ② Technological uncertainty, old technology and “leading edge” technology.

3. Business risks

(1) Main threat: threat to the viability of the software to be developed.

(2) Five types of business risks:

• Market risk — developing a great product or system that no one really needs;
• Strategic risk— Developing products that no longer fit the company as a wholeThe business strategy;
• Sales risk — building a product that the sales department doesn’t know how to sell;
• To manage risk— Lost due to a shift in focus or staff changeSenior managementSupport;
• Budget risk – There is no guarantee of budget or manpower.

Steps of risk management

Risk management mainly consists of three steps. The first step is risk identification, the second step is risk prediction, and the third step is risk mitigation, monitoring and management. Details are as follows:

1. Risk identification

(1) Definition: Risk identification is an attempt to systematically identify threats to the project plan (estimation, schedule, resource allocation).

(2) Classification

• Generic risk: Generic risk is a potential threat to every software project.
• Product-specific risk: identified only by those who have a good understanding of the technology, people, and environment of the current project.

(3) Risk identification methods

The method of risk identification is to establish a risk item checklist, and the specific steps are as follows:

• ① Product scale — andThe total size of the software to be built or modifiedRelevant experience;
• ② Business influence — andConstraints imposed by management or marketingAssociated risks;
• ③ Customer characteristics — andCustomer quality,The ability of developers and customers to communicate in real timeAssociated risks;
• ④ Process definition — andThe degree to which software processes are defined 和 The degree to which software is complied with by the development organizationAssociated risks;
• ⑤ Development environment — andAvailability and quality of tools used to build productsAssociated risks;
• ⑥ The technology to be built — withThe "complexity" of software to be developed 和 The "novelty" of the technology included in the systemAssociated risks;
• ⑦ Number of staff and experience — andGeneral technical level and project experience of software engineerAssociated risks.

Conclusion:

By creating a checklist of risk items, planners are able to estimate the impact of a risk by producing an answer to each item.

2. Risk prediction

Risk prediction evaluates the risk from two aspects: (1) the possibility or probability of the occurrence of risk, that is, evaluate the probability of risk; (2) The consequences of risk occurrence, that is, the assessment of risk impact. Details are as follows:

(1) Assessment of risk probability: expressed in percentage

(2) Assess the risk impact

(1) From the qualitative point of view, there are four levels, which are negligible, slight, serious and catastrophic;

(2) From a quantitative point of view: RE=P*C; Where P is the probability of risk occurrence and C is the project cost brought by risk occurrence.

Here’s an example:

Question:

A company plans to use 60 reusable components, of which only 70% are likely to be used and the rest will have to be customized for development. Given that the average component is 100LOC, the cost of each LOC is $14. Assume that the probability of this risk occurring is 80%, calculate the risk exposure RE.

Answer:

• Risk: 30% of components to be redeveloped;
• The probability of risk occurrence P is: P=80%;
• Loss cost C is: C=60×30%×100×14=25200 yuan;
• Risk exposure was RE=P×C=80%×25200=20160.

Risk mitigation, Monitoring and Management (RMMM)

(1) Risk mitigation

Objective: To avoid problem activities.

(2) Risk monitoring

Objective: To provide an indication of high and low risk variability.

Examples of monitoring measures:

• Monitor the attitude of project team members to project pressures;
• Monitor the cohesion of the project team;
• Monitor the relationship between project team members;
• Monitor potential issues related to compensation and benefits;
• Monitor the possibility of working in and out of the company.

(3) Risk management

Objective: To make management and contingency plans in advance if risks have occurred.

Summary: In a project, the more detailed THE RMMM, the better, but at the same time, the RMMM steps will lead to additional project overhead.

6. Risk table

1. Steps to establish the risk table

(1) List all risks and classify them.

(2) Estimate the probability of each risk.

(3) Evaluate the impact of each risk, and the impact value is divided into: 1= catastrophic; 2. 3. 4= negligible.

Note: Rank by probability and impact: high probability, high impact risks are placed at the top of the table.

(4) RMMM formation.

2. Legend of risk table

risk	category	The probability of	impact	RMMM
…	…	…	…	…

Vii. Concluding remarks

Risk analysis is particularly important in a software project. If the risk analysis is not done in the early stage, the consequences of the software are completely unimaginable. So, learn to do risk analysis and management, and have a better evaluation of software.

So much for risk analysis and management of software project management! If you need to know more about software engineering, you can go to the “Software Engineering” section to view and learn ~

At the same time, do not understand or wrong place also welcome to comment section comments or private letter I exchange ~

• Concern about the public number Monday laboratory, do not regularly share learning dry goods, learning on the way not lost ~
• If this article is useful to you, be sure to like it and follow it