Presentation on theme: "Why Projects Fail… and what you can do about it …."— Presentation transcript:
Why Projects Fail… and what you can do about it …
Warnings: This topic we are about to cover may be somewhere deadly serious, but we try not to be!!! If anyone feel bored during this training session, tell us, we will make it faster.
Abstract To understand the general idea about the reason why IS projects fail How does a project be successful? ---- Critical Success Factors IS project failure happens at any fields ----3 Case Study Analysis Solution to improve project management process. 1 2 3 4
Introduction What is project failure… The project costs a lot more than estimated. It takes much longer than everyone expected. The product fails to do what it was supposed to. Nobody is happy about it. So….Who’s fault? Software System Project manager
Project Outcomes Data Source: The Standish Chaos Report, 2009 “Around 2009, the year’s project management statistics show results that in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions. 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”
Critical Success Factor Management of The Implementation Process Formal methodology and reliable estimates Experienced project manager Level of Complexity/Risk Project SizeProject StructureExperience with technology Senior Management Support Users Involvement
Three constraints Quality Cost Time Project manager use IS to meet three key elements: Identify requirements, Allocate budget Keep timing constraints (Bocij, 2006)
Constraints Matrix QualityTimeCost Least Flexible Moderately Flexible Most Flexible (Jeff, 2009)
Categories of Project Failure Correspondence failure Interaction failure Process failure Expectation failure Failure to meet the objectives originally specified for the system The system is not developed within time and budget constraints, or the system is never implemented Poor usage of IS by users (the system itself meets the technique specification) ‘Inability’ of an information system to meet a specific stakeholder group’s expectations’ (Lyytinen & Hirschheim, 1987)
Cost overruns Poor planning and cost estimation Poor monitor on time delivering and poor communication New technology and poor testing Poor decision- making, Scope creep Time slippage Technical shortfalls Forecasted benefits
-Goals not all achieved -Complex Solutions -Lack of Planning -Lack of User Involvement -Lack of Resources -Lack of Commitment -Unrealistic Expectations -Lack of Executive Support -Changing requirements and specifications -Schedule overrun -Budget overrun -Poor leadership and management -Debugging incomplete -Lack of ownership -Too many vested interests Level of Failure -Profitability -Poor Estimates -Unproven Tech. -Lack of Res. -Lack of Features -Lack of Usability -Lack of Project organization -Transparency in IS Project -Progress Meetings -Scrapped Before Completion -Vendor’s Inability to meet requirements -Client consultation during development stage. LEVEL ONE (MINOR) LEVEL TWO (MAJOR) LEVEL THREE (CRITICAL) (Bury, 2010)
Case study 1: Failure of Taurus in London stock exchange
Background A lot of transactions within a day, the paper trail was becoming unmanageable. In 1987 the antiquated paper driven system almost collapsed under the sheer volume of trades resulting from a rising market. UK development plans to develop an automated transaction settlement system for the London Stock exchange. Taurus Develop an automated transaction settlement system for the London Stock Exchange in 1998. Aim to create a simple system for large investment houses, which account for over 70% of the value of transactions on the London Stock Exchange. An 6-month time frame demanded by the securities industry for the completion of the Taurus project. Original budge is slightly above £6million Inefficient security market in 19 th century
Taurus Content Title Project Outcome Ending budget is £800 million, which is over 130 times of original one. Previous lose reported by financial times on 3th.Nov, 1993 is just 400 million. The project is completed nearly 12 years, over 11 years delay. Develop from several stakeholders to over thirty committees connected to the Taurus project all with their own vested interests.
Complexity of Taurus Structure of project creates a lack of cohesion and teamwork between interested parties Lacks of leadership and top management Cause of failure (Glotz, 1992)
Improvement Careful selection of the appropriate package Strong leadership Management expectations Project Team competence Dedicated resources Critical Success Factor (Chapman, 2004)
Case study 2: London Ambulance Service Area covers 620 square miles Largest Ambulance Service in the world Around 4,000 staff at over 70 stations Carries over 5,000 patients every day Receives 2,000-2,500 calls each day (Lond.Ambulance)
Gazetteer and mapping software system Communications interface (RIFS) Description of CAD Radio system -MDTs: Mobile Data Terminals in ambulances -AVLS: Automatic Vehicle Locating System Computer Aided Despatching System (Fitzgerald & Russo, 2005)
Outcomes of LAS IS Failure OUTCOMES The system could not cope with the load placed on it by normal use. The response to emergency calls was several hours; 20-30 people died as a result of ambulances arriving too late. Ambulance communications failed and ambulances were lost from the system. OVERLOAD RESPOND CRASH
Reasons of LAS IS Failure Project OrganisationInformation System The complexity of the system The frustration of the ambulance crews Communication and response time problems Poor project management Inexperience of the developers An over-ambitious project timetable Poor training
CSF Improvement Good project management: lowest cost should not be deciding factor etc Project management The project should be pre-test before put into practice Very relaxed project timetable & Training good, timely, and accurate. Very relaxed project timetable & Training good, timely, and accurate. (Ein & Segve, 1978)
CSF Improvement Develop the system more simpler and easier Information system The new system should be as close as possible to the functioning of the manual system The new system should be as close as possible to the functioning of the manual system Upgraded the ambulance fleet & make the crews’ job more comfortable Upgraded the ambulance fleet & make the crews’ job more comfortable
Case study 3: University Accounting System Failure Background Introduction University of Cambridge develop a computerized financial system, which bugs, and continues to be unstable, slow and complex in its first six weeks. Until now, CAPSA is still regarded as unreliable and fail to do what it is expected to do. The result of investigation proved that CAPSA cause much pain and inconvenience, which cost lots money, damage the integrity of the university’s financial processes and tension the relationship between academics and administration. (Rohde, 2001)
Causes of Failure The reasons of system failure include mainly governance and management Project manager changed several times Not prepare contingency plans Project delay Overspend Lack of planning of project infrastructure Causes Roles and responsibilities are not clearly defined (Laurie, 2003)
Project management Risk management Use of consultant Clear goal and objectives CSF Analysis Critical Success Factors
Common factors in three cases Pre-test of system Contingency plans People risk
What we can do about it… Sometimes, easy ways make your project success: Think well, know what you really want Trust your team, communicate frequently Review everything, test everything Say goodbye to complexity
References: Adamu, M. (2005). London Ambulance Service Software Failure. Bocij, e. a. (2006). Business Information System: Technology, Development and Management for the E-Business. America: Pearson Education Limited. Bury, M. (2010). Understanding Information Technology System Project Failure. Retrieved 2 28, 2012, from https://docs.google.com/viewer?a=v&q=cache:ZUflYANfHZIJ:www.kean.e du/~rmelworm/10/3040-04.s10/submittals/ITSFailure- MB.ppt+Understanding+Information+Technology+System+Project+Failure &hl=en&gl=uk&pid=bl&srcid=ADGEESiyo66tTcaztmPxFKIkfoTorTOSfqb sRgjSV_xRMF0 Chapman, J. (2004). System failure:Why governments must learn to think differently. Journal of Demos, pp. 47-48. Ein, P., & Segve, E. (1978). Organizational context and the success of management information systems. Management Science 24, 1064-1077. Fitzgerald, G., & Russo, N. (2005). The turnaround of the London Ambulance Service Computer-Aided Despatch system. European Journal of Information Systems, pp. 244-257.
Flowers, S. (1996). Software failure:management failure. Chichester: John Wiley and Sons. Glotz, S. (1992). A sequential learning analysis of decisions in organizations to escalate investments despite continuing costs or losses. Journal of Applied Behavioural Analysis, pp. 561-574. International, T. S. (2001). Standish Chaos Report:Extreme Chaos. The Standish Group International. Jeff. (2009). Truth about the Project Failure. Retrieved 2 25, 2012, from http://www.youtube.com/watch?v=-eb7-3W4npM Laudon, K., & Laudon, J. (2011). Management Information System: Managing The Digital Firm,12th edition. Canada: Pearson Education Limited. Laurie, J. (2003). Why Project Fail?-A University Accounting System Case Study. Newcastle: Northumbria University. Lond.Ambulance. (n.d.). CAD Failure LAS.1992. Retrieved 3 9, 2012, from Lond.Ambulance: http://www.lond.ambulance.freeuk.com/cad.html References:
Lyytinen, K., & Hirschheim, R. (1987). Information Systems Failure: A Survey and Classification of The Empirical Literature. Oxford: Oxford University Press. Rohde, L. (2001). Cambridge may sue Oracle,KPMG for failed system. London: IDG News Service. Stair, R. M., Reynolds, G., & Chesney, T. (2008). Fundamentals of business information system. London: Course Technology CENGAGE Learning. Stair, R. M., Reynolds, G., & Chesney, T. (2008). Principles of Business Information Systems. London: CENGAGE Learning. Wastell. (2011). Managers as designers in the public services: beyond technomagic. Axminster: Triarchy Press.