Core risks of software projects

Risks exist in all projects. Some of these risks are the culprit of project failure. The five most common risks are listed below, which have a huge impact on the success or failure of the project.

 

1. The schedule from the beginning is incorrect.

People always tend to make optimistic estimates, and often ignore the "may need to do" work. Although you may make a serious estimation of the project size, the estimation results may be too small, this directly leads to a longer schedule than expected. In this case, the results that can be produced are also limited. However, people are often blinded by the seemingly motivating schedule and lose their vigilance against this risk.

Although a complete estimation of the project scale does not ensure that the schedule is accurate, at least it will not make the difference too far from the reality. Preparing for unmeasurable workloads means that you are not at risk.

For large projects, the risk of incorrect schedule is relatively small, because large projects generally make a lot of estimation on the project scale. In addition, such projects have the opportunity to re-estimate, adjust the progress.

 

2. Demand Expansion or change.

From the perspective of the project, the demand is always in the direction of expansion, and even removing the requirements of existing functions is also a kind of expansion, because this increases the workload. We always need to "hit the Mobile target". The idea of trying to fix the demand at the beginning of the project and not allowing any changes is no different than a sword. For example, a two-year project may change the user's business during development, so we must make corresponding changes to the software.

We need to have an acceptable range of changes so that when the customer asks for a change request, we can determine how much work will be added and how much impact the progress will be, tell the customer how much it will increase and what results it will get.

 

3. Lost project staff.

A member often leaves during the project process. Maybe he does not leave any documents. Maybe, except that he has no details about the project, the new person may not be able to quickly master the knowledge required by the project. The best way to deal with this risk is to keep team members and the human brain is more accurate and efficient than any document. If you cannot do this, you need to spread your knowledge across the team. In the past, we always thought that every developer could be replaced with enough documents.

 

4. Protocol crash.

This risk is different from other types. It either does not occur or occurs, which directly leads to project failure and does not affect the project to varying degrees.

When the project starts, both parties will sit together to determine the scope of the requirement. If we cannot talk about it in this process, we 'd better cancel it so that both parties will not suffer any losses. However, this rarely happens. In many cases, the two sides get a barely acceptable result, so the project starts with an ambiguous and ambiguous goal.

The hidden problems will not disturb you for a moment, but will not be permanent. When a defective or ambiguous product is delivered, the time and money paid by both parties are irrecoverable. When either party no longer has the patience to continue, the project will have only one dead end. Perhaps this is good. What's worse is that after the two sides have made many modifications and negotiations, the project still cannot go out of the quagmire. When we realize that "lack of consensus" is the root cause, there is no cure for the project.

 

5. Low production efficiency.

The efficiency of developers varies greatly. From the perspective of the team, this difference will weaken to some extent. In rare cases, this risk will have a fatal impact on the project, but more importantly, it will have an impact on the project progress.

 

We can see that among the five risks, there are only the fifth one in relation to efficiency. Obviously, the first four risks have a greater impact on the project. Therefore, we cannot think that risk management leads to inefficiency. Instead, we can recognize the existence of these risks, prepare for these uncertainties, reserve enough resources, and truly dare to face the difficulties, instead of looking for excuses to escape.