ThemeGallery PowerTemplate

Download Report

Transcript ThemeGallery PowerTemplate

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
1
To understand the general idea about the
reason why IS projects fail
How does a project be successful? ---Critical Success Factors
3
2
IS project failure happens at any fields
----3 Case Study Analysis
Solution to improve project management
process
.
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
60%
53%
53%
51%
50%
49%
46%
44%
40%
40%
34%
33%
32%
31%
30%
28%
26%
27%
Challenged
29%
28%
Successed
Failed
24%
23%
20%
18%
16%
15%
10%
0%
1994
1996
1998
2000
2002
2004
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
Users Involvement
Senior Management Support
Level of Complexity/Risk
Project Size
Project Structure
Experience with technology
Management of The Implementation Process
Formal methodology and reliable estimates
Experienced project manager
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
Quality
Time
Cost
Least Flexible
Moderately
Flexible
Most Flexible
(Jeff, 2009)
Categories of Project Failure
Correspondence failure
Failure to meet the
objectives originally
specified for the system
Interaction failure
Poor usage of IS by users (the
system itself meets the
technique specification)
Process failure
The system is not developed
within time and budget
constraints, or the system is
never implemented
Expectation failure
‘Inability’ of an information
system to meet a specific
stakeholder group’s
expectations’
(Lyytinen & Hirschheim, 1987)
Technical
shortfalls
Time slippage
Cost overruns
Poor planning
and cost
estimation
Poor monitor on
time delivering
and poor
communication
New technology
and poor testing
Forecasted
benefits
Poor decisionmaking, Scope
creep
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
LEVEL ONE
(MINOR)
-
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 TWO
(MAJOR)
-
Scrapped Before
Completion
Vendor’s Inability to
meet requirements
Client consultation
during development
stage.
LEVEL THREE
(CRITICAL)
(Bury, 2010)
Case study 1:
Failure of Taurus in London stock
exchange
Background
Taurus
Inefficient security
market in 19th century
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.
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
Taurus
Project Outcome
Content Title
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.
Cause of failure
Complexity of
Taurus
Structure of project
creates a lack of
cohesion and teamwork
between interested
parties
Lacks of
leadership and
top management
(Glotz, 1992)
Improvement
Strong
leadership
Careful selection
of the
appropriate
package
Dedicated
resources
Management
expectations
Critical
Success
Factor
Project
Team
competence
(Chapman, 2004)
Case study 2:
London Ambulance Service
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
Area covers 620 square miles
(Lond.Ambulance)
Computer Aided Despatching
System
Description of CAD
Gazetteer and mapping
software system
Communications
interface (RIFS)
Radio system
-MDTs: Mobile Data
Terminals in ambulances
-AVLS: Automatic
Vehicle Locating System
(Fitzgerald & Russo, 2005)
Outcomes of LAS IS Failure
The system could not
cope with the load
placed on it by normal
use.
OVERLOAD
OUTCOMES
The response to
emergency calls was
several hours; 20-30 RESPOND
people died as a
result of ambulances
arriving too late.
CRASH
Ambulance
communications
failed and
ambulances were
lost from the system.
Reasons of LAS IS Failure
Project Organisation
Information System
Poor project management
Inexperience of the
developers
An over-ambitious project
timetable
Poor training
The complexity of the
system
The frustration of the
ambulance crews
Communication and
response time problems
CSF Improvement
Good project management: lowest cost should not be deciding factor etc
The project should be pre-test before put into practice
Very relaxed project timetable &
Training good, timely, and accurate.
Project management
(Ein & Segve, 1978)
CSF Improvement
Develop the system more simpler and easier
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
Information system
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
Overspend
Roles and
responsibilities
are not clearly
defined
Lack of planning
of project
infrastructure
Project manager
changed several
times
Causes
Project delay
Not prepare
contingency
plans
(Laurie, 2003)
CSF Analysis
Project
management
Risk
management
Use of
consultant
Critical
Success
Factors
Clear goal and
objectives
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/ITSFailureMB.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.
References:
• 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.
L/O/G/O
Gala Group