NDLI: Why did your project fail?

Please wait, while we are loading the content...

Why did your project fail?

Content Provider	ACM Digital Library
Author	Cerpa, Narciso Verner, June M.
Abstract	Introduction We have been developing software since the 1960s but still have not learned enough to ensure that our software development projects are successful. $Boehm^{2}$ suggested that realistic schedule and budgets together with a continuing steam of requirements changes are high risk factors. The Standish Group in 1994 noted that approximately 31% of corporate software development projects were cancelled before completion and 53% were challenged and cost 180% above their original $estimate.^{13}$ Glass discussed 16 project $disasters.^{5}$ He found that the failed projects he reviewed were mostly huge and that the failure factors were not just management factors but also included technical factors. Linberg in 1999 found that 20% of software projects failed, and that 46% experienced cost and schedule overruns or significantly reduced $functionality.^{8}$ Later, Glass revisited failed projects and found that poor estimation was high on his list of failure $factors.^{6}$ In 2007 the Standish Group reported that 35% of software projects started in 2006 were successful compared with only 16% in the corresponding 1994 report; however, the 2007 CHAOS report still identifies 46% (53% in 1994) of software projects as challenged (having cost or time overruns or not fully meeting user's requirements) and 19% (31% in 1994) as outright $failures.^{12}$ The validity of the Standish Group findings has been questioned as not consistent with cost overrun results of other $surveys.^{7}$ Jørgensen and Moløkken-Østvold suggested that there are serious problems with the way the Standish Group conducted their research and that the findings were biased toward reports of failure because a random sample of top IT executives was asked to share failure stories when mailed confidential surveys. Recently $Charette^{4}$ commented that "billions of dollars are wasted each year on failed software projects" and that "we have a dismal history of projects that have gone $awry."^{4}$ Charette suggests that from 5%-15% of projects will be abandoned before or shortly after delivery as hopelessly $inadequate.^{4}$ Other recent studies, suggest various failure rates for software development projects up to $85%.^{7}$ Stories of software failure capture public attention and in general there is a perception that software quality is not improving but getting worse. Developing software systems is an expensive, and often a difficult process. Although there are many guidelines for successful software $development,^{9,11}$ few project post-mortems are conducted, and little understanding is gained from the results of past projects. The project manager (PM) and the development team must deal with many pressures from project stakeholders (for example, upper level management, marketing, accounting, customers, and users) during the software development process. These pressures impact both the cost and the quality of the software produced. There are generally more than one or two reasons for a software project to fail, and it usually is a combination of technical, project management and business decisions. Many software project failure factors have been described in the $literature.^{1-13}$ However, most organizations do not see preventing failure as an urgent matter. It is not understood why this attitude $persists.^{4}$ Because most of the literature is based on a handful of failed project case studies, in our research we analyze 70 failed software projects to determine those practices that affected project outcome. We are interested in providing, from the perspective of software practitioners, quantitative evidence targeting those aspects of the development process that contribute to project failure. Essentially, we are interested in updating the results of prior studies and testing the validity of previously reported anecdotal evidence. To date, no one has taken a set of project data and teased it out to identify, for a whole group of such projects, the most common failure factors. We are interested in everyday projects that are not high profile enough to be reported in the literature. Our work builds on that previously reported by $Boehm,^{2}$ $Charette,^{4}$ $Glass,^{5,6}$ Jørgensen and $Moløkken,^{7}$ $Linberg,^{8}$ and the Standish $Group,^{12,13}$ among others.
Starting Page	130
Ending Page	134
Page Count	5
File Format	PDF
ISSN	00010782 15577317
DOI	10.1145/1610252.1610286
Journal	Communications of the ACM (CACM)
Volume Number	52
Issue Number	12
Language	English
Publisher	Association for Computing Machinery (ACM)
Publisher Date	2005-08-01
Publisher Place	New York
Access Restriction	One Nation One Subscription (ONOS)
Content Type	Text
Resource Type	Article
Subject	Computer Science Computer Science

Sl.	Authority	Responsibilities	Communication Details
1	Ministry of Education (GoI), Department of Higher Education	Sanctioning Authority	https://www.education.gov.in/ict-initiatives
2	Indian Institute of Technology Kharagpur	Host Institute of the Project: The host institute of the project is responsible for providing infrastructure support and hosting the project	https://www.iitkgp.ac.in
3	National Digital Library of India Office, Indian Institute of Technology Kharagpur	The administrative and infrastructural headquarters of the project	Dr. B. Sutradhar bsutra@ndl.gov.in
4	Project PI / Joint PI	Principal Investigator and Joint Principal Investigators of the project	Dr. B. Sutradhar bsutra@ndl.gov.in Prof. Saswat Chakrabarti will be added soon
5	Website/Portal (Helpdesk)	Queries regarding NDLI and its services	support@ndl.gov.in
6	Contents and Copyright Issues	Queries related to content curation and copyright issues	content@ndl.gov.in
7	National Digital Library of India Club (NDLI Club)	Queries related to NDLI Club formation, support, user awareness program, seminar/symposium, collaboration, social media, promotion, and outreach	clubsupport@ndl.gov.in
8	Digital Preservation Centre (DPC)	Assistance with digitizing and archiving copyright-free printed books	dpc@ndl.gov.in
9	IDR Setup or Support	Queries related to establishment and support of Institutional Digital Repository (IDR) and IDR workshops	idr@ndl.gov.in

Why cryptosystems fail

Why security standards sometimes fail

Why agile teams fail without UX research

Why our theories of innovation fail us

Why Your Data Won't Mix

Presenting your project

Why did computer science make a hero out of Turing?

Why Writing Your Own Search Engine Is Hard

The Tower of Babel did not fail

Why did your project fail?

Similar Documents

Why cryptosystems fail

Why security standards sometimes fail

Why agile teams fail without UX research

Why our theories of innovation fail us

Why Your Data Won't Mix

Presenting your project

Why did computer science make a hero out of Turing?

Why Writing Your Own Search Engine Is Hard

The Tower of Babel did not fail

Why did your project fail?