Failure in Software Projects

Since the late 1960s, software projects have caused the delay of all developed systems, the planned budget recurring problems of usage, main tainability, and extensibility. The term “Software Crisis” has been used because The intangibility of software Even in today’s society, due to reasons such as not being ruled by the usual laws of physics and the difference in the production method, software is still viewed with suspicion by many people, managers and customers [1]. However, in their work, decisions, entertainment, education, finance, communication, health, safety, transportation, etc., people They have become reliant on software in almost every area of life. This wide use is used to solve software-intensive systems and
It also complicates the problems it works with. Academics, administrators and software experts
“software engineering” with the notion that a more disciplined and methodological approach to problems is needed developed their discipline. Despite the advances on the technical front, the required level of maturity has still not been reached. 

Accordingly, it is necessary to develop high quality software systems and manage their related projects.
mastery of the skills could not be achieved [2], [3]. Poor strategic management and related human factors are the most important failures. cited as one of the major reasons. When the source of the aforementioned problems is investigated; policies, budgeting and Problems have been observed due to non-software issues such as other external constraints [4]. However, the software if their projects are to be successful; These issues, which are not related to software engineering, are also discussed by software experts. It is necessary to know and to develop the methods of coping with these problems by the managers. Because bad management increases software costs faster than all other factors [5].

As a result, in software, which is one of the most challenging areas of our modern world, there are three fundamentals that distinguish success from failure.
factor is present. These; can be classified as technical, managerial and social reasons.

What is Failure?

Software project

• If canceled before completion,
• If it exceeds its designed budget,
• If it takes longer than the anticipated completion time,
• Meets fewer of the predetermined features and functions
it means failed. The realization of the first item above is absolute failure, while the others are Also called relative failure. Other terms used with similar meanings by the software world with minor differences are:
The term Crunch Mode is used to describe projects with extremely tight schedules. People involved in the project expresses the pressures felt by [6]. The phrase Death March has almost impossible programming
used for projects. It describes the potential sense of failure that surrounds the project team [7]. Runaway Project The idiom is used to describe projects that have been canceled or are close to cancellation [8], [9]. These terms describe a typical project. To put it in terms of: Management makes too many promises on project results in a very short period of time. found, crackling mode has been entered. While the project is in progress, after a short time the project team made this impossible to happen. To achieve the goal, he finds himself in the death march. When it is obvious that the project will not succeed, the project is no longer It’s an illegal project. In terms of success and failure patterns, the most important factors concerning the software world are as follows [10]:
• The projected delivery dates of software projects and the thought or concern of bringing them to market on time,
• The cost of developing the software application and the resources needed,
• The level of quality and reliability in the delivery of the software,
• Ease of learning and use in the operation of the software,
• Customer support and service level in case of problems,
• Ease of change and sustainability during the maturity of the application.
Although a project must meet all of the above criteria to be considered successful, it must meet the first three. failure is enough to fail.

CHAOS Study

The Standish Group, a research firm based in Massachusetts, USA, has been providing software and information technology since 1993. continues its work to examine the failures in the field of technology (IT) technology. The aforementioned software attempts to identify the extent, key factors and ways of coping with project failures [11]. 1999 Here are some numeric values included in the CHAOS Chronicles report published in 2017:

• 23,000 applications were examined.
• The cost of unsuccessful projects is US$ 75 Billion.
• Only 26% of software projects have been successfully completed.
• The rate of projects that exceeded their budget or planned time (challanged) is 46%.
• The rate of canceled projects is 28%.
• The total cost overrun is US$22 Billion.

CHAOS research shows that there is a slight improvement in IT project management (Picture-1).

Picture-1 Purple: Successful, Red: Unsuccessful, Yellow: Relative Failure

Root Causes of Software Disasters

In the following parts of the research, the reasons for failure in software projects; technical, managerial and social topics will be reviewed below.

Technical Reasons

There are many factors that cause the failure of software projects. Among these factors are the nature of the software. The complexity, which is directly related to the size of the software, comes to the fore. All software In sub-industries, large systems are less likely to be canceled or delayed.
larger than applications.

The technical reasons for the failure of software projects are listed below:

• Use of ineffective software technologies
• Selection of inappropriate software tools
• Not determining business processes
• Failure to perform the analysis properly
• No historical software measurement data
• Not selecting an active architecture
• Failure to use effective development methods
• No design reviews
• Failure to conduct code inspections
• Implementation of inappropriate, undisciplined testing methods
• Manual specification and design
• Configuration control not applied
• Uncertainty or change of more than 30% of user requirements
• Failure to use appropriate programming languages
• Extreme and unmeasured level of complexity
• Not using reusable components
• Failure to make appropriate database planning and design
• Sudden transition to using new technologies, lack of experience

Administrative Reasons

Although many process models, tools and methods have been developed in the technical fields of software engineering, It cannot be said that the same level has been reached in the field of management. Software projects are just bad bugs, bad luck, bad programmers or because of poor testing personnel, but mostly for administrative reasons [11]. Top the fact that the management is generally far from software issues and the authority (authority) they have shown in their field of expertise The fact that they cannot apply it sufficiently in this field is one of the administrative problems. With successful software projects The most important difference between failed projects can be summed up in two words: “No surprises!” Forecasting in successful projects, Planning and quality control are considered throughout the entire project lifecycle. Therefore, unexpected delays not found. Other administrative reasons that push software projects to fail are as follows: 

• Naive promises and other political pressures by senior management, marketing department or project manager
• Intense time pressure due to unrealistic estimations
• Senior management refusal of size, workforce and cost estimates
• Ignorance and indifference of top management
• Mistakes in project management practices
• The lack of a clear definition of the project purpose and scope
• Incompetence of the project manager
• Employment of unqualified technical personnel
• Finding inactive development processes
• Lack of experienced personnel in the development team
• Not using automatic estimation tools
• Not using automatic planning tools
• Not using automatic project progress monitoring methods
• Use of ineffective project change management procedures
• Little or no use of quality control approaches
• Appropriate personnel for the job, ignoring the job criteria suitable for the personnel
• Failure to comply with the software project management plan.
• Collection of inappropriate metrics or no collection at all
• Some critical tasks (quality assurance, testing, planning, estimation, database administrator, design, change
control, debugging, etc.) use of ordinary technical personnel instead of experts
• Absence or late detection of failure warning signs
• Inadequate documentation
• The development team is not informed about the business processes and the problem area.
• Intense contention caused by the globalization of the market
• The environment of contention arising from the production of new technologies
• Poor performance by software/hardware providers
• Unexpected and unpredictable depressions

Social Causes

There are also cultural and social factors among the failure patterns of software projects. Both the buyer and In terms of the provider, the culture and social structure of the institution directly affects the success of the project. client side often tends towards intense time pressure. Depending on the culture and structures of the organizations, the senior management Inappropriate advice is often a factor in the failure of projects. Most of the IT projects come with some brings drastic changes. However, the customer’s reaction to this change is often negative. In this; The uneasiness of going out of the conventional methods, sacrificing the power they hold in the current system. The feeling of having to give up and the fear of losing one’s job play a big role. Accordingly, the new system It has also been noted that, instead of supporting the project carried out for the development of observed in projects [7], [8], [9], [10], [12], [13], [14], [15], [16]. Social problems often seen in unsuccessful projects The most important reasons are:

• Poor in-team communication environment
• Inappropriate working environment of developer personnel
• Failure to receive inputs as a result of poor connection with the receiver
• Unrealistic expectations of buyers
• Experiencing severe friction between the buyer and other stakeholders
• Optimism stemming from inexperience
• Inexperienced management team
• Inexperienced technical team
• Working with inexperienced customers
• Being unaware of technological developments
• Existence of discriminatory practices in company policies
• Distance communication caused by the coldness of the management
• Weak reporting structure
• Technical personnel working under constant time pressure
• Lack of communication and support between departments and units
• Existence of complex dependencies
• Introducing new new goals linked to ambition
• Fear of being unemployed
• Feeling of revenge and hostility

Other Causes

Other than the reasons mentioned above, it is not often seen in all projects, but causes projects to fail.
Other possible factors are listed below:

• Projects to be developed for more than one city/country that are geographically far from each other
• Projects where the project contract is distributed and more than one sub-contractor is responsible
• Hybrid projects where both software and hardware are developed simultaneously
• Projects with the highest real-time constraint (space, aviation, guided missile, etc.)
• Projects developed under legal constraints
• Contracted projects where the tender criteria is the lowest bid.
• Projects of financially weak companies with risky funds
• Projects managed by companies that go to radical staff reductions or lay off key staff
• Projects with a staff wear rate exceeding 40%
• Projects with a staff increase of more than 10% per month
• Projects carried out in areas other than the general skills of technical personnel
• Projects carried out in areas outside the general experience of the management team
• Projects with a high rate of technical personnel change

Conclusion and Recommendations

Software projects are inherently complex, and complex projects require careful planning.
requires. Well-planned projects can be effectively supervised, their progress can be monitored, and their employees provides support. Clear and specific goals in planning, firm, precise and specific requirements, accurate predictions are essential for success is key. Software projects are inherently risky and cannot be successful without effective risk management.

The early and continued involvement of users in the project plays a key role in meeting the risks. Project,
time, budget, and access to other goals. To be able to carry out this control; the real project
It is possible with the help of visibility, which is defined as the determination of the state of the patient. Determined metrics, historical data Observation of progress against benchmarks and milestones providing visibility are helpers. Choosing the right architecture, development tools, languages and methods, design reviews and code inspections, use of appropriate testing methods, tool-aided regulatory inspection, and effective documentation are success factors. Leanness should be emphasized in all development phases. software development creativity, requires intelligence, entrepreneurship, persistence and motivation. All of these features are people-oriented. education, morale, Team communication and working environment are also very important. Skilled and experienced project manager and technical team It has expert personnel in critical tasks and can perform all these under the umbrella of quality.
Project groups have a higher chance of success.

Understanding the causes of failure in software projects and learning lessons from them
affect its success. After each completed project, a meeting will be held to analyze what went well and what went wrong. The studies (post-mortem), standard, method, measurement and data used in the project are recorded and the future is enlightened. It is the best opportunity to transform this knowledge into knowledge that will hold.

Sources

1. Dorfman, M. ve Thayer, R. H., Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1996, ISBN:
0818676094.
2. Pressman, R. S., Software Engineering, A Practitioner’s Approach, 4th Ed., McGraw-Hill, 1997, ISBN: 0071146032.
3. Abdel-Hamid, Tarek K. ve Madnick, Stuart E., Software Project Dynamics: An Integrated Approach, Prentice-Hall, New Jersey,
NJ, 1991, ISBN: 0138220409.
4. Thomsett, R., People Project Management, Yourdon Press, Inc., New York, NY, 1980, ASIN: 0136557473.
5. Boehm, B., Software Engineering Economics, Prentice-Hall, New Jersey, NJ, 1981, ISBN: 0138221227.
6. Boddie, John, Crunch Mode: Building Effective Systems on a Tight Schedule, Yourdon Press, New York, NY, 1987, ASIN:
0131949608.
7. Yourdon, Ed, Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects, PrenticeHall, Englewood Cliffs, NJ, 1997, ISBN: 0130146595.
8. Glass, R. L., Software Runaways, Prentice-Hall PTR, Upper Saddle River, NJ, 1998, ISBN: 013673443X.
9. Cole, A., “Runaway Projects-Cause and Effects,” Software World (UK), Vol.26, No.3, 1995, s. 3-5.
10. Jones, Capers, Patterns of Software System Failure and Success, International Thomson Computer Press, Boston, MA, 1996,
ISBN: 1850328048.
11. Jones, Capers, “Project Management Tools and Software Failures and Successes,” CrossTalk, July 1998, s. 13-17,
(http://www.stsc.hill.af.mil./crosstalk/1998/07/tools.pdf), 2003
12. Weinberg, G. M., Quality Software Management, Vol.1, Systems Thinking, Dorset House Publishing, 1997, ISBN: 0932633226.
13. The Standish Group International, Inc, “CHAOS: A Recipe for Success”, http://www.standishgroup.com, 2003.
14. Flowers, S., Software Failure: Management Failure, Amazing Stories and Cautionary Tales, Wiley, 1996, ISBN: 0471951137.
15. Brooks Jr., F. P., The Mythical Man-Month (20th Anniversary Edition), Addison-Wesley, MA, 1995, ISBN: 0201835959.
16. DeMarco, T. ve Lister, T. R., Peopleware: Productive Projects and Teams, 2nd Ed., Dorset House Publishing, NY, 1999, ISBN: 0932633439.

17. May, L. J., “Major Causes of Software Project Failures,” CrossTalk, July 1998, s. 9-12,
(http://www.stsc.hill.af.mil./crosstalk/1998/07/causes.pdf), 2003.