Failure Of Software Development Projects Research Articles

Agile software development projects–Unveiling the human-related critical success factors

ContextInvestment in information technology is associated with better business performance when its implementation is successful, but it has high costs in case of failure, especially for large software development projects, which typically have the highest failure rates. Agile methodologies emerged with the expectation of reducing the risk of software development project failure. ObjectiveThis research aims to answer the following question: What are the human-related critical success factors for agile software development projects to succeed? The research model comprises four explanatory variables (team capability, customer involvement, psychological safety, and team autonomy) and one dependent variable (success of agile software development projects). MethodA questionnaire-based survey was carried out, resulting in 177 valid responses. A Partial Least Squares (PLS) analysis was performed to test the theoretical model. ResultsThe findings indicate that team capability and customer involvement have the strongest effects on the success of agile software development projects. The results also show that psychological safety is a significant indirect success factor and that team autonomy appears to have a competing dynamic with psychological safety on the other two factors. ConclusionTo the best of our knowledge, this is the first study to examine the direct impact of psychological safety and its indirect effect, mediated by team capability and customer involvement, on the success of agile software development projects. The mediation, moderation, and direct effects are studied, offering theoretical and practical insights.

The use of prototypes to bridge knowledge boundaries in agile software development

AbstractBridging knowledge boundaries among project team members is essential to prevent delays or complete failure of software development projects. Prior researchers have reported that software prototypes can be used to help bridge knowledge boundaries between team members in traditional software development settings, yet their use in an agile development setting remains unexplored. Agile development centers the interactions between team members on emerging representations of the prototype whose properties are prone to change over time. Therefore, we conducted an in‐depth study of an agile development project to enhance our understanding on how software prototypes are used as boundary objects in a distributed team setting. Our analyses of team member interactions during 46 virtual meetings that took place over a period of 6 months revealed four different prototype use practices (exemplifying, contrasting, relating, framing) that were effective in bridging syntactic, semantic, or pragmatic knowledge boundaries. We also provide empirically grounded evidence of how variations in object properties can afford different use practices, how the use practices take advantage of these properties, and how object properties are reshaped through these use practices as different types of knowledge boundaries are bridged. These findings bear important implications for research on prototypes as boundary objects in software development in particular and boundary object use in general.

Exploratory Factor Analysis for Software Development Projects in Mexico

Time and risk management have always been major concerns in a continuously growing number of processes or methodologies used to develop all kinds of useful products and services. Software like any other industry not only needs the most appropriate development methodology but also an efficient project management strategy that is capable of estimating and managing development times and any potential risks as best as possible in order to deliver high quality software products and services on time. Hence, the success or failure of software development projects depends on the efficiency by which several key factors such as cost, time, and risks are managed and how other software development factors influenced them. This paper presents an exploratory factor analysis to study the effects produced primarily on time planning caused by common factors observed in outsourced software development projects such as communication, teamwork, personnel training, among others. In our work, we also build a structural model in which we analyze the relationships between sets of dependent and independent variables derived from the responses of a survey applied to 32 Mexican organizations that subcontracted their software development projects to outsourcing providers. The results are presented and the reliability of our model was validated using the SmartPLS software.

Software Development: Cowboy or Samurai

Much has been written about the failure of software development projects. The importance of good software to business cannot be underestimated. A major issue is quality of the software being written and produced. Over the years, the emphasis for improvement in software development has been to change the process. Unified Modeling Language is but one of a long line of changes in software development process starting with structured programming introduced in the seventies to object oriented programming in nineties. However, several software development experts have begun to assert that the problem may not be with the process employed but rather the human asset, namely the software developer. This paper discusses two extremes of software developer behaviors. These two ends of the spectrum are the cowboy, free of restrictions, and the Samurai, following a strict code of behavior. The paper first presents the characteristics of the cowboy and the Samurai then the paper compares the development environment within which each behavior is suitable. The paper concludes with a summary and industry observations.

An Information-Entropy-based Risk Measurement Method of Software Development Project

Risk is the major reason for the failure of software development projects. The risk measurement can provide the decision-making data for the risk management and control. The traditional risk measurement method usually assesses in terms of the occurrence probability and the loss of the risk factors, which usually are assessed by experts subjectively. Therefore, they are greatly influenced by artificial factors. In this way, it is difficult to realize the objective and effective measurement. This paper proposes one risk measurement method of software development project based on information entropy, which makes up for the shortcomings of the former studies. This method makes use of information entropy to measure the amount of information so as to measure the software development project risk. In this paper, a new risk checklist is given. First of all, it obtains the risk information through the checklist. Then it obtains the information amount of risk factors by aid of information entropy. This paper concludes that the larger the information amount of the risk factors is, the larger the removed uncertainty is, the smaller the information entropy is and the smaller the risk is. In short, there is a positive correlation between risk and entropy. This paper demonstrates the scientificity and rationality of the method theoretically. Compared with other risk measurement methods, this method manifests certain advantage. The case analysis prove the rationality and feasibility of this method.

The impact of Software Process Maturity on Software Project Performance: The Contingent Role of Software Development Risk

Despite growing efforts to improve software development processes, recurring concerns about software project performance remain largely present. The rate of software development project failure rate has been routinely documented in information systems (IS) research (Wallace, 2004; El-Masry and Rivard, 2010). The management of software development projects is often marked by inadequate planning, a poor grasp of the overall development process, and no clear management framework, even as the focus in software development shifts from a technology perspective to a more process-centric view (Slaughter, 2006). To address such concerns few CMM-based studies have examined the benefits and direct impact of software process maturity on software project performance but with mixed results. The present paper attempts to systematically examine the contingent role of software development risk on the impact of software process maturity level on software project performance. Guided by risk-based perspective in Software Engineering and CMM-based framework, an exploratory model was developed and tested. The premise of this paper is that software development risk plays a contingent role in the relationship between software process maturity and software project performance. Drawing on a sample of 107 organizations that have undergone official CMM appraisals, the results of partial least squares analysis of the data reveal initial evidence that (1) a positive effect of software process maturity level on software project performance while underscoring the negative effect of software development risk on software project performance, and (2) more importantly, the findings show that software development risk plays a contingent role software process maturity level on software project performance. For researchers, the integration of software development risk can provide a much needed linkage in the three fundamental constructs of CMM. From a managerial perspective, in order to foster a better software project performance, IS project leaders and managers should strongly emphasize devising effective software development risk assessment since a variation of this construct’s level may strengthen or weaken the relationship between software development process maturity and software project performance.

Factors that motivate software engineering teams: A four country empirical study

Motivation, although difficult to quantify, is considered to be the single largest factor in developer productivity; there are also suggestions that low motivation is an important factor in software development project failure. We investigate factors that motivate software engineering teams using survey data collected from software engineering practitioners based in Australia, Chile, USA and Vietnam. We also investigate the relationship between team motivation and project outcome, identifying whether the country in which software engineering practitioners are based affects this relationship. Analysis of 333 questionnaires indicates that failed projects are associated with low team motivation. We found a set of six common team motivational factors that appear to be culturally independent (project manager has good communication with project staff, project risks reassessed, controlled and managed during the project, customer has confidence in the project manager and the development team, the working environment is good, the team works well together, and the software engineer had a pleasant experience). We also found unique groupings of team motivational factors for each of the countries investigated. This indicates that there are cultural differences that project managers need to consider when working in a global environment.

Reducing failures in software development projects: effectiveness of risk mitigation strategies

Risks as uncertain conditions with negative consequences on a software project could increase the failure rate of a project if it is ignored. To identify the effectiveness of risk management strategies, a questionnaire survey among over 1000 software professionals was conducted. Post Hoc Multiple Comparison Test and Kendal’s non-parametric test were employed to analyse risk mitigation strategies in terms of effectiveness in reducing time and cost overruns. Findings reveal risk mitigation strategies related to the technical part are not as efficient as that in the managerial part such as the users’ involvement and commitment in reducing time and cost overruns.

People, Organizational and Technological Dimensions of Software Requirements Specification

A software specification can be defined as a short statement of the requirements that the software must assure. Through these requirements, software must provide facilities or capabilities to users, enabling them to achieve the specified organizational objectives. Nevertheless, the inappropriate specification of requirements is still considered one of the reasons for the failure of software development projects. One of the reasons that may explain this failure is that requirements specification tends to overvalue the technology side of requirements. Good requirements are only assured by the right combination of three dimensions: people, organization and technology. This paper reviews significant literature about software requirements management, particularly software requirements specification, identifying major issues and concerns. Through the lenses of each one of these three dimensions, several important facets of software requirements specification are analyzed, covering each of their main quality attributes. Implications for future research are discussed.

Software Requirements Management through the Lenses of People, Organizational and Technological Dimensions

The inadequate specification of requirements remains being indicated as one of the main reasons for the failure of software development projects. A possible explanation for this failure is that requirements management tends to overvalue the technology side of requirements. However, the requirements management depends on other important issues beyond technology which are sometimes neglected. Good requirements are only assured by the right balance of three dimensions: people, organization and technology. Through the lens of each of these three dimensions, this paper reviews significant literature, identifying some of the key issues and concerns about the management of software requirements, particularly the software requirements specification. Major software quality attributes, like clearness, completeness, correctness, understandability, verifiability or validity, consistency and feasibility, are used to analyse several important facets of software requirements management. Implications for future research are discussed.

Software development project success and failure from the supplier's perspective: A systematic literature review

In this paper, we consider software development project success and failure from the supplier's perspective. First we clarified concepts in order to be able to exclude review articles on in-house projects, continuous services, the customer's perspective, and software product development, with the aim of providing valid results for supplier firms. We divided success criteria into project success and project management (PM) success, and, in seven articles, identified three success criteria from the supplier's perspective: customer satisfaction, short-term business benefits, and long-term business benefits. In contrast, no definition of software development project failure was found. Articles were found in seven different journals, showing that knowledge on software development project success from the supplier's perspective is fragmented. This impedes the growth of knowledge on this topic.

COMMUNICATION, TEAM PERFORMANCE, AND THE INDIVIDUAL: BRIDGING TECHNICAL DEPENDENCIES.

Failure of software development projects is common. Often one of the major factors is poor communication between individuals on the development team. However, improving coordination requires more than just increasing communication. The Socio-Technical Congruence (STC) metric helps make sense out of the complicated highly-dynamic coordination requirements between team members by analyzing the relationship between communication and task dependencies obtained from work artifacts (Cataldo, Herbsleb, & Carley, 2008). Previous research computed STC from data contained in software repositories and found that high values of STC in a commercial software engineering setting led to higher team performance (Cataldo, Wagstrom, Herbsleb, & Carley, 2006), but did not differentiate cleanly between the effects of communication aligned with coordination requirements and that which was not. In this work we extend STC, creating an individual metric and two sub-measures that distinguish between communication that is aligned w...

CHUNK: An Agile Approach to the Software Development Life Cycle

ABSTRACT This article introduces a methodology for developing applications incorporating components of Agile development methods with the traditional software development life cycle (SDLC), a.k.a. the “waterfall” model of software development. We look at the causes for failure of software development projects and propose steps in the development process to address many of the root causes of these failures (it would be implausible to state that any development methodology could eliminate the risk of failure). We also provide a critical review of Agile principles and the traditional SDLC. The steps of the new methodology are then described with rationalization for their necessity.

Software developer perceptions about software project failure: a case study

Software development project failures have become commonplace. With almost daily frequency these failures are reported in newspapers, journal articles, or popular books. These failures are defined in terms of cost and schedule over-runs, project cancellations, and lost opportunities for the organizations that embark on the difficult journey of software development. Rarely do these accounts include perspectives from the software developers that worked on these projects. This case study provides an in-depth look at software development project failure through the eyes of the software developers. The researcher used structured interviews, project documentation reviews, and survey instruments to gather a rich description of a software development project failure. The results of the study identify a large gap between how a team of software developers defined project success and the popular definition of project success . This study also revealed that a team of software developers maintained a high-level of job satisfaction despite their failure to meet schedule and cost goals of the organization.

In the 25 years since The Mythical Man-Month what have we learned about project management?

This paper discusses Brooks’ The Mythical Man-Month, a landmark work in the software project management field, and compares the software project management advice given there with practices employed some 25 years later. To find out the state of today's practice 20 experienced software developers were interviewed regarding their impressions of factors leading to success or failure of software development projects. Their observations are compared with the points raised by Brooks in his seminal work.