Conference Paper

What factors lead to software project failure?

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

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.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... • Missed Deadlines: Project is significantly overscheduled which exceed 30% of estimated project completion time. As seen in different studies such as the Standish Group [12,[14][15][16], the failing of software projects caused by several factors. Verner J et al [15] analyzes data from 70 failed projects, and specifies the following common failure factors: ...
... As seen in different studies such as the Standish Group [12,[14][15][16], the failing of software projects caused by several factors. Verner J et al [15] analyzes data from 70 failed projects, and specifies the following common failure factors: ...
... Verner et al. [15] investigated a number of failed projects to determine the factors behind project failing. A data from 70 failed projects was analyzed to identify the software project failure factors. ...
Article
Full-text available
The successful software project can be defined as the project that meets the planned quality, cost, schedule, and effort. It has been suggested that there are many reasons which might lead to software project success. Several success and failure factors for particular projects were discussed in the literature. This paper aims to identify the most common success factors through reviewing a set of software project reports and case studies. In order to fully understand reasons behind the project success, the reasons behind project failure and the definition of failure itself are discussed. Furthermore, case studies of successful and failed software projects are described. This paper also investigates techniques that have been developed to increase software project success rate and decrease probable failures.
... Several problems in effort estimation and scheduling that cause time pressure are mentioned in the literature. These problems include long schedules [Jones 2006], insufficient experience [Verner et al. 2008], insufficient historical data [Smite and Gencel 2009] Capers Jones [2006] wrote about the reasons for software project failures. In his article, he listed the root causes of unrealistic schedule pressures as follows: "1. ...
... Similarly, Miranda and Abran [2008] suggested using probabilistic models to combat underestimation. Verner et al. [2008] investigation of the cause of failures in 57 projects showed that software projects failed because of multiple factors. However, three of the four most common factors involved time and were outlined as the "delivery date impacted the development process," which was present in 93% of failed projects, "project was underestimated" ...
... Effect on quality assurance. High time pressure caused by unrealistic deadlines leads to minimal quality assurance [Verner et al. 2008]. The quality assurance effort was saved by using workarounds or compromises during implementation, reducing the effort spent on documentation, reallocating tasks to newly assigned developers, or reducing the quality of the final product [Basten and Mellis 2011]. ...
Preprint
Large project overruns and overtime work have been reported in the software industry. Experiments and case studies have investigated the relationship between time pressure and software quality and productivity. Our search strategy examined 5,332 papers and identified 88 papers as having relevant contributions related to time pressure in a software engineering. Our review investigated definitions, metrics, and causes of time pressure. Also, we map the papers to process phases and approaches. Last, we summarize the effects of time pressure on quality and productivity. The majority of the reported results support the outcome of reduced quality and increased productivity with time pressure.
... 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. ...
Article
Full-text available
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.
... Very few studies identified exactly the IT projects failure factors [2,6]. Those factors are related together and their interrelation impact the project performance in different stages of project implementation [8]. ...
... IT Projects fail because of many different failure factors which can be related to technical, business, and/or project management [8,[35][36]. Those factors are interrelated together [6,35,[37][38], and can affect the project performance throughout different phases of projects implementations. ...
... Critical failure factors of IT projects do include the following: undefined requirements or poorly defined requirements, project complexity [2,6,39], poor communication between project stakeholders, poor project control and quality assurance [39][40], unstable organization environment, poor time and schedule estimations, project team members are not qualified [40][41], unrealistic customer expectations, poor project management, poor management of user expectations, turnover in project team throughout project implementation [6,40], shortfall in expertise, lack of motivation for project team, lack of user involvement, ineffective risk management [6,29], poor planning for project schedule and budget, failure to gain user commitment [42], organizational policies, not effectively managing changes on scope and requirements, poor project management practices and methodologies that used in project [41], improper estimations of project costs, and/or inaccurate assessment and planning of project risks [6]. Those critical failure factors have been categorized as shown in Table 1. ...
Conference Paper
The role of Information Technology (IT) systems is critical for organizations in different sectors to increase their performance and profitability, hence, to achieve the strategic goals. However, failure rate of IT projects is still high despite the development of theories, methodologies and frameworks of IT project management in past decades. The aim of this paper is to (1) identify critical failure factors (CFFs) for IT projects, (2) classify CFFs based on their original source, and (3) prioritize CFFs using fuzzy analytic hierarchy process (FAHP). Findings provide project managers and practitioners with a framework that contributes in proper planning the project from the start. Trying to diagnose and solve the highly ranked CFFs minimizes the possibility of IT project failure. Results show that the main factors of project team and planning are the highest impact factors on IT projects performance, and critical failure factors (CFFs) of unstable organization environment and poor communication and reporting between project stakeholders are the most CFFs among all CFFs that impact significantly on IT projects and lead to projects’ failure.
... This is evident from the fact that in South Africa only 35% projects were completed successfully, 46% were challenged and caused over cost (Emam & Koru, 2008). Lower level of employee involvement in decision making, lower level of managerial expertise, and poor project planning can enhance the chances of project failure rates across the world (Verner et al., 2008). ...
... At present, the success of information technology projects is not satisfactory. Recent studies have shown that the overall success rate of information technology projects is very low because whenever a project moves to agile development stage, most of the time project managers are not considered into the project development phases, which results in the failure of most of the IT projects (Reyck et al., 2005;Emam & Koru, 2008;Verner et al., 2008) . For the success of information technology projects a project manager plays a vital role along with other departments. ...
Article
This study aims to reveal the effect of formal definition of project scope on project success. Furthermore , it also intends to examine the moderating effect of managerial expertise in information technology on the above stated relationship. The study followed a cross sectional research design, purposive sampling technique, and self-administered questionnaires. 120 respondents are selected that are working in six information technology based organizations. The results show a significant and positive relationship between formal definitions of project scope with project success. It also revealed that IT project manager's expertise in information technology field has a positive moderating effect on the relationship between project scope and project success. It contributes in existing knowledge of information technology in the perspective of project management. The finding may be fruitful to win the game from the competitors. It also explores the new insights for researchers, practitioners, and consultants of project management. The moderating effect of managerial expertise in IT is unique addition to research.
... 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]. ...
Article
Full-text available
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. ...
Thesis
Full-text available
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.
... As a result, the integration of risk management analysis seems to be an insightful contribution to the formulation of the NRP problem. Such a rationale can be reinforced by the fact that the adoption of risk management constitutes a key reason related to software project success [1], and so its absence is a key reason associated to software project failures [50], once project managers and their development teams cannot assess the specific points of failure in their respective software projects. For instance, a study covering 50,000 software projects found that 53% suffered from troubles on delivery, including an average budget overrun around 56% [38]. ...
Article
Full-text available
Exploring iterative and incremental approaches, current software projects define various delivery releases, which ought to be developed within budgetary constraints, but raising customers’ satisfaction as much as possible. In search based software engineering, such a problem is referred to as next release problem (NRP), in which the selection of software requirements for the next release is reformulated as an optimization problem. More recently, NRP proposals have evolved to a multi-objective perspective, providing non-dominated recommendations that balance the trade-off surface with respect to customers’ satisfaction and development cost. Despite key advancements in NRP proposals, most of them do not deal with software risks, which represent a vital aspect that can deeply impact on project cost and customers’ satisfaction. In such a direction, using multi-objective evolutionary algorithms (MOEAs), this paper proposes and evaluates a risk-driven systematic approach for the NRP problem, in which a risk analysis is incorporated for estimating the impact of software risks in development cost and customers’ satisfaction. By contrasting three different well-known MOEAs, empirical results based on two semi-real datasets reveal the potential efficiency and practical applicability, bringing not only more realistic, precise and meaningful estimations, but also finding a significant percentage of unanticipated solutions.
... As simple as a mobile game can be in comparison with other software applications, its development process must not be conducted in an ad-hoc manner. First, because the life cycle of a mobile game is different from a traditional software [3] and second, due to the low success rate observed on software projects developed with inadequate planning or no planning at all [18]. ...
Conference Paper
Full-text available
Observing the growth of mobile games industry in the past few years, many companies turned their eyes to this market. Each year, the number of released mobile games grows, but the successful ones do not follow the same pace. One of the reasons of this phenomenon is the lack of correct planning and estimation. This paper performs a quasi-systematic review on general software project plans and techniques used both in academy and industry in order to identify which plan is most suited for mobile games. The results show that most mobile games are usually developed using agile methodologies, which suggests that agile planning techniques can be very useful in this context. Among the several works researched and techniques found, we highlight the GAMED methodology, created for the development of educational games. With some adaptations aiming the mobile games’ market, this methodology can provide a robust way to develop mobile games, especially when allied with agile planning techniques
... As discussed earlier, the success of the project is also mainly dependent on the satisfaction of the client which in turn is greatly affected by the risks faced by the projects that may affect the success of the project. The relationship between project success, client's satisfaction, and risks is ternary as shown in Fig 5. Major risks such as poor requirement management, weak project management, poor project planning and scheduling, weak risk management and inefficient team resources are major risk categories which are responsible for project failure [49]. These and other kinds of risks directly affect the progress of the project, processes and client's satisfaction. ...
Article
Full-text available
Software development process tailoring is a standard and regular practice of software development companies. Without realizing it as a regular and well-defined standard approach, companies perform it on an ad-hoc basis. Due to which, process tailoring could not be developed into a formal process and approach to managing software development, processes and projects. Software development process paradigm shift from conventional software development approaches to the agile methodologies left many companies struggling with the reusability of the existing processes and defining new processes from scratch. Limited work on process tailoring and lack of a formal approach, particularly for overwhelmingly used agile methodologies, affected the acknowledgment of this process. Addressing this limitation, present research work formulates a process tailoring framework to tailor agile-based software development processes. The proposed framework recommends tailoring three key processes of agile methodologies based on the project state considering the client’s perspective and requirements. The existing literature have been reviewed to develop a theoretical framework which is verified and validated through structured interviews and case study of real projects. The framework provides a formal and a structured approach to tailor agile-based processes and methodologies.
... But apart from these entire endeavors, the studies conducted by the researchers over the past decade state that the failure rate of software has crossed the threshold. They identified certain causes of failure [3] which are enumerated as (1) unarticulated project goals, (2) unclear requirements, (3) sloppy software development models, (4) inaccurate estimation of resources, and (5) poor communication among customers and developers. ...
... 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. ...
... 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]. ...
Conference Paper
Full-text available
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 ® .
... 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]. ...
Article
Full-text available
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.
... 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. ...
Article
Full-text available
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]. ...
Preprint
Full-text available
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.
... 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. ...
Conference Paper
Full-text available
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.
... 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]. ...
Conference Paper
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.
... 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. ...
Article
Full-text available
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.
... A relevant degree of uncertainty (in the sense of Turner and Cochrane (1993)) is usually present in these kinds of projects. First, the projects of the new industrial revolution are intensive in software engineering, and information technologies, which are usually characterized by bad definition in project goals and requirements (Kaur and Sengupta (2013), Hofmann and Lehner (2001), Verner et al. (2008), Sommerville and Sawyer (1997), etc.). ...
Chapter
We are at the beginning of a new technological revolution, propelled by the development of cyber-physical systems and technologies like Internet of Things, Bid Data, Cloud Computing, 3D Printing, etc. Therefore, we will see an avalanche of projects to implement new business models, products, services and companies. In this paper, we analyse the main characteristics of these projects and we wonder about the appropriate methodologies and managerial styles to lead them. We argue that these projects are complex in nature, according to the current literature on project complexity and thus, classical project management approaches might be unsuitable for managing them. We suggest some clues to seek for new managerial styles, mainly in the literature concerning innovation and new product development and within the “Agile” approach.
... A relevant degree of uncertainty (in the sense of Turner and Cochrane (1993)) is usually present in these kinds of projects. First, the projects of the new industrial revolution are intensive in software engineering, and information technologies, which are usually characterized by bad definition in project goals and requirements (Kaur and Sengupta (2013), Hofmann and Lehner (2001), Verner et al. (2008), Sommerville and Sawyer (1997), etc.). ...
Chapter
Economic Activity takes two alternative forms: the Market and the Firm. Economics is a social science that tries to explain how to generate wealth and how it is distributed. The firm is a social organization whose members decide to cooperate to generate wealth and its distribution among the stakeholders. They certainly share a common goal. However, to translate economic principles to management is an open challenge. Traditional IO as understood among the economists deals with the generation of wealth through the market, which if it is well designed will achieve a fair distribution through endogenous dynamics towards equilibrium. On the other hand, a proper theory of the firm needs explicit rules of governance and operations. This fact requires a New I.O dealing with uncertainty far beyond probability; individual and collective bounded rational agents; specialization and heterogeneity; imperfect information and variety; incentives and penalties to avoid free riding, and how to develop core competences such as entrepreneurship, innovation and knowledge management. The paper revised I.O and ends up with a map of Management Sciences to help designing the Management Engineering curricula and the range of specific skills and competences demanded by different institutions.
... Tendo em vista a importância das informações resultantes é necessário que, os SI automatizados apresentem disponibilidade e confiabilidade, ou seja, a probabilidade de operar com sucesso, de acordo com as especificações, em um determinado momento e a probabilidade de operar sem apresentar defeitos, sob certas condições, em um determinado intervalo de tempo (Pfleeger, 2004, p. 330 Verner et al. (2008) [7] Ahimbisibwe et al. (2015) [11] Standish Group (2014) [3] Sweis (2015) [8] Marques et al. (2013) [12] Rukshan e Mangala (2010) [4] Sudhakar (2012) [9] Kappelman et al. (2006) [13] Nasir e Sahibuddin (2011) [5] Kouzari et al. (2015) [ (2011) foi de 1990 a 2010; artigos que continham no título "development projects" e "information systems" e/ou "IS" e/ou "software" e/ou "information technology" e/ou "IT"; além disso, os artigos deveriam conter as palavras chaves: "critical factors of failure" e/ou "failure factors" e/ou "critical success factors" e/ou "success factors". (2016) Em relação às variáveis, utilizadas nesta pesquisa para determinar os fatores críticos em projetos de desenvolvimento de software, salienta-se que estão presentes na maioria dos estudos utilizados como referências, entretanto, em muitos deles aparecem distribuídas em fatores que apresentam nomenclaturas diferentes. ...
... 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. ...
Article
Full-text available
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. ...
Article
Full-text available
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. ...
Conference Paper
Full-text available
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. ...
Conference Paper
Full-text available
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.
... Our results indicate that there is no a single cause for software unavailability, as also claimed in some of the previous software failure-related studies. 39,40 Instead, unavailability of business-critical systems is the result of several causes that form a network where the causes are connected to each other. Moreover, the causes come from different contexts. ...
Article
Full-text available
Software unavailability can lead to disastrous consequences ranging from delays and cancellation to a loss of millions of dollars of technology. However, research on the causes that can make systems unavailable is still little. The aim of this paper is to investigate such causes in an industrial context using 2 qualitative approaches ((a) interview and (b) retrospective analysis) using archival data and records from a student information system. As a result, connectivity, human, hardware, storage, and software were found to be the important categories of causes for the unavailability. Besides, the critical lessons to be learned that relate to activities of software management and software business are also discussed. This includes vendor support, systems documentation, health check process, licensing, and software updating or upgrading. To strengthen the claim that our findings are promising, we compare our main findings with those of a previous study. This study can generally assist software engineering people including engineers, developers, project managers, vendors. Additionally, this paper dis cusses the threats to the study's validity and suggests open problems for future research.
... 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. ...
Article
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.
... 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]. ...
Chapter
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.
Chapter
It has been well-known that the chance of successfully delivering a software project within an allocated time and budget is very low. Most of the researches in this area have concluded that “user's requirements” of the systems is one of the most difficult risks to deal with in this case. Interestingly, until today, regardless of amount of effort put into this area, the possibility of project failure is still very high. The issue with requirement can be significantly increased when developing an artificial intelligence (AI) system, where one would like the systems to autonomously behave. This is because we are not only dealing with user's requirements, but we must also be able to deal with “system's behavior” that, in many cases, do not even exist during software development. This chapter discusses a preliminary work on a framework for risk management for AI systems development projects. The goal of this framework is to help project management in minimizing risk that can lead AI software projects to fail due to the inability to finish the projects on time and within budget.
Conference Paper
In software engineering, project scheduling is an essential factor that determines success of projects. Success is influenced by various project scheduling estimates, such as accurate estimates of project's duration and budget. These estimates highly depend on uncertainties related to commonly occurring unpredictable events during a project's duration. Furthermore, budget and duration estimates depend on the available teams and their performance levels with respect to tasks and circumstances. This paper proposes a data-driven Discrete-Event Simulation (DES) approach to provide decision support to project managers in project scheduling. Moreover, we introduce a tool that we developed for this purpose, which features various visualizations of results and helps project managers compare different strategies and parameters.
Article
Full-text available
This study extends the debate surrounding the components of IS project success by reviewing success factors from the perspective of their interdependency and influence on each other. This research utilises interpretive structural modelling as the methodology and framework to develop the relationships between the selected factors. This approach is presented as a mechanism that can provide greater insight to the underlying causal interrelationships associated with IS project success and the successful transition to operations. The findings identify a number of key outcomes that have significant driving influence on other interconnected factors in the final model. This study highlights the benefits of an interpretive approach where IS factor interrelationships can be modelled to demonstrate potential influence on other connected factors thereby, increasing the chances of project success.
Article
Full-text available
Automatizar processos, através do uso de software, tornou-se uma prática amplamente utilizada nos mais diversos níveis organizacionais. Neste contexto, o sucesso de projetos de desenvolvimento de software passou a ter um papel fundamental e determinante. A importância da definição dos atributos de sucesso, bem como da determinação e tratamento dos fatores críticos em projetos de desenvolvimento de software, pode ser evidenciada através dos diversos estudos já realizados. Este trabalho teve como objetivo verificar as possíveis relações existentes entre os fatores críticos em projetos de desenvolvimento de software e os atributos que determinam o seu sucesso. O emprego de métodos estatísticos, aos resultados obtidos de uma survey research, aplicada aos profissionais de TI de organizações brasileiras, possibilitou verificar a existência de relações entre os fatores críticos, entre os atributos de sucesso e entre os fatores críticos e os atributos de sucesso. As relações entre os atributos de sucesso justificam, para essas organizações, a sua utilização como indicadores do sucesso para projetos de desenvolvimento de software.
Conference Paper
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.
Article
Full-text available
Purpose: In the architecture, engineering and construction (AEC) industry, technology developers have difficulties fully understanding user needs due to the high domain knowledge threshold and the lack of effective and efficient methods to minimise information asymmetry between technology developers and AEC users. Design/Methodology/Approach: A synthetic approach combining domain knowledge and text-mining techniques is proposed to help capture user needs, which is demonstrated using BIM apps as a case. The synthetic approach includes the: (i) collection and cleansing of BIM apps’ attribute data and users’ comments; (ii) incorporation of domain knowledge into the collected comments; (iii) performance of a sentiment analysis to distinguish positive and negative comments; (iv) exploration of the relationships between user sentiments and BIM apps’ attributes to unveil user preferences; and (v) establishment of a topic model to identify problems frequently raised by users. Findings: The results show that those BIM app categories with high user interest but low sentiments or supplies, such as ‘reality capture’, ‘interoperability’ and ‘structural simulation and analysis’, should deserve greater efforts and attention from developers. BIM apps with continual updates and of small-size are more preferred by users. Problems related to the ‘support for new Revit’, ‘import & export’ and ‘external linkage’ are most frequently complained by users. Originality/Value: The main contributions of this work include: (i) the innovative application of text mining techniques to identify user needs to drive BIM apps development; and (ii) the development of a synthetic approach to orchestrating domain knowledge, text-mining techniques (i.e. sentiment analysis and topic modelling) and statistical methods in order to help extract user needs for promoting the success of emerging technologies in the AEC industry.
Thesis
Disponível em: http://repositorio.utfpr.edu.br/jspui/handle/1/4281 Esta dissertação propõe um método e uma linguagem de modelagem gráfica de requisitos de software e sistemas sob o nome de RIMON (Requirements and Interdependencies MOdeling Notation). Esta linguagem permite representar requisitos e suas interdependências de forma sistemática, precisa e expressiva, visando contribuir para a melhoria da qualidade da especificação de requisitos de softwares e sistemas. Originada a partir de conceitos da abordagem RON (Requisitos Orientados a Notificações), a RIMON foi criada para ser visualmente atrativa em possíveis usos comerciais. Essa atratividade decorre de um desenvolvimento fundamentado na teoria de física das notações (Physics of Notations – PoN), que fornece princípios destinados a produzir notações visuais eficientes em termos de comunicação. Adicionalmente, a linguagem é definida por meio de uma sintaxe abstrata (metamodelo) e de uma sintaxe concreta (sintaxe visual) complementada por um mapeamento semântico preciso. Em relação ao método proposto, este consiste em um ciclo iterativo de atividades para identificação e análise dos dados de entrada e modelagem gráfica dos requisitos e suas interdependências. A RIMON oferece características tais como suporte a modelagem de requisitos funcionais e não-funcionais, entidades, atributos, pré-condições, pós-condições e identificação de conflitos. Como diferencial, a modelagem de pré-condições possibilita representar restrições relativas a requisitos não-funcionais por meio de atributos contendo condições lógico-matemáticas. Por fim, este trabalho apresenta três experimentos de modelagem usando RIMON, tanto de requisitos de sistemas (extraídos da literatura) quanto de requisitos de software (projeto real), destinados a demonstrar e verificar as capacidades da linguagem. Available in: http://repositorio.utfpr.edu.br/jspui/handle/1/4281 This dissertation proposes a method and a language for graphic modeling of software and systems requirements, under the name of RIMON (Requirements and Interdependencies MOdeling Notation). This language allows to represent requirements and their interdependencies in a systematic, precise and expressive way, aiming to contribute to the quality improvement of software and systems requirements specifications. Sourced in concepts of RON (Requirements Oriented to Notifications) approach, RIMON was designed to be visually attractive in its possible commercial usage. This attractiveness results from a development grounded in the Physics of Notations (PoN), which provides principles for creating efficient visual notations in terms of communication. In addition, the language is defined by an abstract syntax (metamodel) and a concrete syntax (visual syntax), complemented by a precise semantic mapping. Regarding the proposed method, it includes a set of steps for identification and analysis of input data, graphical requirements and interdependencies modeling. RIMON offers features such as support for modeling functional and nonfunctional requirements, entities, attributes, preconditions, postconditions and conflict identification. As a notable characteristic, the modeling of preconditions allows the representation of constraints related to non-functional requirements by means of attributes containing logical-mathematical conditions. At last, this work presents three modeling experiments using RIMON, including system requirements (extracted from the literature) and software requirements (real project) environments, designed to demonstrate and verify the capabilities of the language.
Article
Context Large project overruns and overtime work have been reported in the software industry, resulting in additional expense for companies and personal issues for developers. Experiments and case studies have investigated the relationship between time pressure and software quality and productivity. Objective The present work aims to provide an overview of studies related to time pressure in software engineering; specifically, existing definitions, possible causes, and metrics relevant to time pressure were collected, and a mapping of the studies to software processes and approaches was performed. Moreover, we synthesize results of existing quantitative studies on the effects of time pressure on software development, and offer practical takeaways for practitioners and researchers, based on empirical evidence. Method Our search strategy examined 5414 sources, found through repository searches and snowballing. Applying inclusion and exclusion criteria resulted in the selection of 102 papers, which made relevant contributions related to time pressure in software engineering. Results The majority of high quality studies report increased productivity and decreased quality under time pressure. The most frequent categories of studies focus on quality assurance, cost estimation, and process simulation. It appears that time pressure is usually caused by errors in cost estimation. The effect of time pressure is most often identified during software quality assurance. Conclusions The majority of empirical studies report increased productivity under time pressure, while the most cost estimation and process simulation models assume that compressing the schedule increases the total needed hours. We also find evidence of the mediating effect of knowledge on the effects of time pressure, and that tight deadlines impact tasks with an algorithmic nature more severely. Future research should better contextualize quantitative studies to account for the existing conflicting results and to provide an understanding of situations when time pressure is either beneficial or harmful.
Chapter
This chapter entitled “So What” confronts the dilemma of theory versus practice. The chapter discusses the implications for software systems development for the software development industry and for higher education. It suggests five areas in which industry needs to change Giving much greater emphasis, status, resources and time to requirements elicitation.Paying much more attention to non-functional (quality) requirements and process exceptions.Staff selection and skills development.Greater engagement with stakeholders throughout the process.Process change to include pre-development risk identification and post implementation change management. Giving much greater emphasis, status, resources and time to requirements elicitation. Paying much more attention to non-functional (quality) requirements and process exceptions. Staff selection and skills development. Greater engagement with stakeholders throughout the process. Process change to include pre-development risk identification and post implementation change management. Specific suggestions are made in each of these areas. This chapter also makes specific proposals for higher education curricula and research. Finally the chapter discusses the implications for the professionalisation of software systems development. It argues that the discipline’s aspirations of securing exclusivity over work in the industry can only be achieved if the unique attributes of software systems development are recognised and new theory developed to explain the implications of these attributes. This theory is most unlikely to come from the software engineering paradigm due to its emphasis on methodology and method over models. New, unique theory is more likely to emerge from applying a socio-technical paradigm and open systems thinking to the development process.
Chapter
The objective of this chapter is to offer a method of explicating the software systems development (SSD) process as a sociotechnical process using Open Systems Theory. It explains how this theory is relevant to software systems development (SSD). It suggests that “Open Systems Thinking” (OST) that flows from open systems theory can be applied to SSD in two senses. The first way, applied by Checkland and others in Soft Systems Methodology, is as a means of analysing the real world problem the software system is intended to solve. The second sense applies OST to the software development process itself. These two explanations demonstrate the complexity and intricacy of the SSD task. OST presents the physical world as an ever changing, infinitely recursive series of processes organised into process chains. Software systems attempt to map the real world processes onto a pre-defined, determinant artefact. The two are inherently contradictory. The process used to achieve this mapping is dependent on the people who drive the process (the developers), and the stakeholders who define the process to be mapped. In OST terms people are themselves subsystems in the development process. People are integral to the process because the intangibility of software dictates that people must hold the vision of the product and must communicate their own sense of the vision between each other. Software systems developers are charged with resolving the conflicts between the physical world and the virtual world. OST is used to explain and delimit the nature of the problem for developers.
Conference Paper
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.
Article
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.
Preprint
Full-text available
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.
Article
Full-text available
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.
Chapter
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.
Conference Paper
Full-text available
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.
Article
The social, political and cultural issues faced by organisations and their senior management team in the delivery and adoption of strategic projects, is highly complex and problematic. Despite a mature body of literature, increasing levels of practitioner certification, application of standards and numerous government initiatives, improvements in success have been minimal. In this study, we analyse the key underlying factors surrounding the failure of Information Systems (IS) projects and explore the merits of articulating a narrative that focuses on senior management embracing practical pessimism. Specifically, we develop a hypothesis supported by empirical study that leverages expert’s views on the dominance and interrelationships between failure factors within PRINCE2® project stages using an Interpretive Ranking Process. Our findings establish how the concept of dominance between individual failure factors can necessitate senior management to make key informed and timely decisions that could potentially influence project outcomes based on an empirical derived, interpretive predictive framework.
Conference Paper
Full-text available
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.
Article
Full-text available
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.
Article
Full-text available
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
Article
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.
Book
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.
Article
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.
Article
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.
Article
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!
Article
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.
Article
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.
Article
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.
Article
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.
Article
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.
Conference Paper
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.
Article
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.
Article
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.
Article
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.< >
Article
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