Software Project Failure Process Definition

,


I. INTRODUCTION
Successful software projects provide a competitive advantage to enterprises; therefore, the management of software and information technology projects is critical to the success of the organization and the careers of participating team members [1]. Conversely, the failure causes financial and moral loss, reduces or destroys expected gains [2]. Despite their importance and the spent resources, software project failure rates have remained high during the last ten years. The Standish Group CHAOS report found that the overall success rate was only 29 percent, while challenged projects accounted for 59 percent, and canceled projects for 19 percent; for big projects, the success rate is much lower and likely to be about 10 percent [3].
Many studies have investigated the top causes of failure as poor requirements, inadequate resources, unrealistic schedules, poor planning, unidentified risks [4], lack of top management commitment [5], inappropriately used technology [6], unrealistic or unarticulated project goals, inaccurate estimates, poorly defined system requirements, poor status The associate editor coordinating the review of this manuscript and approving it for publication was Ricardo Colomo-Palacios.
reporting, and unmanaged risk [7]. Management techniques are generally the main cause of problems [8], [9]. Furthermore, the specific characteristics of a project, an organization, or an external environment play an essential role in failure [10].
From an integrated perspective, project failure is a combination of several factors and multiple interrelated problems [9] that can be defined as a mistake chain [8]. However, the causes of failure are often investigated in isolation [11]. The influence of failure factors on the result of a project and the relationship between them were evaluated by conducting root cause analysis (RCA) [11], logistic regression [12], grounded theory, and latent Dirichlet allocation [13]. Researchers have generally focused on defining the causal relationships between failure factors, not explaining the team behaviors behind the failure factors. Thus, some researchers argue that existing critical success (or failure) factor models have less concentration on communication, team, project management, and product-related issues [14].
The goal of this study is to identify patterns of team behavior in the context of software project failure in contrast to previous studies. The main research questions (RQ) explored are: ''RQ1: What are the critical and recurring team behaviors that lead a software project to failure phase by phase?'' and ''RQ2: What are the transition patterns between the failure phases?''. Critical team behavior is a type of behavior that leads a project to fail by initiating an important deviation, preventing a solution, and negatively affecting overcoming events.
Because the reasons for failures create a complex network and it is difficult to address a software project failure in a linear and normative way, we first focused on identifying important team actions leading a software project to failure, and all the relationships between these actions. Then, for simplicity, we logically categorized team behaviors into failure phase definitions and highlighted the most likely transition between the phases to form a process definition.
The main contribution of this study is to formulate software project failure in the form of a process created by team behaviors behind failure factors. Identifying distinct breakpoints in the failure process supports more effectively measuring and controlling project progress and product quality and determining the future risks arising from the actions of the software team. In addition, we constructed a dataset that describes the relationship between software project failure factors and team behaviors (actions). Our failure process definition that is expressed in basic terms of behaviors supports simplifying communication between software developers, non-technical managers, and other stakeholders while enabling a concise description of higher-level concepts [11].
The remainder of this paper is organized as follows. Section 2 introduces related works from the software project management literature and defines the gap in the existing literature. Section 3 presents the methodology to define the failure process. Section 4 contains a systematic analysis of private and public case study results via qualitative grounded theory, quantitative design structure matrix (DSM), and Bayesian belief network (BBN) methods. Section 5 answers the research questions and discusses the results, the structure of the overall failure process, and threats to validity. Finally, Section 6 presents conclusions and future work.

II. BACKGROUND AND RELATED WORKS
In this section, the focus is to investigate existing work on failure progress in software projects and the prediction methods of software project failure to establish the justification for the contribution of the systemic failure process definition. We discussed basic concepts of existing methods such as risk management, root cause analysis, and anti-patterns that were used to define or evaluate software project progress and their effectiveness when failure arises in a project.

A. EXISTING FAILURE PROCESS DEFINITIONS
The mistake chain, which can be accepted as a process, is one of the main causes of failure for various project types. Mittelstaedt [8] defined mistake chains as follows: ''The root causes of project failure depend on similar human behaviors, biases, and blind spots''. He identified sequences of mistake chains as follows: ''1) An uncared initial problem, often minor in isolation, 2) Subsequent problems that increase the effect of the initial problem. 3) Inept corrective effects, 4) Disbelief that accelerates seriousness of the situation, 5) Generally, an attempt to hide the truth while attempting to remediate, 6) Sudden recognition that the situation is out of control 7) Finally, a total failure that causes significant loss''. However, software engineering requires a specific definition of the failure process, because it differs from other engineering disciplines owing to its essential difficulties such as complexity, relevance, mutability, and invisibility [15].
Even if there was no general process definition for software project failure, the researchers aimed to reveal notable phased definitions in the evaluation of failure. Jones stated [16] that ''most troubled projects, the trigger point for alerting clients and senior management occurs when a late milestone. . . is missed and. . . several well-known software disasters were not anticipated until the very day of expected deployment! Obviously, technical personnel and even many low-level managers were aware that things were not going according to plan, but the political pressures. . . are often so strong that no one wants to give bad news. . . When the problems finally become so serious that they can no longer be ignored, it may well be too late . . . , and hence the project is canceled or terminated''.
Glass combined some previous work [6] to create a process that consists of crunch mode, death march, and runaway steps. Boddie [17] defined crunch mode as there due to a threat reaching its original target, and a project team was working very hard to overcome this dilemma. Yourdon [18] defined death march as the parameters of a project that exceeded the norm by at least 50 percent, and the project had a nearly impossible schedule. KPMG characterized runaway projects as failing significantly to achieve their objectives, exceeding their original budget by at least 30 percent [19], and getting development efforts out of control.
The existing identification of failure modes provides important insights for understanding the status of software projects. However, even their literary values, these terms do not directly reflect the attitudes and behaviors of a team against deviation; their process definitions are independent and do not cover the whole process; some of their phases are intersected.

B. FAILURE PREDICTION METHODS
Failure prediction methods identify the factors and risks that affect a project's success or failure by reviewing and investigating resources and analyzing the relationship between predictors and outcomes [12]. A causal model for software project failure should completely determine the causal relationships affecting failure [11]. RCA allows the identification of causal relationships between the detected causes of project failures in basic or categorized forms as shown in Fig. 1a and 1b [20]. It produces root causes related to all process areas such as implementation, requirements, management, software testing, and deployment [11], [21]. Additionally, logistic regression is another method to help project managers to assess expected failures [12]. In risk analysis and RCA, the root causes at the deepest level may or may not be related to team behaviors, although some studies categorize failure factors and examine management as a separate category [11]. Additionally, one team action may drive and assign to many failure factors. Thus, the identification of team behavior behind the failure factor and the connections between team behaviors leading a project to failure become unclear and ambiguous. For example, Boehm's top ten risk items contain many risks (failure factors) such as unrealistic schedules and budgets, developing the wrong functions or user interface, gold-plating, and straining computer-science capabilities [22]. The definitions of root causes are also similar such as unrealistic project objectives, team technical problems, lack of user involvement, requirement instability, problematic technology, etc. [12].
Another key aspect driving our research is that existing failure models, such as RCA-based models, have complex representations for non-technical people as shown in Fig. 1.
Whereas, process quality models should provide explicit viewpoints and meet the needs of diverse stakeholder groups for a wide range of applications [23]. Management looks at the connection between the team structure and the problem domain to understand who owned the problem instead of complex explanations [24]. Thus, a new perspective is required to enlighten managers and customers about the progress of failure in software projects.

C. ANTI-PATTERN DEFINITIONS AND FAILURE PROCESS
Failure process definition can be considered an anti-pattern. Anti-patterns provide a common vocabulary for identifying problems, defective processes, and implementations. They provide useful insights into understanding the relationship between failure and its causes. However, from an integration perspective, common anti-patterns were presented as lists where they were isolated from one another [11]. The relationship between project progress and the time when the anti-patent symptoms appear is not clear except for rare and independent examples such as escalation commitment (continue against failure) [25], fire drill (forcing immediate delivery after slack time) [11], and death march (trying to catch impossible schedule) [18].

III. METHODOLOGY
We aimed to identify and extract behavioral failure patterns from case study data. Thus, we required methods to collect case study data, detect important patterns in the data, and qualitatively and quantitatively identify and analyze the connections between them. The main steps of the proposed methodology are shown in Fig. 2: (1) We researched relevant literature to derive the structured questions. (2) For qualitative analysis, we collected private and public case study data and analyzed them with grounded theory to identify team behaviors behind failure factors for building the failure process definition. We investigated teams' responses to each failure factor by examining failure causes and their context until reaching the team behaviors behind failure. It allows further analysis to understand how teams' failure responses were represented in terms of concepts, categories, and relations.
(3) We applied quantitative research based on DSM and BBN to evaluate the transitions between phases.
We reviewed the literature and noted the similarities between case studies and anti-patterns with our code definitions to validate our findings. We also benefited from the definition, causes, symptoms, and consequences of similar anti-patterns [26] such as escalation failure and death march.

A. QUALITATIVE ANALYSIS
Our grounded theory-based case study data analysis contains the following interweaving steps: building memo questions from a literature analysis, theoretical sampling, constant comparison, coding, and saturation [27]. We preferred the Straussian grounded theory approach because it allowed for a general idea of where to begin, forcing the theory with structured questions [28], providing rigorous procedures, and techniques for analyzing interpretive case study data [29]. We evaluated the results employing credibility, transferability, conformability, and dependability criteria [30], [29].
Corbin and Strauss [31] claimed that some surveys in the literature supported researchers to initiate a research project with some knowledge of the phenomenon being studied. Moreover, literature can be used to derive questions that largely determine the research methods and establish the boundaries of the study. These questions represent memos in grounded theory and are called memo questions. We built memo questions and linked them to pertinent expressions [32] to identify the context of team activities. The answers to the memo questions referred to previous and subsequent actions against failure factors that identified the code, connections, and categories.
Theoretical sampling [31] supports identifying what data to collect, where to find it, when it appears, and the selection of data sources when choosing the sample case studies in our study [33]. Thus, we filtered out case studies whose chronological order was unreachable because of the order required to detect transitions between phases. Therefore, because the failure process should be traceable and auditable to identify key points, we excluded failed projects that even if careful change management procedures were conducted, a suddenly appeared internal or external factor such as unexpected customer or manager decision led to a huge deviation and termination.
To detect failure factors, we accepted each person involved or contributing to the software project progress as a member of the software team, including the project manager, developer, sponsor, customer, or top manager.
The definition of software project failure is also important to choose appropriate case studies; however, it is imprecise and varied. Project management literature has many different failure definitions [34]. Generally, they are based on the degree of match or mismatch between design and reality of process and objectives [35]. We accepted the definition of failure as failed software projects are over budget and not delivered on time [36]; they do not create the impact they should have delivered [37], abandoned, or canceled with loss of investment [38]; they do not create client benefits or are excessively deviated from its budget and schedule [39].
Grounded theory-based data investigation involves incremental and iterative applications of three types of coding: open (identifying, naming, categorizing, and describing phenomena), axial (relating codes to each other), and selective (choosing a core category and relating it to other categories) [29]. We evaluated raw data of one case study on a sentence-by-sentence basis in each iteration to derive codes, concepts, and categories. The main steps are as shown in Each iteration investigating a case study requires the constant comparison and update of incidents, codes, and categories with previously collected data [40]. The constant comparison allowed us to control the data collection process and ensure the consistency of codes with data and other codes.
We considered different perspectives and actions of team members involved or contributing to the project's progress to conduct an integral and persuasive analysis [40]. We chose the most dominant action as a key point leading a project to failure even if there were objections from other members.
In open coding, we detected key points and assigned them with labels to build codes by summarizing incidents via team behaviors; the labels make concepts that support capturing and collecting the main objects, instances, incidents, and actions on the data [41].
The outcome of open coding was categories that supported the identification of concepts from the data by grouping similar concepts into categories or subcategories. We noted the chronology of events to use the order of codes in axial and selective coding. In axial coding, the open codes were compared and categorized into code groups by looking for similarities and differences to construct axial codes. In selective coding, core categories defined by axial codes and their chronological order were refined to the conceptual and narrative description of the storyline of the failure process definition.
Theoretical saturation was evaluated to determine whether adding new data resulted in an update of the established theory [42] by examining the pattern of emergence of new concepts and transitions throughout the research process [23]. We calculated and visualized the cumulative sum of newly identified concepts and transitions to control saturation.
We first applied grounded theory to information from private failed case studies in various software development areas using memo questions. For enhancing credibility and decreasing subjectivity, we wrote down the speeches and evaluations of team members or reporters directly by avoiding interpretation. The main parameters used to define key failure incidents and behaviors were as follows: • Important event: A critical incident, behavior or action creates a milestone in project progress toward failure by affecting the overcoming events. The attributes of the event are the cause of failure, the initiator, the time of the event, the next event, and the problem scale.
The sources of information were meetings, reports, and emails.
• The ratio between the actual and expected number of users: Significantly lower numbers than the expected user numbers indicate failure. We evaluated high user numbers considering user satisfaction and productivity, because a manager may force end-users to use the system unwillingly. The sources of information were onsite observations, meetings, and system-usage logs.
• User satisfaction: It demonstrates the quality and content of interaction between the information produced by the system and the recipients [35]. On-site observations and meetings were the main resources for understanding a user's satisfaction level.
• Developer viewpoint: On-site observations and meetings were the main sources for obtaining a detailed understanding of developers' perspectives on project progress. After completing the private case study analysis, further sampling was required to fill the gaps in the credibility and transferability of the emergent theory. This led to the public case study search and analysis. The data collection methods were different for private and public case studies; thus, we conducted the grounded theory coding process for them separately. However, we employed the same parameters and methods in analysis to maintain the standard grounded theory approach, which required an integrated coding process.
The public case study analysis was provided to improve the credibility and transferability of previous codes by saturating them using well-known failed and overbudget software project lists [6], [43]. To increase credibility, we gathered data from multiple sources such as public records, articles, newspapers, published reports, and official statements [44]. To ensure transferability and applicability, we evaluated the generalization of the findings by comparing the outcomes of private and public case studies and checking whether the same results were obtained in other contexts with similar properties and codes [29].

B. QUANTITATIVE ANALYSIS
Modeling a process requires decomposing the process into steps, determining transitions among the steps, and analyzing the sequence of the steps into a process flow [45]. The quantitative assessment of process definition via DSM and BBN unveiled the probability of relationships between core categories in selective coding. The inputs of quantitative assessment were the codes, occurrence numbers, and chronological order of codes identified by grounded theory. The output was the transition patterns between failure phases. DSM is a system modeling tool that can represent system elements and their relationships in a compact way that highlights important patterns in the data [45]. It is a square matrix with identical row and column labels. A quantification scheme (not categorical) and time-based DSM were utilized for analysis. In time-based DSMs, the ordering of rows and columns indicates a flow-through time: upstream activities in a process precede downstream activities. In our work, the DSM represented the general characteristics of the system model via the chronological order of phases. However, an additional model was required to express the probabilistic relationships in the entire system.
Thus, we employed the BBN to represent the conditional dependence of phases in a directed graph that encodes probabilistic relationships among variables of interest [46]. A BBN utilizes a probability table that is associated with each node, providing the probabilities of each state of a variable and it provides a graphical representation of the causal structure using directed acyclic graphs [47].

IV. RESULTS
This section reports the grounded theory analysis results of case studies, followed by quantitative assessment results of the DSM and BBN methods. Four questions arise from the literature when considering team actions against failure, as shown in Table 1. The literature suggests a categorization of problems associated with their visibility and scale as minor, medium, and large [8], [16], [17]. Thus, the first three questions represent the team's answers to the progress of a problem as initiating, getting bigger, and serious or out of control. The fourth question address the actions of software teams when a failure has a high probability or is inevitable.

A. PRIVATE CASE STUDIES FOR INITIAL PROCESS DEFINITION
We gathered chronological failure data and critical incidents from seven failed software projects from different business sectors and software types to evaluate the failure progress in software projects. The context of these case studies varies from in-house software development to an extensive range of software applications such as document management, prototyping, and outsourcing. Private case study histories, matching memo questions, open codes, and resources are briefly presented in Supplementary Material A. The projects' general attributes are the goal, team structure, and team experience. Additionally, the approximate values of numerical attributes were given as team size, duration, budget, and company size. Analysis software (ATLAS.ti) was used to map the logically related open codes to the code groups and code groups to axial codes. More details of the coding activities for private case studies can be found in Supplementary Material. B. The axial code analysis is presented in Table 2. The real names of the companies and projects were omitted to protect company information.
Open codes represent the direct behavioral responses of a team to a failure factor. The mental preparation and intermediate processes were not the main focus of interest. For example, in case study 1, MQ1 related to the problem expression as ''The large payments attracted many vendors to submit proposals without considering inconsistencies.''. It can be evaluated as ''wishful thinking'' or ''desire for money'' for the vendor. However, our open code definition was a combination of the failure factor or problem source as ''inconsistencies in analysis'' and the team action against the problem as ''ignoring''.
In axial coding, we attempted to assign the most comprehensive term covering specific variants of team behaviors to axial codes by considering the occurrence frequencies and  Table 3 contains the transitions between axial codes that were obtained from the notes in the open code section of Tables 1-7 in Supplementary Material A. The number in a cell corresponds to the next axial code. The occurrence rate was calculated by dividing the number of occurrences by the total private case studies number (7). EP was omitted because all failed projects ended up with the same phase.
The selective coding revealed the generic process and phase definitions via axial codes. The narrative description of the storyline: The failure process starts with small slippages of the tasks; however, the team ignores warnings or deviations. As the harmful effects of deviations appear, the team VOLUME 10, 2022  tries to reject the deviation first; however, when the deviation exceeds the limits, panic begins to catch the plan. After the committed finish date is missed, the project team attempts to save investments and continue the project against negative conditions. When corrective actions are not implemented on time, stakeholders lose interest and decrease their support; thus, termination is inevitable.
The cumulative sum of identified new concepts for each case study diminished quickly, as shown in Fig. 4. This indicates the maturity of the proposed model was high for phase definitions; therefore, adding further case studies would be unlikely to discover significant numbers of additional concepts [23]. However, the number of transitions between phases (axial codes) was more gradual, indicating a lower level of theoretical saturation. Thus, we further examined the transitions in evaluating the combined codes of private and public case studies using DSM and BBN methods.

B. SATURATING THE PHASE NAMES AND TRANSITIONS WITH PUBLIC CASE STUDIES
The main purpose of the public case study analysis with grounded theory was to further saturate the initial codes using the well-known, failed, and overbudget software project case study lists [6], [43]. Additionally, we searched the databases IEEE Xplore, ScienceDirect, ACM, and Google Scholar using the following combinations of keywords: software project failure, failed case study, failure process, phase of failure, and failure phase. The data collection principles were (1) using multiple sources of evidence, (2) creating a case study dataset, and (3) validating data [48]. The literature search resulted in a collection of more than 100 academic research papers, resources, and books, including case studies of software project failures. We investigated 15 projects with a failure history in the case study resources, as shown in Table 4. To represent the relationship between the gathered information and its context, a full set of data and transitions are provided in Supplementary Materials C and D, not to overextend the article.
Nine new open codes emerged from public case studies. The conceptual meaning of these open codes allowed us to map them to the existing axial codes as (IW -misunderstanding requirements, starting with unreachable requirements, ignoring constantly changing requirements, starting with known problems, ignoring too long plan issue), (RD -hiding deviation, continue as there is no problem, underestimating deviation), and (EF -indecision to continue or terminate, slipping scope or schedule constantly). Because the usage frequency of losing control was higher in public case studies, and it had a more comprehensive meaning to map with conflict in team, it was replaced with getting into panic. Table 5 contains the transition information and occurrence rates of public case studies. The number of new open codes was relatively low. This indicates that our process definition was near saturation; therefore, an additional case study analysis would not produce significant differences.

C. QUANTITATIVE EVALUATION
The occurrence rates of the phases are shown in Fig. 5. They are higher than 80 percent for private or public case studies on average. The only exception is the occurrence of rejecting deviations phase in private case study analysis.
The total number of transitions between the phases is given by the DSM in Table 6. The matrix as a quantification scheme facilitates weighting the interactions relative to each other. n ij is the total number of transitions from phase i to phase j and reveals the other phases followed by i. The marks below the diagonal are called feedback marks and the marks above the diagonal are called feedforward. The probabilistic relationships of the transitions between the phases were evaluated using the BBN. The standard BBN representation contains a detailed table with each node providing the probabilities of each state of a variable.   However, for simplicity, we represent only the joint probability of transition on the edges calculated using the following equations: where n is the total number of case studies and n i is the number of occurrences of phase i. n ij is the number of transitions from phase i to phase j, and t i is the total number of transitions initiated from phase i. PT (ij/i) is the joint probability of a transition from phase i to phase j which is defined as: Fig. 6 shows the BBN analysis results of the proposed failure process model. The nodes in the graph are phase names, while the edges represent the joint probabilities of the transitions between phases. The transition with the highest probability value between two phases is highlighted by a thick line to illustrate its importance. The feedback transitions are represented by dashed lines.

V. DISCUSSION
In this section, we discuss the outcomes of our work concerning the research questions and compare our findings with those of previous studies on project failure. We have defined the phase details and highlighted the threats to the validity of our conclusions.
A. ANSWERING THE RESEARCH QUESTIONS RQ1: What are the critical and recurring team behaviors that lead a software project to failure phase by phase?
Answer 1: Our findings suggest that similar team behaviors are perceived in failed software projects, whereas the apparent failure symptoms are different. The phase definitions created by grouping and categorizing codes have high occurrence rates in the case studies as shown in Fig. 6. On average, similar phase definitions appeared in 89 percent (standard deviation 6.8 percent) of case studies.
RQ2: What are the transition patterns between the failure phases?
Answer 2: The joint probability of transitions indicates that the order of IW → RD → LC → EF → LS → EP is more frequent than that of other paths as shown in Fig. 6. The probabilities in this path have at least twice as much frequency as backward and forward jumps although some have low probability values. Thus, we accept this as the primary path for defining the failure process.
Our findings contribute to previous studies on building an integrated software-specific failure process model with standard phase and transition definitions. Table 7 summarizes the intersections and shared concepts between existing definitions from the literature and the proposed failure process; they indicate a reasonable consistency of content. However, existing software-specific anti-patterns have isolated definitions and the general failure process does not include some of them. For example, escalating failure and losing support phases did not exist in the mistake chain [8] while rejecting deviations was emphasized in the passive form as the mum effect [77] or hiding the truth [8]. The central role of these differences is the essential difficulties of software development that make measuring the correlation between outcomes, objectives, and progress difficult especially, for non-technical people. In other engineering disciplines, such as civil or mechanical, the team can see the whole product at once; hiding problems is not easy and may not result in extreme situations [78]. In a construction project, the visibility of the outcome causes a delay to be realized almost immediately [79]. Minimal technical knowledge can be sufficient to evaluate the overall progress.

B. DEFINITION OF SOFTWARE FAILURE PROCESS
The main outcome of this study is the definition of a process model for failed software projects. At the beginning of the process, early warning signs arise; however, there is no visible indication of failure. The project team does not understand the overall problem and ignores warnings. In the rejecting deviations phase, the significant deviation is visible to the team; however, the majority of members do not accept the importance of the problem and tend to mask the problem hoping to overcome it without attracting the scrutiny of executives and other stakeholders [2]. When deviation from the schedule exceeds the nominal limits, the team loses control and unconsciously attempts to rescue the project. Escalating failure occurs when the team continues to invest even through negative events and missed results. After a long unproductive escalation cycle, the project loses the support of clients or sponsors, causing its termination.
We prefer the term ''the software project failure process'' to express the process leading a project to failure. Another possible term may be inspired by nature, such as the waterfall  process as ''the swamping process''. The more you struggle unconsciously, the more you sink until you drown. More importantly, you will lose your chance to rescue. ''Sink'' was also used to identify runaway projects in the literature [6].

1) IGNORING WARNINGS
This phase refers to a situation in which the software team underestimates or ignores warning signs and the initial emergence of deviations, leading to project failure in the future. Brooks [15] asked the question, ''How does a large software project get to be one year late?'' and answered it as ''One day at a time! Incremental slippages on many fronts eventually accumulate to produce a large overall delay''. All project tasks are linked in a complex decision network; thus, total failure can be initiated by the first wrongdoing in the tasks and/or decisions that aggregate and accumulate into more critical problems [24].
Early warning signs arise as predictions, cautions, or alerts to possible or impending problems. They provide an assessment of risks, future difficulties, and failures during project development [1]. They do not directly represent a major crisis but indicate a need for further investigation to prevent the start of a mistake series [10]. Lui and Chan [79] reported that the dynamic and multifactorial nature of many software project problems may prevent immediate or even timely identification of root causes. Moreover, the intangible nature of software makes it difficult to estimate the proportion of work that has been completed [77]. Project managers are often missing the appropriate response to early warnings in many cases [80].

2) REJECTING DEVIATIONS
In this phase, the project team intentionally rejects problems or withholds bad news about the project status, as the scale and visibility of deviation increase. The reluctance of people to report bad news about a troubled project is called the ''Mum Effect'' [77]. This could be a major contributor to the phenomenon of uncontrollable (runaway) software projects [81]. As a passive version of rejecting deviation, it may disrupt communication between team members [82] and occurs very frequently [82], [83]. Snow et al. [83] claimed that biased, generally optimistic status reporting occurs in more than 60 percent of projects.

3) LOSING CONTROL
The losing control phase represents the unconscious attempts of a software team to rescue a project after skipping an important milestone or finish date. It is similar to the crunch mode reported in the literature. Huang and Han [84] stated that as the date to deliver the slipping milestone approached, teams tried to compensate for the lost time by forcing a team to work more days and hours per week, developers sleeping on the floor for days on end. The exhaustion leads to more bugs that need to be fixed and causes wasting even more time. The delay may affect the management to initiate multiple forms of coping strategies aiming for the same goal [85]: ownership problems, no owner or more than one owner can create political fighting and convert a small problem into a big issue; moreover, team members may be firefighting with or even withholding their problems without considering how these problems might create other problems [79]. The team members stop moving according to the plan and try to catch the schedule unconsciously by focusing on only their tasks.

4) ESCALATING FAILURE
Keil and Mann's [25] description of the escalating failure is parallel to our findings as ''continued commitment against negative information'' and ''an escalation cycle starts following a series of negative project events and the commitment of more resources when decision-makers neither decide to abandon the project nor take corrective actions despite unambiguous negative feedback''. Keil et al. [86] used it to explain ''troubled projects were continued instead of being abandoned or redirected''. According to Keil and Mann [87], 30-40 percent of all information system (software) projects involve some degree of project escalation, the average escalation time is 21 months, and less than 25 percent of the escalated projects are completed or implemented. The causes of escalation are more than simple mismanagement of projects and can be psychological, social, and organizational [87].

5) LOSING SUPPORT
This phase refers to losing support of customers, managers, or other stakeholders because the development process does not meet their requirements and expectations on time. The key reason is the loss of sponsorship support in 80 percent of project abandonment [37] similar to our findings. The management of stakeholders leads a project to success or failure [14]. The withdrawal of a sponsor or stakeholder already contributing to the project has a more detrimental effect on perceptions of project success than starting without a sponsor [88]. Without the strong support of the organization's managers and sponsor commitment, developers perceive little chance of project success [88], [89].

6) ENDING PROJECT
If there is no way for a project to be completed, the terminating project is natural and even healthy [90]. In this phase, the business goal shifts to terminate the project with minimal losses. The primary actions are preparing a termination plan, managing public relations crises, and learning from failures.

C. THREATS TO VALIDITY
In this section, we address increasing the validity of our work by minimizing the risk of potential threats. For dependability, we conducted a systematic and well-documented research process. Therefore, we have provided the raw data and analysis procedures with the intermediate results of the qualitative and quantitative analyses to ensure confirmability. Other researchers can evaluate the code, phase, and transition definitions from different perspectives using raw data and analysis notes to unveil new concepts.
The credibility of this research inherits some internal limitations from the grounded theory. Grounded theory might restrict the potential of the data and the creativity of the qualitative analyst, and it may be influenced by the personality, experience, or perspectives of researchers [41], [91]. To overcome this bias and increase credibility, we collected data from multiple sources using various methods. Individuals and companies withhold information about their failed project with feeling guilt or shame; hence, some details may have been missed. To overcome this problem, we examined 22 case studies (private 7 + public 15) that exceeded the ideal limit to build a theory defined between 4 and 10 [92]. In addition, we researched many papers or websites for each case study to gather data for cross-validation.
A threat to the transferability of our process definition was the effect of bias in case study selection and the data collection process. We increased diversity by researching projects of different scales and domains to mitigate this threat. Moreover, we saturated our process definition by adding public case study data and comparing them with private case study data. The comparative analysis facilitates a decrease in a threat related to the generalizability of the findings that appears the selected sample of case studies is not sufficient to represent different perspectives to be generally applicable [23]. We assessed that the effect of this threat decreased significantly in the final version of the process definition as relatively few new concepts arose in public case studies.
Another validation technique for results discovered using grounded theory is a literature search [41]. The parallel definitions in the literature and our process model indicate consistency between existing studies and our process model as demonstrated in Sections 5.1 and 5.2. The existing studies contain similar observations, symptoms, and outcomes; however, their definitions are isolated and not integrated into a failure process.
Employing an additional analytic strategy can produce credible and dependable research findings [91]. Thus, we supported grounded theory with quantitative DSM and BBN approaches. The quantitative methods highlighted the main path of failure process definition by analyzing the transition probabilities. However, the quantitative evaluation also revealed a significant number of feedbacks and feedforward jumps between RD, LC, and EF phases that may have weakened the failure process definition and external validity. The main reason behind this was the difficulty in finding the full chronology of failure stories because many studies have investigated failure causes in isolation [11]. Moreover, people, projects, and organization-specific reasons can differentiate the failure process. The exceptional feedback and feedforward transitions also appear in other development processes, and their probability values are too small to distort the failure process definition.
There are some other limitations to our study. First, informants' perceptions may have biased the collected data samples; although, we preferred to use multiple data sources for each case study. However, the addition of more failure cases may not have eliminated the perceptual effect. To reduce the effect of this limitation, surveys can be conducted to define the failure process through expert validation. Second, because there is a lack of research and datasets directly investigating the relationships between team actions behind failure factors in the software engineering literature, for some case studies, we had to collect data from unusual sources such as newspapers or websites for scientific research to generate a novel chronological dataset on software project failure. This may have adversely affected the quality of this study.

VI. CONCLUSION
The principal contribution of this study is a failure process model for software projects. The model reveals critical team behaviors and transitions among them leading a software project to failure. It was derived from a comprehensive case study search, qualitative grounded theory analysis, quantitative DSM, and BBN methods.
The important theoretical and practical implications of the results can raise the awareness of researchers, software professionals, managers, and other stakeholders to evaluate a more realistic picture of project failures, failure milestones, real progress, and estimate future incidents. From a theoretical perspective, the researcher can use the methods, intermediate analysis notes, and dataset in our study as inputs for new research to further understand software failures and develop methods for successful projects. Additionally, thinking failure as a process can create a scientific background to develop and offer models for improving process monitoring and control tools. From a practical perspective, our process model, which has simple behavioral definitions helps software teams and managers to identify and manage the deviations and risks in software projects. Thus, they can handle and prevent the spread of failures in a project's progress by an in-depth understanding of initiating team action.
Although we believe that the results of this study will be useful to understand the progress of a failed software project, there are some requirements for further research on failure in software development process methodologies and phases. The first improvement would be to match failure phases with their solutions that support important insights for identifying solution methods. The second improvement is systematically elaborating the connection of the software project failure process to various software development process models, such as waterfall, incremental, agile models, and their phase definitions. Another future improvement is a domain-specific analysis of the failure process. There are important domains that can be investigated specifically, such as the back-end, system, and real-time software. Additionally, predictive modeling using computational intelligence for the effects of failure factors, personal roles, and personal characteristics on failure phases can reveal useful concepts. It will be interesting to extend this study by examining the subphases of the primary failure phases.