No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
What factors lead to software project failure?
Abstract
It has been suggested that there is more than one reason for a software development project to fail. However, most of the literature that discusses project failure tends to be rather general, supplying us with lists of risk and failure factors, and focusing on the negative business effects of the failure. Very little research has attempted an in-depth investigation of a number of failed projects to identify exactly what are the factors behind the failure. In this research we analyze data from 70 failed projects. This data provides us with practitionerspsila perspectives on 57 development and management factors for projects they considered were failures. Our results show that all projects we investigated suffered from numerous failure factors. For a single project the number of such factors ranges from 5 to 47. While there does not appear to be any overarching set of failure factors we discovered that all of the projects suffered from poor project management. Most projects additionally suffered from organizational factors outside the project managerpsilas control. We conclude with suggestions for minimizing the four most common failure factors.
... Important research spanning more than four decades on the study of IT project management and failure is available in the literature (Ackermann and Alexander, 2016;Baker et al., 1983;Brown, 2001;Cerpa and Verner, 2009;Charette, 2005;Chua, 2009;Cole, 1995;Eden and Ackermann, 1992;El-Emam and Koru, 2008;Ewusi-Mensah, 2003;Fowler and Horan, 2007;Glass, 1998;Hughes et al., 2016a,b;Jones, 1995;Kappelman et al., 2006;Keider, 1984;Keil et al., 1998;Kerzner, 2014;McManus and Wood-Harper, 2008;Meier, 2008;Morris and Hough, 1987;Pinto and Mantel, 1990;Pinto and Slevin, 1987;Schmidt, 2022Schmidt, , 2023bSchmidt et al., 2001;Standish, 2014;Verner et al., 2008;Williams et al., 2001;Yardley, 2002;Yeo, 2002). This literature is the basis for developing root cause hypotheses, and for the comprehensiveness of rival explanations considered. ...
... Research spanning more than fourty years has identified and reconfirmed a limited number of IT project failure factors and causes (Baker et al., 1983;Brown, 2001;Cerpa and Verner, 2009;Charette, 2005;Chua, 2009;Cole, 1995;Dwivedi, 2013;El-Emam and Koru, 2008;Ewusi-Mensah, 2003;Fowler and Horan, 2007;Glass, 1998;Jones, 1995;Kappelman et al., 2006;Keider, 1984;Keil et al., 1998;Kerzner, 2014;McManus and Wood-Harper, 2008;Meier, 2008;Morris and Hough, 1987;Pinto and Slevin, 1987;Schmidt, 2023b;Schmidt et al., 2001;Standish, 2014;Verner et al., 2008;Yardley, 2002;Yeo, 2002). The failure factors are: ...
... In this section, we evaluate the hypothesis that unclear, changing, or unrealistic objectives were contributing causes of the termination of the POLSAG project (Baker et al., 1983;Brown, 2001;Charette, 2005;Chua, 2009;Cole, 1995;El-Emam and Koru, 2008;Ewusi-Mensah, 2003;Glass, 1998;Kappelman et al., 2006;Keider, 1984;Keil et al., 1998;Kerzner, 2014;McManus and Wood-Harper, 2008;Morris and Hough, 1987;Pinto and Slevin, 1987;Schmidt, 2023b;Schmidt et al., 2001;Standish, 2014;Verner et al., 2008;Yardley, 2002;Yeo, 2002). ...
Information technology (IT) projects often fail. Postmortem analysis is not general practice in IT project management. This is a missed opportunity for IT project management because postmortem analysis is a proven source of practice improvements and preventive actions in other domains. In this paper, the root causes of failure of a major IT project are identified by postmortem analysis, a well-established method for investigating accidents and failure ex post facto to improve practice and performance. The root causes of failure identified are: a) inadequate planning, b) novelty of a technology to the organisation, and c) inappropriate software development method and process. The postmortem offers insights into risks and challenges that IT projects still face today. Significantly, the postmortem analysis shows how a different approach to project planning could have prevented the failure and termination of the project. This paper also demonstrates how systematic IT project postmortem analysis can be conducted based on leading theory of process tracing and causal modelling in combination with the literature on IT project failure. The demonstration of this approach to IT project postmortems is new and original.
... It should be noted that studies [33][34][35][36][37][38][39][40][41] do not contain any categorization of the factors. For the "Communication" factor, which has been used as an example, the factors "Customer communication" [35] were categorized as Team and People factors because they refer to people who play an important role in the project development, such as the clients and users. ...
... Factor Id. Name of the factor Primary studies Definition of the factor 4 MOTIVATION of the people participating in the project [10,22,25,27,28,35,37,38,41] "If the staff is not rewarded for working long hours, their motivation decreases resulting in increasing risk for failures" [27]. "An aggressive schedule that affected both team motivation and the development process" [37]. ...
... Name of the factor Primary studies Definition of the factor 4 MOTIVATION of the people participating in the project [10,22,25,27,28,35,37,38,41] "If the staff is not rewarded for working long hours, their motivation decreases resulting in increasing risk for failures" [27]. "An aggressive schedule that affected both team motivation and the development process" [37]. ...
Most software development organizations are project based. However, statistics show that the failure rate of projects is very high. Different authors have identified factors (critical success factors) that can influence the success or failure of software projects, and that must be considered when carrying out a software project. This study is part of a research aimed at defining a framework that allows software development companies to assess the extent of the impact of critical success factors on their projects and increase the probability of project success. To achieve this goal, the first step was to identify the factors influencing software project success as reported in recent literature, as presented in this paper. A systematic literature review was conducted to obtain the list of factors that can influence the success of software projects. The list of 50 critical success factors resulting from this literature review can be used as a guide of critical aspects to be taken into consideration by the project manager when managing a project. Several gaps were identified through the literature review, such as the lack of indicators to measure the level of impact of each factor and the absence of descriptions for these factors.
... 4) They are peer-reviewed or cited by authors of peer-reviewed authors on the topic. The selected literature for the analysis of the identification of failure factors consists of 24 papers, 21 IT specific papers, marked with "✓" in Table 1: (Kerzner, 2014;Standish, 2014;Chua, 2009;Cerpa and Verner, 2009;El-Emam and Koru, 2008;Verner et al., 2008;McManus and Wood-Harper, 2008;Meier, 2008;Fowler and Horan, 2007;Kappelman et al., 2006;Charette, 2005;Ewusi-Mensah, 2003;Yeo, 2002;Yardley, 2002;Brown, 2001;Schmidt et al., 2001;Glass, 1998;Keil et al., 1998;Jones, 1995;Cole, 1995;Keider, 1984), and three texts on project management (Morris and Hough, 1987;Pinto and Slevin, 1987;Pinto and Mantel, 1990;Baker et al., 1983). The papers (Pinto and Slevin, 1987;Pinto and Mantel, 1990) have been reviewed in combination as one paper because failure is treated in both papers. ...
... Software that fails to meet the real business needs. (Verner et al., 2008). Lack of documented requirements and/or success criteria. ...
... Leadership, upper management support. (Verner et al., 2008). Over-zealous advocacy (Meier, 2008). ...
This paper shows how causes and mechanisms behind past information technology (IT) project failures can be used for systematic risk mitigation in new IT projects. This is significant because successful IT projects are needed to realise the benefit potential of digitalisation, whereas failed IT projects overspend resources and underdeliver benefits. In this paper we a) identify factors and causes that lead to IT project failure, b) analyse the consistency over time of the identified factors and causes, c) expose mechanisms of failure by analysing failure factors, causes, and common features of IT projects, and d) show how this knowledge can be used in IT project risk evaluations. The paper uses hermeneutic literature review, statistical analysis of failure factors in the literature, content analysis of the reviewed literature, and process tracing.
... Moreover, TP is a psychological condition that arises whenever there is insufficient time to complete a task (Speier-Pero, 2019). Studies have shown that TP can negatively impact the quality of software development, leading to issues such as bugs (Kuutila et al., 2017), burnout (Kuutila et al., 2020;Verner et al., 2008), and poor performance (Kuutila et al., 2020). For instance, a report by the Consortium for Information and Software Quality highlighted the staggering economic impact of 2.08 trillion USD attributed to low-quality software in the US during 2020, underscoring the significance of addressing TP and its associated software failures. ...
... These factors are interconnected. TP can also increase the burden on software developers (Maruping et al. 2015), leading to burnout and further contributing to software failure (Verner et al., 2008). Furthermore, a lack of communication (Shah et al., 2014) and a lack of user involvement (Zahid et al., 2018) can also arise when there is a lack of time, leading to software failure. ...
... 3. Inappropriate skills or unskilled workers are the main factors that affect software projects (Gupta et al., 2019;Guillaume-Joseph and Wasek, 2015;Al-Ahmad et al., 2009). Since they have no prior experience dealing with tight deadlines, the results can be unsatisfactory (Verner et al., 2008). As a result, it is not about the number of employees to appoint to a job but rather about the employees' software development expertise and skills. ...
The success of software development projects is often hindered by time pressure (TP), leading to decreased productivity, compromised quality, and increased risk of failure. To address this issue, it is crucial to understand the key factors contributing to TP in software development projects. In line with the study's objectives, the review methodology followed the Kitchenham and Charters criteria, and a search strategy encompassed four primary digital databases, namely IEEE, ACM Digital Library, Science Direct, and Springers, resulting in 4,500 relevant sources. After applying inclusion and exclusion criteria, a total of 128 papers were selected for analysis. This paper offers a comprehensive overview of the factors contributing to TP in software development. This study synthesizes the findings from multiple studies to guide practitioners in improving their project management approaches and highlights the significance of enhancing various aspects of the development process. The findings highlight the importance of improving project management, estimation techniques, knowledge, and skills to effectively manage TP. Additionally, managing requirements volatility, setting clear goals and objectives, and reducing distractions and interruptions emerge as crucial strategies for mitigating TP and enhancing project success. Furthermore, selecting software developers based on their personality traits is recommended to foster a work environment conducive to reduced TP and improved software development outcomes. By understanding and addressing these factors, software development teams can alleviate TP and increase the likelihood of successful software products. Implementing these recommendations can contribute to reduced TP, improved project outcomes, and enhanced overall success in software development.
... Therefore, to achieve a successful outcome, the project manager must identify, assess, prioritize, and manage all the major risks [46]. Verner and colleagues [47] analyzed 70 failed software projects, and identified 57 essential factors that can affect software project failure, where the major reason was poor risk assessment. ...
... We consider them insignificant as they were highlighted by less than 5% of the literature. These factors include lack of resource [16] , technology illiteracy [46], unrewarded human resources [47] and trust among the team members [35]. These low contributing factors might have some impact on the software project failure, but strong empirical evidence will be required before considering them significant. ...
... Methodology Algorithm Automation Limitation [47] Empirical study X X The survey data was self-reported and needed more empirical study implication to investigate the issue. [67] Empirical study X X The survey data was self-reported to only Jordanian software Firms. ...
Software Project management (SPM) is a vital concern for software industries to follow best practices for successful project completion. Despite the rich availability of SPM literature, every year around 70% of projects cannot gain successful completion worldwide. Software failure impacts the software industry in terms of reduced revenue, development teams with stress and reduced motivation, general population in terms of jobs reduction and the whole country in terms of reduced exports. This study explores the literature on SPM with the objectives of identifying major contributing factors in software failure. The current study, identified 2171 research studies out of which 68 have been thoroughly analyzed, after applying guidelines of inclusion and exclusion. The analysis of 68 selected research papers highlighted 13 influencing factors toward software project failure, with four major, five significant and four insignificant factors, where the major factors are incorrect cost and time estimation. The analysis included 35.29% empirical studies, 47.06% general literature review and 17.65% case studies. The analysis also reflected that 86.77% papers only examined the state of the art while only 13.23% of research studies discussed some algorithm to reduce failure. Further, the analysis found that only 4.41%, studies developed some automation tool for reducing some failure factor while 95.59% of studies did not developed any tool. The findings of this study provide future insights for SPM research as well as the software industry to increase the ratio of successful projects.
... Por otra parte, los factores tecnológicos son variables que se utilizan para evaluar las alternativas disponibles con respecto a las capacidades tecnológicas. Verner et al. [5], describen el fracaso de un proyecto de software como una combinación de decisiones técnicas, de gestión de proyectos, y de negocio, donde cada dimensión interactúa con las demás de forma compleja. Indican que a pesar de que existen muchas pautas para un desarrollo exitoso de software, se realizan muy pocos post-mortems (proceso que se utiliza para identificar las causas del fracaso de un proyecto y de cómo prevenirlas en el futuro) de proyectos, por lo que se obtiene poca comprensión de los resultados de proyectos anteriores. ...
... Otro estudio más reciente [6], realiza una revisión bastante exhaustiva de la literatura sobre las causas de los fracasos de los proyectos de TI (Tecnologías de la Información), con el propósito de enumerar las causas más frecuentes y elaborar un marco de trabajo, a partir de estas, para ayudar a ejecutar proyectos de TI conéxito. Sobre un total de 32 documentos comprendidos entre los años 1992 y 2014, se obtiene un listado de 11 causas más frecuentes de por qué los proyectos fracasan, resultados que coinciden con los hallazgos en [5]. ...
... 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]. ...
Many researchers have attempted to identify the factors behind software project failures and their solutions from various perspectives. However, systematic and integrated process definitions of failure as process models for success are lacking. This study aims to build a process definition for software project failure as an anti-pattern by identifying the main phases and their relationships in terms of team behavior. We researched software engineering literature and case studies to gather information about critical incidents and repeating behaviors of teams in failed projects into a novel dataset. Grounded theory was employed to build a theoretical
foundation
for failure phase definitions from the collected data. The design structure matrix and Bayesian belief network were used for the quantitative assessment of the transitions between phases. The results revealed that common behavioral patterns occurred in approximately 89 percent of the case studies, supporting the decision to consider software project failure as a process. The proposed failure process definition has a simple structure that uses everyday concepts for phase names and reveals the critical behaviors leading a software project to failure Thus, it provides critical insights for software professionals, non-technical stakeholders, and managers to evaluate the progress of their projects and design strategies to avoid failure.
... This is because stakeholder perception and involvement is key in the measure of project success as noted by Doherty, Ashurst, and Peppard (2012) and by DeLone and McLean (2003) in Figure 2.1. Therefore the bene ts realisation process should be stakeholder-led and Yeo (2002) and Verner, Sampson, and Cerpa (2008) suggested that organisational factors could all result in failure; ...
... The project moving out of tolerances such as time, funding and resources automatically deems the project as a failure in the eyes of some people, usually senior managers who are not involved beyond passive interest in a project (L. Hughes, Rana, and Dwivedi 2019; Andresen et al. 2002;Doherty, Ashurst, and Peppard 2012;Verner, Sampson, and Cerpa 2008). Sauer (1993) instead suggested that the only basis to determine a project as having failed should be where there is a technical or operational breakdown at an organisational or project level. ...
The aim of this project was to produce two virtual machines using only FLOSS software which could hypothetically be used by an NHS Trust, where one machine was set up for use by standard clerical staff members and the other for clinical staff who require more specialised software such as being able to view scans and log patient records. Research was also carried out into previous projects where FLOSS software was implemented, however the literature shows that these are not often successful due to factors such as too many stakeholders being involved in a project which tends to lead to over- runs of time and budget. Research into the usability of FLOSS also revealed that users often think of FLOSS software as being ’ugly and outdated’ because FLOSS projects are often too small to have HCI developers involved.
Test users were selected to assess the usability of the virtual machines using SUS (system usability scale) questionnaires and being asked a set of qualitative questions. Comparing the overall mean SUS score of each virtual machine showed that the clinical VM was the most popular by a difference of 5.5, however both scores are below 68 (the average for SUS scores) which indicates that they have UX issues. A paired T-test was carried out which revealed a p-value of 0.7942 and a subsequent post-hoc test using a two-way ANOVA (without replication) also revealed a p-value of 0.8005 both of which reveal that was there no statistically significant difference between the two testing groups.
Thematic analysis of the interview questions also revealed that all users had apprehensions about the system and made repeated comparisons to questions. Comparison to the project objectives showed that some were only partially achieved because of difficulties with communication and COVID-19 adjustments.
... Moreover, the success rate of big data projects remains alarmingly low, with reports suggesting that between 80 and 87 percent fail to produce sustainable solutions (Escobar et al. 2021;Hotz 2024). While data quality is a significant factor (Ataei and Staegemann 2023), many other reasons contribute to project failures, including poor project management, organisational issues, and factors outside the project manager's control (Verner et al. 2008). IT project failures are often linked to complex combinations of innovation, technology, human factors, and environmental and management challenges. ...
Big data projects have become increasingly important in today's data-driven world, significantly influencing sectors such as healthcare, finance, and retail. However, these projects often face high failure rates, with estimates suggesting that between 80% and 87% fail to produce sustainable solutions. This systematic literature review aims to investigate the factors contributing to the failure of big data projects. We conducted a comprehensive analysis of 26 academic studies and 3 industry reports, covering literature from 2010 to 2024. Our review reveals five primary themes contributing to big data project failures: technical challenges, organisational factors, ethical and legal considerations, financial constraints, and methodological challenges. Technical issues, particularly in data quality and integration, emerged as the most prevalent, closely followed by organisational factors such as skills shortages and cultural resistance. Ethical considerations and financial constraints also play significant roles, while methodological challenges, though less frequently mentioned, highlight important areas for future research. The review underscores that big data project failures rarely stem from a single factor but rather from the interplay of multiple challenges. This insight calls for a holistic approach to big data initiatives, integrating technical solutions with organisational change management, ethical considerations, and strategic alignment. Our findings provide insights for researchers, practitioners, and policymakers, emphasising the need for interdisciplinary approaches and industry-specific frameworks to enhance the success rate of big data projects.
... As several qualitative aspects can rarely be discovered, cost estimation in software development projects is not precise. Overestimation or estimation for software cost can be critical to maintaining the competitiveness of a company [2]. Therefore, accurate estimation of required cost is a big challenge for project managers to execute and fulfill the projects within due time and cost. ...
Different project management processes have been used in software engineering to support managers in keeping project costs manageable. One of the essential processes in software engineering is to accurately and reliably estimate the required effort and cost to complete the projects. The domain of software cost estimation has witnessed a prominent surge in research activities in recent years and being an evolving process, it keeps opening new avenues, each with advantages and disadvantages, making it important to work out better options. This research aims to identify the factors that influence the software effort estimation using the constructive cost model (COCOMO), and artificial neural networks (ANN) model by introducing a novel cost estimation approach, COCOMO-ANN (CANN), utilizing a partially connected neural network (PCNN) with inputs derived from calibrated values of the COCOMO model. A publicly available dataset (COCOMONASA 2), various combinations of activation functions, and layer densities have been systematically explored, employing multiple evaluation metrics such as MAE, MRE, and MMRE. In the PCNN model, the ReLU activation function and a 1000-dense layer have demonstrated better performance. While layer density generally correlates with better outcomes, this correlation is not universally applicable for all activation functions and outcomes vary across different combinations. The use of the relationships between 26 key parameters of COCOMO in PCNN produced better results than FCNN by 0.59%, achieving an MRE of 6.55 and an MMRE of 7.04. The results indicated that the CANN model (COCOMO & ANN) presented better results than existing models.
... According to a study [4] analyzing 70 software projects that failed, the main cause of failure was incorrect decision-making during the software project lifecycle. The researchers identified several factors that contributed to flawed decision-making, such as insufficient information about requirements for delivery decisions, improper requirement-gathering methods, lack of well-defined project scope, and incorrect delivery plan, which disrupted the development process. ...
... Poor planning and scheduling main failure factors, quality and spirit of team member, user involvement, good planning and estimation, good leadership and strong skill are highly motivated the successful project environment [52]. Verner is a renowned researcher of software industry, in his one article paper there are 57 failure factors investigated, but commonly whose appearance makes project failures those are delivery date issues, underestimated, staff were not rewarded, inadequate [53]. According to his survey on Sydney software house complete and consistent requirements are necessitates of successful projects that would provide a better chance of developing good requirements in developing industry [31] along with effectively handling of that requirement. ...
Recent literatures and research have been shown that successful software projects are based on many factors. These factors make a project successful or unsuccessful depending upon the nature of the environment where it was built. Efficacious software projects are those who completed on time, within scope and budget, meeting all requirements, management and customer supports and many more. However, different countries have a distinct perspective regarding factors evaluation that leads to a successful project. The research found that there have been limited studies of the Pakistani software environment consequently; this research study was a survey study concentrate on the success factors of Pakistan's software projects using quantitative research analysis approach. 40 software houses were targeted, and data has been collected through questionnaires and interviews from related personnel’s of less experienced and most experienced software houses, in the Karachi, Lahore, Quetta, and Peshawar which has clearly shown the main waves of success aspects of software projects and management. This research also provides a comprehensive look at software projects through the eyes of the Pakistani's software personals as well as the relationship and outcomes of practices with the help of literature study. The importance of this research is to cover both theoretical and practical dimensions of the factor’s association and hypothetical investigations through different statistical methods such as, Chi-Square, regression analysis and One-Way Anova. For these techniques, a statistical software environment is using the R language which is the first time in the research of Pakistani environment.
... Based on the results of this study, the authors have identified the knowledge management in effort estimation as a relevant aspect to achieve an improvement in the use and application of techniques, tools, and datasets and thus carry out a more efficient and effective effort estimation process. Inaccurate estimates have been identified as a software projects failure factor [58], [59] and the knowledge management in effort estimation can be part of the solution to improve the literacy in this field. ...
... Developers and their teams also need to balance personal productivity, project constraints, organizational context, and business impact alongside pushing the boundaries on what code can do in the world. Against this complexity, some estimates of the overall success rates of software projects claim that the majority of software projects deliver late, deliver out of scope of planned budgets, and fail to drive business impact [1]. ...
Software research has reliably documented a connection between how satisfied developers feel at work and their overall productivity. However, these explorations have not typically integrated known social science mechanisms around human wellbeing and achievement to describe
why
this connection exists, and what the most promising levers are for leaders and teams that wish to impact it. In addition, there are strong criticisms of using highly volatile and individual affective measures (e.g., daily happiness) as a sole signal for the quality of learning and problem-solving. In this study, we present a research-based framework for measuring successful environments on software teams for long-term and sustainable sociocognitive problem-solving, named
Developer Thriving.
Across 1282 full-time developers in 12+ industries, we tested the factors of Developer Thriving and found it predictive of developers’ self-reported productivity.
... Yet, we report the negative effects of time pressure on confirmation bias in software testing. Several other studies also report that time pressure deteriorates software quality and is a source of errors by affecting testers performance and development [15], [61], [62], [63], [64], [65]. ...
bold xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Background
: Software testers manifest confirmation bias (the cognitive tendency) when they design relatively more specification consistent test cases than specification inconsistent test cases. Time pressure may influence confirmation bias of testers per the research in the psychology discipline.
Objective
: We examine the manifestation of confirmation bias of software testers while designing functional test cases, and the effect of time pressure on confirmation bias in the same context.
Method
: We executed one internal and two external experimental replications concerning the original experimentation in Oulu. We analyse individual replications and meta-analyse our family of experiments (the original and replications) for joint results on the phenomena. Results: Our findings indicate a significant manifestation of confirmation bias by software testers during the designing of functional test cases. Time pressure significantly promoted confirmation bias among testers per the joint results of the family. The different experimental sites affected the results; however, we did not detect any effects of site-specific variables.
Conclusion
: Software testers should develop an outside-of-the-box thinking attitude to counter the manifestation of confirmation bias. Time pressure can be manoeuvred by centring manual suites on the designing and consequently the execution of inconsistent test cases, while automated testing focuses on consistent ones.
... Furthermore, this paper is the first to show and measure the literature's consistency in identifying and confirming the managerially controllable factors and causes associated with IT project failure spanning more than 30 years of research. marked with "X" in Table 1: (Kerzner, 2014;Standish, 2014;Chua, 2009;Cerpa and Verner, 2009;El-Emam and Koru, 2008;Verner et al., 2008;McManus and Wood-Harper, 2008;Meier, 2008;Fowler and Horan, 2007;Kappelman et al., 2006;Charette, 2005;Yeo, 2002;Yardley, 2002;Brown, 2001;Schmidt et al., 2001;Glass, 1998;Keil et al., 1998;Cole, 1995;Keider, 1984), and three texts on project management Pinto and Slevin, 1987;Pinto and Mantel, 1990;. The papers (Pinto and Slevin, 1987;Pinto and Mantel, 1990) have been reviewed in combination as one paper because failure is treated in both papers. ...
Please cite this article as: Schmidt, J., Mitigating risk of failure in information technology projects: Causes and mechanisms, Project Leadership and Society (2023), doi: https://doi. Abstract This paper shows how causes and mechanisms behind past information technology (IT) project failures can be used for systematic risk mitigation in new IT projects. This is significant because successful IT projects are needed to realise the benefit potential of digitalisation, whereas failed IT projects overspend resources and underdeliver benefits. In this paper we a) identify factors and causes that lead to IT project failure, b) analyse the consistency over time of the identified factors and causes, c) expose mechanisms of failure by analysing failure factors, causes, and common features of IT projects, and d) show how this knowledge can be used in IT project risk evaluations. The paper uses hermeneutic literature review, statistical analysis of failure factors in the literature, content analysis of the reviewed literature, and process tracing. Abstract This paper shows how causes and mechanisms behind past information technology (IT) project failures can be used for systematic risk mitigation in new IT projects. This is significant because successful IT projects are needed to realise the benefit potential of digitalisation, whereas failed IT projects overspend resources and underdeliver benefits. In this paper we a) identify factors and causes that lead to IT project failure, b) analyse the consistency over time of the identified factors and causes, c) expose mechanisms of failure by analysing failure factors, causes, and common features of IT projects, and d) show how this knowledge can be used in IT project risk evaluations. The paper uses hermeneutic literature review, statistical analysis of failure factors in the literature, content analysis of the reviewed literature, and process tracing.
... Cel al robusteței în construcție (în esență însemnând capacitatea de a fi făcut cu programatori și manageri de proiect cu calificare medie) este mult mai puțin gestionat în practică. Acest lucru poate fi constata chiar din concluziile studiilor privind cauzele eșecurilor proiectelor de digitizare/IT: lipsa abilităților manageriale sau lipsa abilităților tehnice apar între cele mai frecvente cauze (Baccarini, Salm și Love, 2004), (Verner, Sampson și Cerpa, 2008), (Sudhakar, 2016). ...
... These costs are known as Technical Debt (TD) and are a severe problem in software development projects, as exemplified in Figure 1. Numerous studies have substantiated these trends in several years of research [2,8,13], highlighting the detrimental impact of such circumstances on quality assurance. Figure 1: In a Short Run, more features of software systems can emerge and lead to a better turnover. ...
... These costs are known as Technical Debt (TD) and are a severe problem in software development projects, as exemplified in Figure 1. Numerous studies have substantiated these trends in several years of research [2,8,13], highlighting the detrimental impact of such circumstances on quality assurance. Figure 1: In a Short Run, more features of software systems can emerge and lead to a better turnover. ...
Technical debt is often the result of Short Run decisions made during code development, which can lead to long-term maintenance costs and risks. Hence, evaluating the progression of a project and understanding related code quality aspects is essential.
Fortunately, the prioritization process for addressing technical debt can be expedited with code analysis tools like the established SonarQube. Unfortunately, we experienced some limitations with this tool and have had some requirements from the industry that were not yet addressed.
Through this experience report and the analysis of scientific papers, this work contributes: (1) a reassessment of technical debt within the industry, (2) considers the benefits of employing SonarQube as well as its limitations when evaluating and prioritizing technical debt, (3) introduces a novel tool named SoHist which addresses these limitations and offers additional features for the assessment and prioritization of technical debt, and (4) exemplifies the usage of this tool in two industrial settings in the ITEA3 SmartDelta project.
... Cel al robusteței în construcție (în esență însemnând capacitatea de a fi făcut cu programatori și manageri de proiect cu calificare medie) este mult mai puțin gestionat în practică. Acest lucru poate fi constata chiar din concluziile studiilor privind cauzele eșecurilor proiectelor de digitizare/IT: lipsa abilităților manageriale sau lipsa abilităților tehnice apar între cele mai frecvente cauze (Baccarini, Salm și Love, 2004), (Verner, Sampson și Cerpa, 2008), (Sudhakar, 2016). ...
STRATEGIA DE DEZVOLTARE DURABILĂ PENTRU CONSERVAREA STURIONILOR SĂLBATICI DIN DUNĂREA DE JOS ÎN CONTEXTUL SCHIMBĂRILOR CLIMATICE ȘI PACTULUI VERDE EUROPEAN
György Deák*1,2) și Puiu-Lucian Georgescu1,3)
1) Consiliul Consultativ pentru Dezvoltare Durabilă al României
2) Institutul Național de Cercetare-Dezvoltare pentru Protecția Mediului
3) Infrastructura de cercetare REXDAN, Universitatea „Dunărea de Jos” din Galați
Summary
Aquatic ecosystems face habitat changes caused by the amplification of the climate change phenomenon. The adaptive capacity of river ecosystems and associated biota is reduced, reason for which concrete measures are needed. The European Green Deal represents the main signal related to increasingly intense concerns regarding the development of European policies tackling climate and environmental-related challenges. The paper aims to substantiate the application of sustainable solutions for the conservation of sturgeon species in the Lower Danube basin. This is based on the information volume owned by the National Institute for Research and Development in Environment Protection of Bucharest, as a result of the monitoring activity of these species undertaken between 2011 - 2018. Both the distribution maps of the sturgeon species and the numerical evolution of the specimens captured for monitoring between 2011-2018 are presented, along with the distribution of the captures by species. At the same time, the impact of climate change on sturgeon populations was analysed and quantified, based on the assessment of the main climatic parameters' variability in the area of interest, with the aim of substantiating the conservation measures proposed for the future. Finally, the measures for improving the state of conservation of sturgeon populations are presented, taking as well into account the need to correlate the national and community regulations.
http://romania-durabila.gov.ro/wp-content/uploads/2023/04/Publicatia-CCDD-04.04.2023_electronic.pdf
... For this purpose, the restrictions on quality and performance, as well as the operational characteristics of a software, are studied from the perspective of the employees working in the organization. June Verner [10] investigated the factors that lead towards project failure. He analyzed the data of 70 failed projects and found 57 factors contributing towards project failure; unrealistic goals, unclear system and user requirements, poorly structured requirement specification document, unrealistic scheduling and cost estimates, and improper risk assessment were a few. ...
Requirement engineering is a major phase of software development process. A project's success mainly depends on an efficient and effective requirement engineering process. Practices have been defined to ensure successful requirement engineering of software projects. Yet the professionals face numerous issues during this phase. This paper explores the software requirement engineering practices from in the software industry of Pakistan. It highlights the common problems faced by the software professionals, as well as commonly deployed solutions and practices.
... Poor planning and latent faults in delivered software continue to be at the root of many software development failures. 6 All 70 failed software projects analysed by Verna et al. [52] suffered from poor project management. Given the scale of the problem, any small improvements that our approach makes towards enabling better project management, could make a significant overall difference to the success of delivered software systems. ...
Background: Developers inevitably make human errors while coding. These errors can lead to faults in code, some of which may result in system failures. It is important to reduce the faults inserted by developers as well as fix any that slip through. Aim: To investigate the fault insertion and fault fixing activities of developers. We identify developers who insert and fix faults, ask whether code topic ‘experts’ insert fewer faults, and experts fix more faults and whether patterns of insertion and fixing change over time. Methods: We perform a time-based analysis of developer activity on twelve Apache projects using Latent Dirichlet Allocation (LDA), Network Analysis and Topic Modelling. We also build three models (using Petri-net, Markov Chain and Hawkes Processes) which describe and simulate developers’ bug-introduction and fixing behaviour. Results: We show that: the majority of the projects we analysed have developers who dominate in the insertion and fixing of faults; Faults are less likely to be inserted by developers with code topic expertise; Different projects have different patterns of fault inserting and fixing over time. Conclusions: We recommend that projects identify the code topic expertise of developers and use expertise information to inform the assignment of project work.
... The Standish Group report published in 2018 states that 48-65% of software projects were overbudgeted, whereas 48-56% were uncompleted (Johnson, 2020). The probable reasons may be unclear size estimation, unrealistic goals, or poor requirement understanding (Verner et al., 2018). It motivates the research community to examine the software rigorously for accurate size and effort estimation. ...
Early-stage software effort estimation (SEE) is crucial for successfully completing any software project since it helps in project bidding and efficient resource allocation. Most SEE models consider software size as a key metric for estimating effort. Consequently, software size becomes vital for early-stage SEE. Recently, use case points (UCP), derived from use case diagrams, gained popularity among the research community. The researchers used different classical and learning models for UCP prediction. Although learning models performed better than the classical models, it is difficult to conclude which learning model is superior. Ensembling is considered one probable solution when the individual models are not performing well. However, the ensemble models are not explored for UCP prediction till now. Motivated by this, the current work presents an ensemble-based framework for UCP prediction and investigates different ensemble models. We conducted an experimental analysis over two publicly available UCP estimation datasets by implementing different ensemble models. The results show that the ensemble models outperformed the base learners used in this work. Further, we compared the best performing ensemble learner with the existing UCP prediction models in the literature and found an improvement in UCP prediction performance.
... Finally, we ponder a possible connection between technostress and its resulting outcomes in software project failure. Compared with the literature on software project failure, the incident descriptions included similar themes related to the lack of skills, being overworked, and the use of new IT [e.g., 54,75,76]. With our results suggesting that technostress can affect, for example, the motivation, productivity, and work quality of developers, we suggest that the possible connection between technostress and failed software projects should be examined in future research. ...
Software development is a fast-growing market that is heavily tied to information technology (IT) use. Despite the high utilization of IT and high stress levels of software developers, research has largely neglected the effect of IT use on stress experienced by software developers. To address this gap in the research, we employ the concept of technostress. Prior technostress research has found many technostress-creating factors that cause severe negative consequences for both organizations and their employees. Despite these advancements, little is known about how technostress emerges in different organizational contexts and the underlying factors behind the technostress creators in these contexts. We conducted a qualitative study using the critical incident technique to uncover these factors and relevant technostress creators in the context of software development. We utilized a questionnaire with open-ended and closed-ended questions to collect descriptions of technostress experiences from 406 software developers. The current research identifies 21 influencing factors and 10 technostress creators to be relevant in software development, hence contributing to the technostress literature. We also contribute to software development research by explaining how the use of IT contributes to the stress experienced by software developers.
... Between 2002 and 2017 alone there have been more than 474 published articles in relation to success of OSS and COSS , yet the majority of COSS companies face a variety challenges to succeed (Ehls, 2017;Silic & Back, 2015;Ghapanchi and Aurum, 2012;Singh, Tan, and Mookerjee, 2011;Stewart & Maruping, 2006). COSS company challenges can be broadly categorized into technical and non-technical (project and business management decisions related) (Verner, Sampson, & Cerpa, 2008). Among the major causes of technical problems affecting the COSS companies is vulnerability. ...
Commercial Open Source Software (COSS) is a promising business model as it represents the middle ground between expensive proprietary software and free software. The unique nature of COSS companies has captured researchers' attention; hence several studies have been conducted to assess the success of a few prominent COSS companies. However, comprehensive empirical study consisting of various COSS companies of different size, type, and prominence is lacking. Hence, the aim of this study is to evaluate the success of diverse COSS companies by adapting the DeLone and McLean Updated Information Systems (IS) Success Model. The result indicates that COSS companies' success is significantly influenced by user satisfaction while the impact of software use on COSS company success is insignificant. Moreover, both software quality and product property positively impact user satisfaction as well as software use.
... For example, Kemerer [33] reported that the addition of the large numbers of productivity factors did little to improve the relationship between size and effort on a set of 15 homogeneous MIS-type projects. Banker et al. [12] also suggested that a relatively small number of critical factors might explain a large amount of the variation in productivity at a specific site. ...
Quite recently, enormous efforts have been made to improve the quality of software being produced. One of such ways has to do with the project planning process; another way is to effectively manage the people responsible for the overall success of the software being produced. Several software project plans exist depending on the type or projects and organization. The means of measuring how software is designed and how it conforms to that design is called software
quality. Some of the factors that are observed during software quality are scalability, product quality, completeness, correctness, and total absence of bugs.
These applied along with effective people management have been used in the past to prevent risk and enhance both delivery time and product quality. However, some gaps were identified in the earlier works done in this area and in project plans and people management designed for evaluating and controlling product quality prompting the development of modern techniques. Hence, this work tries
to investigate different type of project plans and people management techniques leaning on the gaps in research; it attempts to create a framework for better software project planning and alleviation with the aim of enhancing delivery time and product quality.
... The results indicated 36 factors that influence the software project success where time estimation was a vital factor. In another empirical study conducted by Verner et al. [22] for the identification of major factors that influence the project outcomes. They collected data of 235 projects from North Eastern USA and Australian IT companies, while their results showed that proper time estimation in the early stage of the software life cycle was an essential factor behind the success of software projects. ...
Determining factors influencing the success of software projects has been the emphasis of extensive research for more than 40 years. However, the majority of research in this domain has focused on developed countries, with little attention paid to underdeveloped and developing countries. The primary objective of this article was to assess the effect of critical elements on the success of software projects in underdeveloped countries (like Pakistan), because enterprise environmental factors and staff working habits, as well as their experience and expertise level, all have an effect on a project's success. For this purpose, data were collected from 339 senior developers and project managers working in Paki-stan Software Export Board (PSEB) registered software companies. Structural Equation Modelling (SEM) was used to analyze the constructs and to assess the relationship between factors affecting software success. The empirical results showed that improper planning, inadequate human resources, wrong estimation of time and cost significantly negatively impacted the success of software projects. This research has opened new doors to extend our work in the software community to ultimately succeed in software projects.
... To achieve this, Service APIs must be simple, easy to use, pragmatic, and designed with all major stakeholder groups in mind, including users, providers, aggregators, and architects (Anderson et al. 2020Anderson et al. 2020; this study). Unfortunately, many innovative and promising technical solutions have fallen short not because of an inability to solve problems (Verner et al. 2008), rather, they were difficult to use, built in isolation, and/ or designed without effective communication with stakeholders. Fortunately, projects such as Darwin Core (Wieczorek et al. 2012), the Integrated Publishing Toolkit (Robertson et al. 2014), and Megadetector (Microsoft 2021) provide the blueprint for successful community adoption of a technological solution within the biodiversity community. ...
Web APIs (Application Programming Interfaces) facilitate the exchange of resources (data) between two functionally independent entities across a common programmatic interface. In more general terms, Web APIs can connect almost anything to the world wide web. Unlike traditional software, APIs are not compiled, installed, or run. Instead, data are read (or consumed in API speak) through a web-based transaction, where a client makes a request and a server responds. Web APIs can be loosely grouped into two categories within the scope of biodiversity informatics, based on purpose. First, Product APIs deliver data products to end-users. Examples include the Global Biodiversity Information Facility (GBIF) and iNaturalist APIs. Designed and built to solve specific problems, web-based Service APIs are the second type and the focus of this presentation (referred to as Service APIs). Their primary function is to provide on-demand support to existing programmatic processes. Examples of this type include Elasticsearch Suggester API and geolocation, a service that delivers geographic locations from spatial input (latitude and longitude coordinates) (Pejic et al. 2010).
Many challenges lie ahead for biodiversity informatics and the sharing of global biodiversity data (e.g., Blair et al. 2020). Service-driven, standardized web-based Service APIs that adhere to best practices within the scope of biodiversity informatics can provide the transformational change needed to address many of these issues. This presentation will highlight several critical areas of interest in the biodiversity data community, describing how Service APIs can address each individually. The main topics include:
standardized vocabularies,
interoperability of heterogeneous data sources and
data quality assessment and remediation.
standardized vocabularies,
interoperability of heterogeneous data sources and
data quality assessment and remediation.
Fundamentally, the value of any innovative technical solution can be measured by the extent of community adoption. In the context of Service APIs, adoption takes two primary forms:
financial and temporal investment in the construction of clients that utilize Service APIs and
willingness of the community to integrate Service APIs into their own systems and workflows.
financial and temporal investment in the construction of clients that utilize Service APIs and
willingness of the community to integrate Service APIs into their own systems and workflows.
To achieve this, Service APIs must be simple, easy to use, pragmatic, and designed with all major stakeholder groups in mind, including users, providers, aggregators, and architects (Anderson et al. 2020Anderson et al. 2020; this study). Unfortunately, many innovative and promising technical solutions have fallen short not because of an inability to solve problems (Verner et al. 2008), rather, they were difficult to use, built in isolation, and/or designed without effective communication with stakeholders. Fortunately, projects such as Darwin Core (Wieczorek et al. 2012), the Integrated Publishing Toolkit (Robertson et al. 2014), and Megadetector (Microsoft 2021) provide the blueprint for successful community adoption of a technological solution within the biodiversity community. The final section of this presentation will examine the often overlooked non-technical aspects of this technical endeavor. Within this context, specifically how following these models can broaden community engagement and bridge the knowledge gap between the major stakeholders, resulting in the successful implementation of Service APIs.
... For example, Standish Group has disclosed the success rate of ISD projects annually since mid-1980s. They have reported that the success rate of IS projects has improved only by 5-10 % in 35 years, from the 20-25 % level during the 1980s and 1990s to the 30-35 % level during the 2010s (Hastie and Wojewoda 2015;MacManus and Wood-Harper 2007;Verner et al. 2008). Plan-driven methods dominated ISD work during the 1970s, 1980s and 1990s, and still have a strong position in ISD method development and standardization, for example, among the roughly 150 international standards developed under the ISO/IEC JTC1 SC7. ...
Several change-driven (agile) information systems development (ISD) methods have been launched during the recent years. In addition to agile ISD methods it is still possible to succeed also with plan-driven ISD methods. To facilitate ISD method selections that maximize the probability of ISD project success we crafted and evaluated an ISD method selection framework based on the idea of matching the properties of ISD methods and the characteristics of the business contexts where ISD methods are used. We conducted a systematic literature search to evaluate whether the proposed framework is also able to capture the findings of prior ISD method selection research and to guide future empirical research. From over 1000 potential articles we identified 42 articles that address ISD method selection. We discovered that the proposed framework was able to explain the findings of prior research.
... Hastie and Wojewoda 2015). Major attempts to solve this issue include the development of new ISD methods (ISDM), but regardless of this, the success rate of ISD projects has remained low (Hastie and Wojewoda 2015;MacManus and Wood-Harper 2007;Nelson 2007;Verner et al. 2008). All ISDMs appear to have limitations. ...
No single information systems development method (ISDM) suits to all information systems development (ISD) projects. Despite of this, ISDM selection has received limited attention in earlier research. This raises the question are ISDM selection decisions rare in practice as well, and if so, what are the reasons. We used the bounded rationality and functional stupidity theories to investigate ISDM selection decision-making behavior, and interviewed 31 IS professionals working in the borderline between IS clients and suppliers. We examined their experiences about ISDM selection within both types of organizations. We discovered that the ISDM selection decisions of ISD projects are seldom discussed, that the ISDM selection behavior of client and supplier organizations differ, and that the bounded rationality and functional stupidity theories are descriptively useful. In addition to these research contributions, our study shows that there are theoretical and practical reasons to develop better ISDM selection guidelines for ISD projects.
... Many companies attempt to get the product done using a systematic development process in the form of software project, where a diversity of models is employed, for example, waterfall, spiral, V, prototype, and iterative models, just to name a few. Unfortunately, some projects fail due to various factors [11][12][13][14]. The failure might be missing deadlines, not meeting the scope or requirements, or budgeting problem. ...
This research proposes a framework for social network scrum meeting that serves as an alternate means for work continuation under the COVID-19 pandemic. Conventional agile and scrum methods that require in-person meeting on daily basis, as well as scrum process become impractical under stringent ‘social lockdown’ mandates. To prevent any disruptive discontinuity, the proposed framework sets up an online meeting to replace the in-person stand-up meeting and scrum. Some supporting practices are also established to adjust both agile and scrum event flows that suit this online encounter. They are production development setup and social network meeting. The former offers industrial practices that are well entrenched and proven, while the latter has been used extensively in this digital age. The proposed method is tested with computer science student’s projects. Students are able to continue their meeting, discussion, and some outputs rather than being isolated with no fruitful outcome. The proposed method does establish some ground work to be explored for future software development environments that will suit to the imminent digital technological advancement.
... The research literature highlighted many reasons of challenging and failed software projects including lack of user involvement, incomplete requirements, changing requirements and specifications, unrealistic expectations, unclear objectives, lack of executive support, lack of planning, ineffective project management, technology incompetence, non-compliance to standards and quality issues [19,20]. These are the major issues that always hinder the progress of software projects. ...
The major emphasis of Software Engineering (SE) discipline is to pro-duce successful software systems. The success of software projects is estimated through quadruple measures including budget, cost, scope, and quality. To meet this aim of SE, several software development processes are presented in the literature. Such processes are categorized into two different methodologies which are known as traditional and agile software development methodologies. The issue with traditional software development methodologies is that they had not shown any remark-able progress towards the fundamental goal of SE. Consequently, software development organizations have started to adopt agile methodologies in the pursuit of successful software development. However, agile adoption does not come without challenges that vary from one context to another. Therefore, it is necessary to figure out the key factors of agile software development for successful project outcomes. In the wake of such need, this study investigated the Critical Success Factors (CSFs),categorized and prioritized them through a mixed-method approach. Such an approach was based on the detailed literature review and Delphi method accompanied with Multi-Criteria Decision Analysis (MCDA) technique. Twelve CSFs were revealed and categorized into people, organization and technical dimensions. Among these factors, ‘team capability’ was found the most significant factor where ‘culture’ was revealed as the least significant factor. The findings of the study would be promising for agile software development that is carried on in the local software industry.
... Various literatures referred are discussed that the project failure is mostly based on incompleteness, missing and Frequent changes in requirements. June Verner states that badly defined system requirements, user requirements and requirements specification are the major reason for software project failure [1]. NazishSaleem mentioned that There are several studies e.g., [2], [3], [4] which talk about the success of global software development which depends on the requirement change management, process improvement, developing relationship between client and vendor, software integration and use of tools in managing GSD projects [5]. ...
Missing requirements or incomplete requirements about the project is making delay in projects and that affect customer satisfaction. This problem is caused due to customer or requirement engineer. If it is due to customer then customer may not give it during requirement elicitation. If it is due to requirement engineer then requirement engineer may not collect it during elicitation. Or it is caused the inefficiency of both the parties. To avoid the missing requirements problem, this paper is expressing an intelligent approach.
... Verner et al. in [10] cite organizational culture as a factor that affects the success and causes project failure in software engineering projects. Organizational culture is elements within a workplace or an organization that influence people, purpose, work patterns, culture, leadership, and structure in an organization as defined in [6]. ...
Software is increasingly becoming central to human activities leading to rapid growth and evolution in the industry but with a compromise in quality. Contextual complexity in the small software companies brings in challenges that make quality hard to achieve. Total quality management provides an opportunity for adaptive approaches to ensure quality through the four pillars we stem out of the TQM theory. This study explores to assess the state of current quality practice in software development in small software companies to propose mechanisms that will address quality in terms of the units of analysis and related attributes by interviewing 12 practitioners in Gaborone Botswana whose findings show a low understanding and use of quality measures in practice.
... Traditional structured approaches in software product development and project management in software intensive industries have had to IT project failure [4] [5] [6] [7] [8] and software project failure [9] [10] with a number of examples from the public sector [11] [12] [13]. In addition, traditional software security has also witnessed research by academia on this topic [53]. ...
This research, undertaken in highly structured software-intensive organizations, outlines challenges associated to agile, lean and DevOps practices and principles adoption. The approach collected data via a series of thirty (30) interviews, with practitioners from the EMEA region (Czech Republic, Estonia, Italy, Georgia, Greece, The Netherlands, Saudi Arabia, South Africa, UAE, UK), working in nine (9) different industry domains and ten (10) different countries. A set of agile, lean and DevOps practices and principles, which organizations choose to include in their DevOps adoption journeys were identified. The most frequently adopted structured service management practices, contributing to DevOps practice adoption success, indicate that those with software development and operation roles in DevOps-oriented organizations benefit from existence of highly structured service management approaches such as ITIL.
... Our work advocates consideration of the holistic system within which the software-to-be will function, attending not only to the functional and nonfunctional properties of the software system but also to the indirect, longer-term effects that its use could cause including emergent behaviour, and the risks and uncertainties that this may engender. However, we are also aware that the discipline of software engineering already suffers from high costs and late delivery problems [44], and additional "whole systems" analysis could prove too costly and complex to be useful. In truth, this very problem stifles the use of techniques such as Soft Systems Methodology [12] or Critical Systems Thinking [22] in the software engineering domain. ...
Integrating novel software systems in our society, economy and environment can have far-reaching effects. As a result, software systems should be designed in such a way as to maintain or improve the sustainability of their intended socio-technical systems. However, a paradigm shift is required to raise awareness of software professionals on the potential sustainability effects of software systems. While Requirements Engineering is considered the key for driving this change, requirements engineers lack the knowledge, experience and methodological support for acting as facilitators for a broader discussion on sustainability effects. This paper presents a question-based framework for raising awareness of the potential effects of software systems on sustainability, as the first step towards enabling the required paradigm shift. An evaluation study of the framework was conducted with four groups of computer science students. The results of the study indicate that the framework is applicable to different types of systems and helps to facilitate discussions about the potential effects that software systems could have on sustainability.
... Traditional structured approaches in software product development and project management in software intensive industries have had to IT project failure [4] [5] [6] [7] [8] and software project failure [9] [10] with a number of examples from the public sector [11] [12] [13]. In addition, traditional software security has also witnessed research by academia on this topic [53]. ...
Our research focuses in software-intensive organizations and highlights the challenges that surface as a result of the transitioning process of highly-structured to DevOps practices and principles adoption. The approach collected data via a series of thirty (30) interviews, with practitioners from the EMEA region (Czech Republic, Estonia, Italy, Georgia, Greece, The Netherlands, Saudi Arabia, South Africa, UAE, UK), working in nine (9) different industry domains and ten (10) different countries. A set of agile, lean and DevOps practices and principles were identified, which organizations select as part of DevOps-oriented adoption. The most frequently adopted ITIL® service management practices, contributing to DevOps practice and principle adoption success, indicate that DevOps-oriented organizations benefit from the existence of change management, release and deployment management, service level management, incident management and service catalog management. We also uncover that the DevOps adoption leadership role is required in a DevOps team setting and that it should, initially, be an individual role.
... Traditional structured approaches in software product development and project management in software intensive industries have had to IT project failure [4] [5] [6] [7] [8] and software project failure [9] [10] with a number of examples from the public sector [11] [12] [13]. In addition, traditional software security has also witnessed research by academia on this topic [53]. ...
This research, undertaken in highly structured software-intensive organizations, outlines challenges associated to agile, lean and DevOps practices and principles adoption. The approach collected data via a series of thirty (30) interviews, with practitioners from EMEA region, working in nine (9) different industry domains and ten (10) different countries. A set of agile, lean and DevOps practices and principles, which organizations choose to include in their DevOps adoption journeys were identified. The most frequently adopted structured service management practices, contributing to DevOps practice adoption success, indicate that those with software development and operation roles in DevOps-oriented organizations benefit from existence of highly structured service management approaches such as ITIL ® .
The first decade of DevOps-orientation in software-intensive organizational environments is often characterized with an emerging set of skills that support DevOps practice adoption, targeting a cross-functional collaborative culture; with an aim of achieving a shift in mindset, skillset, and toolset. We investigate DevOps adoption constructs to facilitate development of a formative measurement model to support leadership throughout the DevOps transitional journey. The model and its constructs are designed and validated with a multi-method approach. Initially an exploratory study of a survey is conducted with 250 respondents 76% of whom possess leadership roles, 93% work in Europe and Middle East, and two-thirds are practicing as DevOps practitioners. Pertinent model indicators are produced and grouped under constructs based on survey results and validated using PLS-SEM. The formative structural model is presented and validated in three separate focus group sessions, comprising of respectively seven (7), five (5), and seven (7) participants all of whom had held leadership positions; from countries including USA, UK, The Netherlands, UAE, Greece, Georgia, Switzerland. Seventeen (17) focus group participants provided additional responses through a focus group in-session survey, which allowed feedback on specific model constructs. Results indicate that a set of practices, a set of skills, a set of metrics, DevOps adoption planning and the existence of the DevOps adoption leader roles, should be part of organizational aspirations in the definition of leadership in a DevOps transition path.
Earned value management (EVM) gauges the performance of a project against the initial plan, where budget and schedule information are provided upfront. It makes it easier for the project manager to take corrective actions by pinpointing the deviations in time and cost. Agile project management welcomes changes throughout the life of a project. Therefore, it is important to incorporate EVM with Agile to forecast scope. Several attempts have been made to integrate EVM with Agile at iteration and release level to forecast scope. However, those approaches faced the following four challenges: (i) Not knowing and incorporating the changing effects of Agile builds unrealistic project goals; (ii) the use of velocity as a metric for monitoring and controlling work is challenging because of the local nature of this metric; similarly, (iii) focusing on individual team and individual release is another challenge because it is a contrast with the large-scale implication of traditional EVM; additionally, (iv) the method of calculating “percent complete” at work item level is another issue because without an objective basis for counting this progress, projections at higher levels are called into question. To tackle these challenges, in this research, a novel approach has been proposed. The approach consists of three steps. Firstly, a systematic literature review is conducted for scope change influencing factors identification. Secondly, mapping of the identified factors with different elements of the Agile Software Project Scope Rating Index (A-SPSRI) is performed. In the final step, there is quantification, EVM integration and simulation of the universe of projects. The proposed approach has been used at the release planning phase when several agreed upon features are decided to implement their respective iterations. Unlike the one release one team method, and just relying on the velocity current approach, the universe of simulations is used with multiple teams to ensure the large-scale implication of AgileEVM. Moreover, the triad technique is used to gauge the completeness of features implementation in percentile with respect to the iterations.
E-government information systems (IS) projects experience numerous challenges that can lead to total or partial failure. The project failure factors have been identified and studied by numerous researchers, but the root causes of such failures are not well-articulated. In this study, literature on e-government IS project failures in developing-world contexts is reviewed through the application of qualitative meta-synthesis, design–reality gap analysis, and root cause analysis. In the process, 18 causal factors and 181 root causes are identified as responsible for e-government IS project failures. The most prevalent of the 18 causal factors are found to be inadequate system requirements engineering (with 22 root causes), inadequate project management (19 root causes), and missing or incomplete features (16 root causes). These findings can be of use to future researchers, policymakers, and practitioners seeking to identify methods of avoiding e-government IS failures, particularly in developing-world contexts.
Software and IT industry in Pakistan has seen a dramatic growth and success in past few years and is expected to get doubled by 2020, according to a research. Software development life cycle comprises of multiple phases, activities and techniques that can lead to successful projects, and software evaluation is one of the vital and important parts of that. Software estimation can alone be the reason of product's success factor or the product's failure factor. To estimate the right cost, effort and resources is an art. But it is also very important to include the risks that may arise in the in a software project which can affect your estimates. In this paper, we highlight how the risks in Pakistan Software Industry can affect the estimates and how to mitigate them.
When analyzing the causes that lead to digital government success or failure, state of the art research is often divided into two main areas: (1) implementation of these initiatives by government agencies and (2) their adoption by citizens, as some of the most important users. Each of these two perspectives has its own concepts, measurements, and theoretical models. This separation becomes significant when trying to have a comprehensive understanding of digital government success and when facing practical problems since factors affecting both governments and citizens contribute to the success or failure of digital government initiatives. Therefore, this paper proposes a comprehensive digital government success model that attempts to integrate implementation and adoption perspectives. In addition, based on data from the 32 states of Mexico, the paper provides an illustrative example of how the proposed model could be used.
The objective of this study is to identify the critical factors affecting the software quality at the engineering division of a selected software development organization in Sri Lanka. The purpose of the study is to identify the critical organizational factors that affect the software quality in the selected organization, determine the relationship and impact of those factors to software quality and provide recommendations and strategies to improve software quality. Having conducted a critical literature review, four independent variables have been identified which are staff training & development, coworker relationships, diversity of the team and knowledge sharing. A quantitative survey was carried out with a population of 110 and sample size of 86 senior engineers. The data analysis has been conducted using SPSS 19.0 tool and hypothesis validation was carried out using Pearson correlation, regression and significance values. The research findings showcase that, knowledge sharing has the strongest relationship towards software quality. Staff training and development and co-worker relationships also hold a relationship on software quality whereas diversity of the team does not claim a relationship on software quality. This research would help the software organizations to uplift the software quality by various strategies such as improving existing knowledge management systems with new features, introducing certification process for staff trainings and team building activities. This research could be further enhanced with a larger sample size with the use of other qualitative survey techniques.
Collaborative filtering (CF) algorithm uses the preferences expressed by previous users of items being studied and is widely applied to build recommender systems. A collaborative filter predicts items that a user will like based on the vote similar users gave to that item. In this study, we use CF to estimate how much the knowledge of the presence or absence of one software feature can contribute to the correct prediction of the presence or absence of each of the possible remaining features. Completed software project documentations from the Master in Information Technology programs of selected Northern Luzon higher education institutions were first collected. An analysis of these documents revealed 26 unique software features and yielded a binary matrix indicating the presence or absence of a feature in a specific project. Leave-one-out cross-validation was performed to estimate the predictive power of each element of a given holdout vector, using the 26x26 cosine similarity matrix generated from the remaining vectors. The results show that, on average, knowing correctly the presence or absence of only 1 feature can predict with an accuracy of about 58% the presence or absence of the remaining features. This is 8% better than that of a naïve 50-50 random binary guessing algorithm, and somehow indicates the amount of information contributed by one feature value under the
CF algorithm.
This paper deseribes a survey conducted of the staff of the Jet Propulsion Laboratory (JPL) who estimate software costs for software intensive projects in JPL’s teehnical divisions. Respondents to the survey deseribed what techniques they use in estimation of software costs and, in an experiment, each respondent estimated the size and cost of a speeiflc piece of software described in a design document provided by the authors. It was found that the majority of the technical staff estimating software costs use informal analogy and high level partitioning of requirements, and that no formal procedure exists for incorporating risk and uncertainty. The technical staff is significantly better at estimating effort than siztx however, in both cases the variances are so large that there is a 30 pereent probability that any one estimate can be more than 50 percent off.
Ambitious-size projects, moving targets, and managerial turnover present challenges for Information Technology (IT) projects that has the capability to influence the project manager and result in greater variances. Some of the key variables that are considered to be important indicators of IT project risk include project size and project process. Size as measured in person-months is a better predictor of underperformance than other indicators such as budget, duration, and team size. Governance volatility and target volatility are the two aspects of volatility, which have significant impact on performance with the strongest adverse effects being related to project manager turnover. The risk of underperformance increase as project duration increases, where as increase in the size of a project mean increased risk, even for the experienced project managers.
A study was conducted of 97 projects identified as failures by the
projects' managers or parent organizations. Using the project
implementation profile, a set of managerially controllable factors is
identified as associated with project failure. The factors differed
according to three contingency variables: the precise way in which
failure was defined; the type of project, and the stage of the project
in its life cycle. Implications for project management and for future
research on failed projects are discussed. The results demonstrated
empirical justification for a multidimensional construct of project
failure, encompassing both internal efficiency and external
effectiveness aspects. The fact that the critical factors associated
with failure depended on the way in which failure is defined suggests
that it is necessary to know considerably more about how project
managers define failure (and success) and, indeed how the parent
organization makes judgments on the matter
A summary is presented of the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
Successful IT Projects introduces you to all the basics of project management. This is a great preparation for what you will experience in industry, as well as a thorough support for project management courses in IT or systems engineering. The book specifically addresses the needs for an academic student project providing useful hints and guidance. Working through the key phases of a technical project, you will cover project selection, planning, risk and quality management, as well as project monitoring and evaluation. Contexts for project management are described including coverage of systems development lifecycles (including evolutionary and agile methods), managing change, teamwork and professional ethics. Project management industry standards and methods (such as Prince2) are also introduced. Practical coursework exercises follow explanations of theory so your learning is boosted by some hands-on' experience.
During discussions with a group of U.S. software developers we explored the effect of schedule estimation practices and their implications for software project success. Our objective is not only to explore the direct effects of cost and schedule estimation on the perceived success or failure of a software development project, but also to quantitatively examine a host of factors surrounding the estimation issue that may impinge on project outcomes. We later asked our initial group of practitioners to respond to a questionnaire that covered some important cost and schedule estimation topics. Then, in order to determine if the results are generalizable, two other groups from the US and Australia, completed the questionnaire. Based on these convenience samples, we conducted exploratory statistical analyses to identify determinants of project success and used logistic regression to predict project success for the entire sample, as well as for each of the groups separately. From the developer point of view, our overall results suggest that success is more likely if the project manager is involved in schedule negotiations, adequate requirements information is available when the estimates are made, initial effort estimates are good, take staff leave into account, and staff are not added late to meet an aggressive schedule. For these organizations we found that developer input to the estimates did not improve the chances of project success or improve the estimates. We then used the logistic regression results from each single group to predict project success for the other two remaining groups combined. The results show that there is a reasonable degree of generalizability among the different groups.
The book, The Mythical Man-Month, Addison-Wesley, 1975 (excerpted in Datamation, December 1974), gathers some of the published data about software engineering and mixes it with the assertion of a lot of personal opinions. In this presentation, the author will list some of the assertions and invite dispute or support from the audience. This is intended as a public discussion of the published book, not a regular paper.
The practice of building software is a "new kid on the block" technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative "newbies."
In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about.
There's a problem with those facts—and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but over the short lifespan of the software field, all too many of them have been forgotten. While reading Facts and Fallacies of Software Engineering, you may experience moments of "Oh, yes, I had forgotten that," alongside some "Is that really true?" thoughts.
The author of this book doesn't shy away from controversy. In fact, each of the facts and fallacies is accompanied by a discussion of whatever controversy envelops it. You may find yourself agreeing with a lot of the facts and fallacies, yet emotionally disturbed by a few of them! Whether you agree or disagree, you will learn why the author has been called "the premier curmudgeon of software practice."
These facts and fallacies are fundamental to the software building field—forget or neglect them at your peril!
Abstract
During discussions with a group of U.S. software developers we explored the effect of schedule estimation practices and their implications for software project success. Our objective is not only to explore the direct effects of cost and schedule estimation on the perceived success or failure of a software development project, but also to quantitatively examine a host of factors surrounding the estimation issue that may impinge on project outcomes. We later asked our initial group of practitioners to respond to a questionnaire that covered some important cost and schedule estimation topics. Then, in order to determine if the results are generalizable, two other groups from the US and Australia, completed the questionnaire. Based on these convenience samples, we conducted exploratory statistical analyses to identify determinants of project success and used logistic regression to predict project success for the entire sample, as well as for each of the groups separately. From the developer point of view, our overall results suggest that success is more likely if the project manager is involved in schedule negotiations, adequate requirements information is available when the estimates are made, initial effort estimates are good, take staff leave into account, and staff are not added late to meet an aggressive schedule. For these organizations we found that developer input to the estimates did not improve the chances of project success or improve the estimates. We then used the logistic regression results from each single group to predict project success for the other two remaining groups combined. The results show that there is a reasonable degree of generalizability among the different groups.
This paper summarizes the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
The Standish Group reported in their 1994 CHAOS report that the average cost overrun of software projects was as high as 189%. This figure for cost overrun is referred to frequently by scientific researchers, software process improvement consultants, and government advisors. In this paper, we review the validity of the Standish Group's 1994 cost overrun results. Our review is based on a comparison of the 189% cost overrun figure with the cost overrun figures reported in other cost estimation surveys, and an examination of the Standish Group's survey design and analysis methods. We find that the figure reported by the Standish Group is much higher than those reported in similar estimation surveys and that there may be severe problems with the survey design and methods of analysis, e.g. the population sampling method may be strongly biased towards ‘failure projects’. We conclude that the figure of 189% for cost overruns is probably much too high to represent typical software projects in the 1990s and that a continued use of that figure as a reference point for estimation accuracy may lead to poor decision making and hinder progress in estimation practices.
The purpose of this research was to fill a gap in the literature pertaining to the influence of project uncertainty and managerial factors on duration and effort estimation errors. Four dimensions were considered: project uncertainty, use of estimation development processes, use of estimation management processes, and the estimator’s experience. Correlation analysis and linear regression models were used to test the model and the hypotheses on the relations between the four dimensions and estimation errors, using a sample of 43 internal software development projects executed during the year 2002 in the IT division of a large government organization in Israel. Our findings indicate that, in general, a high level of uncertainty is associated with higher effort estimation errors while increased use of estimation development processes and estimation management processes, as well as greater estimator experience, are correlated with lower duration estimation errors. From a practical perspective, the specific findings of this study can be used as guidelines for better duration and effort estimation. Accounting for project uncertainty while managing expectations regarding estimate accuracy; investing more in detailed planning and selecting estimators based on the number of projects they have managed rather than their cumulative experience in project management, may reduce estimation errors.
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 this paper we investigate the impact of staff turnover on software projects. In particular we investigate whether high staff turnover damages project success. We analyse data from an empirical study of 89 software practitioners to show that projects with high staff turnover are less successful. Furthermore our empirical data suggests a relationship between high staff turnover on projects and low staff motivation levels. We discuss factors which have been previously found to improve motivation levels and conclude that improving motivation levels can reduce staff turnover, which in turn increases project success.
Persistent software errors-those which are not discovered until late in development, such as when the software becomes operational-are by far the most expensive kind of error. Via analysis of software problem reports, it is discovered that the predominant number of persistent errors in large-scale software efforts are errors of omitted logic..., that is, the code is not as complex as required by the problem to be solved. Peer design and code review, desk checking, and ultrarigorous testing may be the most helpful of the currently available technologies in attacking this problem. New and better methodologies are needed.
Many people bumble their way through life, often just one wrong move from chaos. This approach can work, but not for rookie or even experienced project managers. Rookie project managers should be given the opportunity to succeed. Ideally, they should be trained in advance and given the necessary tools and resources to get the management job done. In far too many cases, upper management throws the rookie into a project armed with little training and fewer resources. But even in this less-than-ideal situation, managers can survive if they remember four key concepts: communication, negotiation, organization, and facilitation.
The emerging discipline of software risk management is described. It is defined as an attempt to formalize the risk-oriented correlates of success into a readily applicable set of principles and practices. Its objectives are to identify, address, and eliminate risk items before they become either threats to successful software operation or major sources of software rework. The basic concepts are set forth, and the major steps and techniques involved in software risk management are explained. Suggestions for implementing risk management are provided.< >
Most IT experts agree that software failures occur far more often than they should despite the fact that, for the most part, they are predictable and avoidable. It is unfortunate that most organizations don't see preventing failure as an urgent matter, even though that view risks harming the organization and maybe even destroying it. Because software failure has tremendous implications for business and society, it is important to understand why this attitude persists.
CHAOS: Project Failure and Success Report Report Dennis, Massachusetts, http://www.pm2go.com/sample_research/chaos_1994_2.asp [19] Verner J and Cerpa NSoftware Project Failure: Do we ever learn?
- Standish Group
Standish Group International, CHAOS: Project Failure and Success Report Report, 1994, Dennis, Massachusetts, http://www.pm2go.com/sample_research/chaos_1994_2.asp [19] Verner J and Cerpa N., "Software Project Failure: Do we ever learn?" CACM (in press).
Software Project Failure: Do we ever learn
- J Verner
- N Cerpa
Successful IT projects. Thomson Learning
- D Dalcher
- L Brodie
- E M Bennatan
Bennatan, E.M., On Time Within Budget, John Wiley and Sons,
2000.
CHAOS: Project Failure and Success Report Report
- Standish Group
- International