se-failure stories

1. Software Projects
Failure Stories
Presented by
Mr. Manish Tripathi ( I – 15-18-19)
Thakur Institute of Management Studies
&
Research
(Sunday 12 February, 2017)

3. #1
Denver Airport Baggage System

4. THE EXPECTATIONS
• Originally planned as the most advanced system
in the world, the baggage handling system
• Planned to automate the handling of baggage
through the entire airport

5. THE RESULT
• The system proved to be far more complex than
some had original believed
• The problems building the system resulted in the
newly complete airport sitting idle for 16 months
while engineers worked on getting the baggage
system to work
• The delay added approximately $560M USD to
the cost of the airport
• At the end of the day, the system that was finally
implemented was a shadow of what was
originally planned

6. THE RESULT
• Rather than integrating all three concourses into a
single system, the system supported outbound flights
on a single concourse only
• All other baggage was handled by a manual tug and
trolley system that was hurriedly built when it
became clear the automated system would never
meet its goals
• Even the portion of the system that was
implemented never functioned properly and in Aug
2005 the system was scrapped altogether
• The $1M monthly cost to maintain the system was
outweighing the value the remaining parts of the
system offered and using a manual system actually
cut costs

7. REASONS FOR FAILURE
• Underestimation of complexity
• Complex architecture
• Changes in requirements
• Underestimation of schedule and budget
• Dismissal of advice from experts
• Failure to build in backup or recovery process to
handle situations in which part of the system
failed.

8. #2
London Stock Exchange
Taurus (Transfer and Automated Registration of
Uncertificated Stock) Share trading system

9. THE EXPECTATIONS
• Efforts to move form paper based stock trading to a
computerized system
• Due to the massive growth in share trading in the
1980 the use of paper-based tracking of share
ownership and transfer became an impossible task
• Initiated in 1983, the Taurus project was to replace
the archaic manual based system with a modern
high-speed and efficient computerized one
• Helping maintain London’s place as a financial hub
• The project would usher in the modern age into a
world whose manual processes had hundreds of
years of tradition and many vested interests

10. THE RESULT
• After ten years of effort and millions of dollars spent, the
project is abandoned as it becomes clear that the system will
never work as planned
• The Taurus failure is really two failures in one
• The first attempt at the project involved the creation of a
central database that would act as a hub for the recording of
data and the execution of transactions
• Requiring a complete change in business process flows, the
project in part negated the need for middlemen (registrars)
who had traditionally played a role in the share trading
processes
• This resulted in fierce opposition as it would mean the end to
the highly profitable business for the registrars
• After 5 years of development and the realization that changing
the business processes was a significant technical challenge as
well, the design was dropped in 1989
• The Stock Exchange then embarked on a difficult search for a
design that would be acceptable to all of the stakeholders

11. THE RESULT
• Settled in 1990, the revised design adopted a hub and
spoke type system in which the registrars continued to
play their part in the transaction flow while still meeting
the needs of the other stakeholders involved
• The Stock Exchange would act as the hub and each
registrar would have their own components that would
interface to the hub. This increased the complexity of the
project, but negated some of the stakeholder opposition.
• The Stock Exchange’s parts of the new design was to be
implemented by modifying an existing system purchased
from the US. As well as the challenge of modifying the
software the Stock Exchange also faced major challenges
having British law and regulations changed to support the
new business processes that would come into use once
the system was live

12. THE RESULT
• Reports indicate that following requirements gathering as
much as 70% of the original system would need to be
rewritten
• Such significant modification essentially negated the value
of purchasing the system and resulted in major challenges
developing and testing the software
• Implementation dates slipped a number of times to
accommodate changes and increased testing activities
• After a number of such delays and external audits that
suggested the underlying design that had been adopted had
become unworkable, the project was eventually scrapped in
1993
• Other stakeholders (including the registrars) who had built
systems to interface to the London Stock Exchange hub
forced to abandon their portions of the system
• £75M lost by the London Stock Exchange and as much as
£400M by other stakeholders

13. REASONS FOR FAILURE
• Failure to align the differing interests of the
stakeholders
• Underestimation of complexity
• Lack of effective governance
• Poor strategic decision making (purchasing a
system that was a poor fit to requirements)

14. #3
Novopay (Payroll system)
New Zealand Ministry of Education

15. THE EXPECTATIONS
• The Novopay system was intended to be a tool that
would streamline payments to the 110,000 teachers,
administrators and staff throughout New Zealand’s
educational system
• The project had its origins in a 2005 decision that the
existing payroll facilities needed modernization
• Following a bid process Australia’s Talent2 was
selected to both implement the new system and then
operate it on a service contract basis until 2020
• The original project called for the system to be
implemented in 2010

16. THE RESULT
• Following a number of delays the project only
reached operationally status in Aug of 2012
• Immediately following its operational launch
problems were encountered
• Within a few months, 90% of schools were affected.
• Some school employees reported receiving incorrect
payments while others were paid nothing at all
• Affected employees struggled to maintain their
personal finances in the face of the cash flow
problems the systems failures were causing
• At one point affected staff had reported more than
18,000 payroll errors and the operational staff
supporting the system appear to have been
overwhelmed by the amount of manual intervention
needed to correct those errors

17. THE RESULT
• Tracking and analysis of the errors identified after the launch,
identified more than 500 distinct defects in the system
• Of those 44 were deemed to be very serious
• In Aug of 2012 when the system went live reports indicate that
only 147 defects were known meaning that Quality Assurance
testing had failed to identify several hundred problems in the
system
• Many of those problems were traced back to errors in the original
project requirements and the design of the new system that
allowed incorrect data to be entered into the system thereby
leading to incorrect payroll payments and related problems
• A Mar 2013 review performed by Deloitte raised serious questions
about the stability of the system and outlined a 1-year remedial
plan that needed to be followed to ensure the operational
stability of the system and that the originally planned business
benefits were realized
• In October 2014, Novopay transitioned to be 100% operated by
the New Zealand Ministry of Education, The error rate for
payments is now less than 0.2 per cent

18. REASONS FOR FAILURE
• Requirements problems and poor system design
• Usability issues
• Failure to establish appropriately robust data validation
steps to ensure the quality of data input into the system
• Poorly designed reports that inhibited management
oversight of the system’s use
• Failure of quality control tests (failure to identify data
corruption issues and logic flaws)
• Implementing the system with a high number of
unresolved defects
• Lack of control over manual intervention processes
used when problems were encountered

19. REASONS FOR SOFTWARE PROJECT FAILURES
• Incomplete or confusing requirements
• Miscalculated Time and Budget Frames
• Was it Needed At All?
• Lack of Communication
• No End-user Involvement
• Unfocused Executive Sponsors
• Not involving all stack holders
• Chasing Technology

20. REASONS FOR SOFTWARE PROJECT FAILURES
• Lack of Periodic Assessment
• Lack of Quality Testing
• Accepting a forced schedule or mandated
completion/ milestone dates without substantial
data and analysis
• Adding excessive personnel to achieve unrealistic
schedule compression
• Failing to account and adjust for requirements
growth or change and making necessary adjustments
to the schedule and budget forecasts
• Emotional or “intuition-based” stakeholder
negotiation that ignores facts and statistics

21. Dim query As Boolean= True
Dim message As String
If query = True Then
message = "Raise your Question"
ElseIf query = False Then
message = "THAN YOU"
End If