The course of true love never did run smooth

Software projects are inherently complex, risky and require careful planning. This planning covers software development, estimates, staged development, requirements capture, risk management, business case studies, user interface prototypes and overall project control. Proper planning ensures that the project doesn’t move away from its targeted goals.

Following are some of the reasons for the failure of many I.S. projects:

• Most of the time, clients do not clearly define their business needs and mapping them to functionalities required. Business Requirements should be properly extracted and correctly documented.

• There is a communication gap between the analyst and the customer. The analyst does not bother to communicate in the user’s language and fails to see that the technical schemes dissuade the user.

• Some projects fail due to the absence of version control system or any other kind of enforced record keeping. This record keeping is necessary during development and during maintenance as well.

• Saving time by shifting off issues to the next phase creates unrecoverable losses. A job half done always gives problems.

• Sometimes programmers wrongly accept the incomplete design in a hope that it will save time. This sometimes deviate the programmers from the right approach that should have been taken.

• Additional manpower is not always effective. It sometimes decreases the productivity. If one woman can produce a baby in nine months, nine women cannot produce a baby in one month.

• When managers fail to provide timely, adequate and properly trained resources, their projects generally fail.

• When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn’t work.

• If the software developers are asked to work overtime and it is unpaid in the schedule baseline, then developers lose their interest inside the project.

• Sometimes, managers knowingly omit some tasks from the budget & schedule, considering them low-priority. This sometimes leads to a disaster and it is realized afterwards that low-priority tasks were in fact not that low.

• If developers keep on doing last minute changes in the project, then such changes are left untested and appear on the ground when it is too late.

• There are many projects that inherently require updates and changes in their delivered products. It can be a failure if no practice is done to handle changes systematically to maintain its integrity over time.

• There are lots of errors and bugs usually undiscovered when same people are doing design and coding, or coding and testing.

• Lots of projects fail due to an unneeded complexity introduced in the design or implementation.

• Some of the projects are trusted solely on one person. Such hero-based projects are vulnerable to the failure.

• Projects that don’t plan for handling risks are hit by sudden surprises and can end up losing the client.

References:

[1] H. Winklhofer, “Organizational Change as a Contributing Factor to IS Failure”, Proceedings of the 34th Hawaii International Conference on Systems Sciences, January 2001, IEEE Computer Society, Los Alamitos

[2] Kurt R. Linberg, Software developer perceptions about software project failure: a case study, Journal of Systems and Software, Volume 49, Issues 2-3, 30 December 1999, Pages 177-192.

[3] S. Flowers, Software Failure: Management Failure. Amazing Stories and Cautionary Tales, Wiley, Chichester, New York, (1996), ISBN 0 171-95113-7

[4] William A. Yasnoff, How to Cause Information Technology Disasters, http://faculty.washington.edu/ocarroll/infrmatc/managing/howto/index.htm

[5] David J. Smith FBCI, Business Continuity Management: Good Practise Guidelines, The Business Continuity Institute, 2002, http://www.thebci.org

[6] Jari Vanhanen. Improving configuration mangement processes of a software product, Master’s Thesis, Helsinki University of Technology, December 1997.

[7] Paul Beynon-Davies. Human error and information systems failure: the case of the London ambulance service computer-aided dispatch system project. University of Glamorgan, Pontypridd CF37 1DL, Wales, UK

[8] Martin Neil, Are software failures deterministic?, Information and Software Technology, Volume 39, Issue 3, March 1997, Pages 217-219.

[9] Chris Johnson, Forensic software engineering: are software failures symptomatic of systemic problems?, Safety Science, Volume 40, Issue 9, December 2002, Pages 835-847.