The main goal of this presentation is to study three large information systems projects that failed over the last five years and identify the reasons of failure and derive the challenges and recommendations for IS strategists.
1. IS Projects Failures and Recommendations
Final Integration Project
By: Monzer AL-Shaikh Warak
John Tan
Under supervision of Dr. Mamata Bhandar
2. The content
1. The Goal
2. Avon Failed Project
3. British Home Office Failed Project
4. Novopay Failed Project
5. The conclusion.
6. References
3. 1.The Goal
The main goal of this presentation is to study three large information systems
projects that failed over the last five years and identify the reasons
of failure and derive the challenges and
recommendations for IS strategists.
4. The story of failure
The biggest
problem in failed
IT projects is the
Unconsolidated
difference views
of the each
stakeholders.
In the following slides, we will exploring 3 fail big projects …
5. Avon’s Failed
Project
Project type: Product sales and ordering system
Project name: The “Promise” project
Date : Dec 2013
6. 2- Avon’s Failed Project
• Avon faced a failure before when its Brazilian operations suffered under an Oracle
system, then decided to switch the software into SAP, thinking that the cause of the
problem was due to the software!
• The new system was intended to streamline the ordering process, thereby allowing
Avon to reduce costs and better meet customer needs and expectations.
• This initiative was intended to save approximately US$40m per year.
• The project has now been abandoned with a write-off of between
$100 and $125M.
• Next slides clarify the Reasons behind Avon’s Project failure...
7. Reasons behind Avon’s Project failure:
1. Lack of collected requirements
That’s clear from the gap between the users expectations and final products!, the users expected an easy to use
solution that could work on their tablet devices, which is not achieved an wasn’t in the project scope.
2. Poor of knowledge of software selection
Its not clear whereas if there was a clear methodology used by the Avon
decision maker in vendor selection process! The Avon selected Oracle then
it switched to SAP without clear studying of the real reasons of Oracle failed
implementation .
3. Lack of end users training
In additional of old aged users, it seem that people are less patient with technology!
Users found that the system delay their process and became more complicated, it maybe not! but its clear that
users didn’t trained well on the “to-Be“ processes or on the software itself
or maybe on both! Which is very critical.
For that the SAP reported that the end users refuse to use the product as “working as designed”
8. Reasons behind Avon’s Project failure:
4. Lack in stockholders analysis
it’s a nature reason if we know the requirements didn’t collected well! The expectation of stakeholders
wouldn't be clear, thus it wouldn’t met.
5. Weak change management
Reports talked about The technical project itself was very well structured
and you would expect that cultural change is necessary for it to work,
but for a project of that magnitude need a sponsor right at the top.
So even if there is resistance to change, things get done with support from above, which was maybe
Absent.
9. Challenges & Recommendations for IS strategists
1. Understand the business strategy and recommend the appropriate IS strategy.
2. Understand why the first project failed and what lesson was learnt before starting the 2nd project.
3. Ensure the involvement of all stakeholders.
4. More efforts should be put into the selection of vendors and the capability of their systems should
be studied to ensure they fit into the IS strategy.
5. More efforts should be focus on the design and planning phase.
6. Ensure that requirements are communicated clearly to the vendors involved.
7. Choose either to use interface from SAP so that there is no integration issues. Or ensure both
vendors work together with a competent PM who can control and monitor the progress.
8. Form a user group to test the application and provide feedback for improvement before rollout.
10. British Home
Office Failed
Project
Project type: Immigration controls
Project name: e-Borders
Date : Mar 2014
11. 2- British Home Office Project
• The project was brought in by the then Labor government in 2007 in order to control illegal
immigration after scrapping exit checks.
• e-Borders was not a complex system. It was intended to provide a searchable record of everyone
entering and leaving the country, record their passport number, email address and purpose of visit,
and generate a warning if anyone on a terrorist or criminal watch list was arriving.
• The Project leader - Raytheon - had its contract terminated
in July 2010 after a series of delays after being paid £188m
of its £742 million contract and was later replaced by IBM.
• The e-Borders programme suffered further delays after
Raytheon's contract was terminated as sea and rail
passengers are still not covered by e-Borders.
• In March 2014 announced that the e-Borders programme would be terminated.
• In August 2014 a binding arbitration tribunal awarded Raytheon a total of £224m in
compensation against the Home Office for the incorrect termination of their contract.
12. Reasons behind e-Borders Project failure
The inability of management or government to understand what is realistically possible with given resources and the
inability to set clearly defined requirements and to stick to that project scope is the absolute number one reason why
public or private IT projects fail, the other some reasons are:
1. Failure to establish appropriate benchmarks against which to track project progress and vendor
performance.
The project which is provided by the Trusted Borders consortium lead by Raytheon and includes Serco, Detica,
Accenture and Qinetiq. Raytheon had its contract terminated in July 2010 after a series of delays after being
paid £188 million of its £742 million contract and was later replaced by IBM.
In August 2014 a binding arbitration tribunal awarded Raytheon a total of £224m
in compensation against the Home Office for the incorrect termination of their
contract.
2. Failure to define and stabilize requirements.
The original pilot was only tried at airports. The people ordering the system assumed that it would also work at
ports and on the Channel Tunnel. It didn't. Inspectors also found the data set was not extensive enough for the
e-borders programme to "count in and out" all foreign national passengers - and that this would not be possible
until 2018 at the earliest.
13. Reasons behind e-Borders Project failure
3. Under-estimation of complexity.
Security concerns imposed on the project by civil servants whining about data protection meant that
border staff couldn't see all the data, and had to ring the police or
customs to get information from their version of the system.
The police would often refuse to let the Border Agency staff use
their end of the database and that risk wasn't identified early.
4. Politics
Reports notice that when the system was ordered in 2007, no one in government realized that it was
illegal under EU law.
14. Challenges & Recommendations for IS strategists
1. The government needs to engage subject matter experts right from the beginning to help with
requirement definitions
2. Streamline procurement process and reduce red tape.
3. The right expectations with stakeholders regarding scope and deliverables must be defined and
agreed. Ensuring that they understand what they will get at the end of the project.
4. Pilot implementations should cover all units concerned as requirement for each unit are different.
5. Key personnel from each unit must be identified to represent his unit for all matters relating to the
project. He should coordinate resources within his unit for testing, feedback, etc.
6. Project manager or a project team should be formed to act as bridge to ensure that all parties
understand their roles and responsibilities, control and manage expectations, monitor progress
and ensure deliverables are met.
15. Novopay
Payroll system
Ministry of Education - New Zealand
Project type : Payroll system
Project name : Novopay
Date : Sep 2012 – May 2013
16. 3- Novopay Project
• Novopay is a web-based payroll system for state and state integrated schools in New
Zealand, processing the pay of 110,000 teaching and support staff at 2,457 schools.
• It was purchased by the New Zealand Ministry of
Education for $182 million over 10 years, and was
implemented in August 2012 after seven years of
planning and development by Talent2 company.
• From the outset, the system led to widespread
problems with over 8,000 teachers receiving the wrong
pay and in some cases no pay at all within a few months,
90% of schools were affected.
• The 'Novopay debacle' as it was called received almost daily media attention, causing
embarrassment for the new Minister of Education Hekia Parata, and contributed to the
resignation of newly recruited Education secretary Leslie Longstone.
17. Reasons behind Novopay Project failure
7. Requirements problems and poor system design
A. Usability issues,
B. Failure to establish appropriately robust data validation steps to ensure the quality of data input into the system
C. Poorly designed reports that inhibited management oversight of the system’s use).
8. Have an ambitious project scope the more ambitious the better
9. Failure of quality control tests (failure to identify data corruption issues and logic flaws).
10. Implementing the system with a high number of unresolved defects.
11. Lack of control over manual intervention processes used when problems were encountered.
12. Change technical specifications during the project
18. Reasons behind Novopay Project failure
7. Develop long and complex contract and assume this will solve problems that arise (and they will) .
8. Rely on the advice and skills of salespeople and contract and use lots of consultants rather than develop in
house IT expertise.
9. Ensure as many different consultants are involved so knowledge is fragmented.
10. Ensure project has a long development time-frame so technology becomes
outdated and the likelihood of organizational changes increases.
11. Believe everything you're told about the progress of the project and assume bugs will be ironed out once
project is live.
12. Look for indication of forthcoming failure, do not terminate project. Instead rely on promised IT fixes,
more process and more monitoring.
13. Continue throwing money at the project
19. Challenges & Recommendations for IS strategists
1. Organization should ensure that they form a team of technical experts such as system analysts,
database architect, etc., to represent them on system design and to check what was developed by
the vendor.
2. System design should be more thorough and as detailed as possible.
3. Detailed test plans and test cases for all functionality must to produced and a test team should be
set up to perform the tests and provide quality feedback
4. A comprehensive reporting tool should be included in the scope and detailed requirement defined.
5. Part of the system design include security measures regarding manual data input. At least a 2nd
level check and approval should be included as mandatory for all manual data updates. A report
should be generated to show these changes for any appropriate actions.
20. Conclusion
Based on above Projects, the whole reasons of project fail mainly because of two reasons:
Either A failure of estimation and
Or A failure of implementation
In order to ensure system success, there are several factors to keep in mind:
1. Don’t cut corners, methodologically. In the long run, this results in system
failure or an inadequate system that doesn’t meet the users’ needs.
2. Audit each major deliverable and step along the way for accuracy and correctness.
3. Carefully monitor top management support for the project. Make sure that managers are aware of the
progress of the team.
4. Secure the correct technical lead for the project.
There is no free lunch in software engineering. If we insist on keeping costs low and hurrying the project along,
then quality will be low or the risk of failure will be high no matter how well the project is managed.
21. References
1. “e-Borders”, Wikipedia: http://en.wikipedia.org/wiki/E-Borders
2. "E-borders to be 'genuinely secure”. BBC. 14 March 2012. Retrieved 2012-04-15.
3. "New fears over immigration controls as government sacks e-Borders system supplier". The Daily Mail, James Slack (22 July 2010),
4. “Home Office ordered to pay £224m to e-Borders firm”, http://www.bbc.co.uk/news/uk-28840966
5. “British Home Office”, http://calleam.com/WTPF/?p=6773 , Why Projects Fail blog, Aug 18th, 2014
6. "Government IT projects fail because of politicians, not programmers", By: Willard Foxton, August 19th, 2014
7. Online Article: “Avon's Failed SAP Implementation A Perfect Example Of The Enterprise IT Revolution”, By: Ben Kepes, Forbes
12/17/2013 http://www.forbes.com/sites/benkepes/2013/12/17/avons-failed-sap-implementation-a-perfect-example-of-enterprise-it-
revolution, Accessed in 27/04/2014
8. Online Article: “Avon to SAP: We can’t put enough lipstick on this pig! – A failure in program risk management”, By: John Belden,
Upper edge Blog, Dec 13, 2013, URL: http://www.upperedge.com/2013/12/avon-to-sap-we-cant-put-enough-lipstick-on-this-pig-a-failure-
in-program-risk-management, Accessed in 27/04/2014
9. Online Article: “Inside Avon's Failed Order-Management Project”, By:Doug Henschen, InformationWeek , 12/16/2013, URL:
http://www.informationweek.com/software/information-management/inside-avons-failed-order-management-project/d/d-id/
1113100, Accessed in 27/04/2014
10. "Top 10 Reasons Why Systems Projects Fail", By: Dr. Paul Dorsey, Dulcian, Inc., 26/04/2005
11. "Eight ways Novopay failed", By: Professor Robin Gauld & Ministry of Education, March 19, 2013
12. "New Zealand Ministry of Education", Calleam Consulting Ltd. - Why Projects Fail, May 28th, 2013
http://calleam.com/WTPF/?p=5835
13. Wikipedia: "Novopay"