Software failures: reasonable and even desirable!

Since the technology is continuously evolving and there is a great variety of software testing approaches that can be applied to different stages of the software development process, one would expect that failures related to software projects would have been limited and easily avoided. Numerous researches and statistics reveal that this fact is not true. Software project failures continue to occur. In some cases they do not seem to be significant, but in others they are quite serious and lead to the loss of huge amounts of money. Every year, there is a great list of companies that fail in the development of their products with reference to the investments that are lost in each case. All these examples have led to the creation of lists including the most common software failures, the most common reasons that cause their occurrence and finally tips and advice on how to reduce or even avoid the majority of them.

How is software failure defined and when is a software project considered as a failure?
A software failure occurs when a software system no longer complies with the specifications that were initially defined for it, which means that it does not present the expected behaviour and this situation can be externally observable. Bugs or faults in a software system tend to lead to errors (which occur within the bounds of a system and are therefore hard to observe) and then errors might cause failures. Faults, errors and failures follow a cyclic pattern in a software system. However, there are cases in which the error may be trapped and repaired by the system or it is of a particular type that does not give rise to a failure.

The definition of a software project as a failure varies and seems to be quite a subjective issue. Most of the times, it depends on the type of the project and the standards that the company producing it has set for it. A commercial project that exceeds the pre-estimated budget or does not meet the predefined deadline could be seen as a failure. On the other hand, an open-source project could be considered as a failure if it does not succeed in creating a community around it which takes care of its maintenance and evolution. Other reasons to define a project as a failure are related to the customers and their needs (e.g. the project does not satisfy the customers’ requirements), the team building the project (e.g. the members of the team fail to continue the work already done) and many other factors that will be discussed in a later section of this article.

Which are the most common causes of software project failure?
The issues that have been recorded so far as the reasons contributing to failures in software projects are various and can divided into two broad categories: technical and social. The technical issues are mostly related to the lack of up-to-date estimating techniques and to the fact that developers often fail to make a plan and encounter possible growth or changes in consumers’ requirements. On the other hand, social issues are associated with the attempt to adhere to a plan and some predefined deadlines regarding the construction of the software project resulting in lack of attention to detail and inaccurate results . [4]

A list with some of the most common software failure reasons is presented below [1], [2], [4]:

  • Absence or bad definition of system requirements: The existence of Software Requirement Specifications (SRS) is fundamental in the software development process. System specifications that are not defined in a thorough and precise way can cause misunderstandings and lead to bad implementation. The accuracy of SRS is very important and can save much time and eliminate problems that could possibly arise during the next steps of the development procedure regarding the addition of new features or changes in already existing ones.

  • Unrealistic expectations and project goals: There is a close relation among this factor and some others associated with the pressure caused by imminent deadlines and the skills of the software development team working on a project. In some cases, project managers fail to realise that it is not feasible to implement all the ideas regarding a project within the specified time limits, especially when some of them appear to be quite complex. Moreover, they often overestimate the abilities and skills of the members working on that project, who may be for instance young and inexperienced. The lack of a well organised plan based on the correlation among these issues can easily lead to project failure. It is also true that the unrealistic expectations can be a result of inexperience of project managers themselves.

  • Absence or bad documentation: There are different types of documentation that are required during the various phases of the software development process. Adequate and up-to-date documentation is crucial as it helps developers think about some issues related to the project before actually starting implementing it and reduces the possibility of a failure.

  • Poor communication among developers, customers and final users: There is no way of a software project being successful, if there is no constant and meaningful communication among these groups of people. Users’ needs and customers’ requirements and expectations change all the time and developers should always take into consideration this new information during the development process.

  • Inadequate resources or use of inappropriate ones: Software development teams often tend to use resources and tools that are obsolete and as a result not the most suitable for the development of modern software projects. This can often cause unexpected and undesirable results and in the worst scenario to failure of the whole project. Software manufactures should be responsible for keeping themselves informed about the technology changes and being ready to exploit their advantages in order to improve their project. In some other cases, a bad estimate about the required resources may be done. This fact makes the development of software at the expected and predefined level extremely difficult and sometimes infeasible.

  • Absence or bad risk management: Risks in software projects refer to uncertain states that could affect a project in an undesirable way, e.g. inadequate or badly written requirement specifications, use of unsuitable technology and tools, etc. Risk management is another crucial part of the software development process that should be precise, done from the beginning to the end and kept updated. In that way, many problems could be encountered and solved before becoming too serious and leading to failure.

Of course, a little bit of research and reading on very popular project failures that have been recorded during the last decades can reveal many more reasons that make software fail [5]. My intention in this article is just to give a brief list with some of the most commonly met.

Are there any precaution steps that could be followed to prevent software from failing?When things go wrong and people fail in achieving their goals, the lessons learnt during their attempt constitute the only positive and the most important part. Analysis of these lessons and feedback given either by small software development teams or larger companies leads to the creation of a list with some suggestions considered good enough to prevent failure and contribute to the success of a software project. Some of them are the following [3]:

  • Careful consideration of user input and feedback during all the stages of the software development process

  • Set of realistic goals and detailed plans and estimates about the cost and time that will be possibly required for the development of the software

  • Choice of the right team by comparing the skills and knowledge of its members with what is needed for the right implementation of the project

  • Constant update of documents related to requirement and risk management according to new users’ needs that may arise

  • Provision of the right communication tools so that the communication between developers and consumers is never lost and is preserved during the development procedure

These and many other actions can help reduce the rate of software failure and somehow ensure the success of a project.

Many software manufacturers have been asked about their products’ failures and whether they have regrets trying hard or spending much time and money on them. It is noticeable that the majority of them mentions that they have no regrets and that it is worth taking some risks as they have learnt a lot from their mistakes and they have gained much knowledge and experience that could use in their future plans [5].

After explaining all the above, one reasonable question would be: since the reasons that contribute to software failures and ways of preventing them are known, why do software manufacturers tend to not apply them and leave their projects fail?

The answer is quite complicated. Apparently, the goal of every software development team is to produce a successful product. But, it is not always easy to take into account all these factors that can lead to a failure. Sometimes there is knowledge, but there is lack of experience on how to apply it correctly. In other cases, there is knowledge and experience but the time pressure imposed by deadlines or the limits on the available budget lead to compromises on the quality of the software produced [1].

It seems quite reasonable for software failures to continue to occur at some level, but the majority of them could have been avoided using the knowledge that already exists. The real challenge and the occurrence of true failures that have never happened before and for which there are no known methodologies on how to avoid them. In this context failures are somehow “desirable”, because only this kind of situations can help software manufacturers improve and make technical and economic progress [2].

I suppose that since there is much knowledge on how to produce successful software, it is time to take advantage of it and apply it in practice [2]. And even if a failure occurs, we should be ready to work on it and try to find possible solutions. But when is the right time to stop trying fixing a failure and cancel a project? Should we consider only the relation between the time and cost spent to it with the value that it actually returns? Or are there any other factors that should be also taken into account? In my opinion, this is one of the most difficult decisions that need to be made when software fails.

[1] Cohen Shwartz Oren, “Why Software Projects Tend to Fail “, September 2007
[2] Robert N. Charette, “Why Software Fails“, September 2005
[3], “Why do Software Projects fail?
[4] Capers Jones, “Social and Technical Reasons for Software Project Failures“, June 2006
[5], “Lessons learned from 13 failed software products“, May 2010

2 thoughts on “Software failures: reasonable and even desirable!”

Comments are closed.