Five major causes of software project failure

Status quo

After analyzing data from a large number of software development projects, researchers in the United States told us that more than 50% of software development projects in the world are failing at any time. In fact, in my memory, the exact data I recently saw is that 73% of projects failed at the end. Failure means that the final submitted system either fails to meet market requirements, either the investment in time and money greatly exceeds the original expectation, and this does not include projects that are forced to be terminated for some reason.

Even in the United States, which is at the forefront of the world in the software development field, the situation in other places can be imagined. Maybe this is why software development project management has become a special learning.

Cause

Back to the truth, we may be able to learn from others' lessons. The following are some of the reasons for project failures that are often mentioned in some software engineering works, most of them have been verified in my work experience. I would like to share them with you as a warning:

• Unrealistic schedule

The deadline book may be a book that project stakeholders should read. It clearly depicts and describes the cause of project failure, unfortunately, such projects are still everywhere. In almost every book about software development, the author can give examples of failures to prove what damage the deadline imposed by external pressure on the development team will do to the project, maybe in the business world, A deadline cannot be broken.

There is no mistake in developing deadline, and it is also necessary. The key is whether deadline is practical. The actual deadline is not fabricated by others, but should be a commitment made by the development team after careful evaluation.

• Inappropriate staffing

This article is almost all about software development project management, including many situations, such as insufficient staffing and messy staffing, if an inappropriate project manager is specified, it is expected that the project manager can play a role immediately after joining the team at a critical moment, etc.

The two most classic books of software development, man-piece and man-month myth, have long told us that "man-People" is the most critical factor in software development, many decision makers prefer to ignore this fact to a certain extent, and there is nothing to say about it. My recent experience is: Who do you use to do this, it is often determined what results you will achieve and whether you can achieve the expected results in advance depends on the "people" who complete the work and the interaction between them.

• Disruptive demand changes

Demand management has become one of the required courses for project management. There is no such question. The reason why a project exists is to satisfy certain requirements;

It should be emphasized that the demand changes at Will will inevitably have a bad impact on the project. If the customer's demand changes at will, the software design and implementation will be constantly changed, this takes time and money. changes from the development team's own needs can cause more problems, that is, the customer does not need to submit anything.

The requirement is not unchangeable, but should not be changed at will. It should be changed under control, or there should be a good change procedure to ensure that the change in demand will not have a destructive impact on the project.

• Low Quality Work

If a low-quality software product is produced under some pressure, the post-processing of customer complaints, correction, testing, and other work will take away the profits you have made, which will make you pay a higher price; many software companies have fallen down on this point, and many people will continue to fall behind;

It reminds me of a saying: "Evil has evil news, good news, not don't report, time is not up ". In the development phase, if necessary quality assurance work is reduced, it may seem like a debt has been owed and will be paid back sooner or later. buyers may be different people, but it must be the same company. It is the lowest cost to ensure good quality at the beginning. The more you fix the same defect, the more you will pay later.

• Believe in miracles

There may be a miracle in nature, and we should believe it. However, when we gather together a group of people to do software development, some of them are only the results of people's efforts, and they won't even have a silver bullet, how can there be a miracle? However, there are still many people who "believe" that there is a miracle: for example, they want to produce high-quality results in a chaotic and disordered team; they want to successfully deliver products on an impossible delivery day; for example, we hope to get high-quality products without quality control measures;

In the case of software product development, there is no such miracle as a hard work and a fruitful harvest. In the case of demand analysis, there is no good management of requirements, at the end of the submission, the customer will certainly ask questions. When designing, you will not consider performance issues, and you will inevitably encounter performance restrictions during testing. when implementing a function, you will not do a good job of quality control, during the final integration, many defects will be exposed. Therefore, the success of the project is only due to a steadfast attitude.