“A Tutorial on Why Information Technology Projects Fail”
Ashton Hospodar
Amanda Trevisan
Permission:
"We, the undersigned give permission for posting our work to the web. We
have removed all personal identifiers from this manuscript, except for our
name. We give permission for others to create a derivative work from this
manuscript, as long as we remain an author of the derivative work and as
long as the order of authorship reflects each author's relative contribution.
In case of conflict, the course instructor makes the final choice of the order
of authorship."
Executive Summary:
Information technology (IT) is, “the study, design, development, implementation,
support and management of computer-based information systems, particularly software
application and computer hardware” (Information Technology, Wikipedia). Those
aspiring to improve the current way work is done must begin to implement the
capabilities of information technology to their design process. While proper management
of IT projects is crucial for organizations today, the failure rate of IT projects are
astounding.
There are many reasons for why IT projects fail. The two most popular reasons
for failure include poor project planning, as well as a lack of managerial involvement and
support. Project failure can be very detrimental to an organization and team. This paper
outlines the most common reasons for project failure.
However, sometimes project failure is inescapable. If an ongoing project must be
ended, damage control becomes very important. What to do if project failure is inevitable
is also illustrated in this paper.
Introduction:
As defined by the Information Technology Association of America (ITAA),
information technology (IT) is “the study, design, development, implementation, support
and management of computer-based information systems, particularly software
application and computer hardware,” (Information Technology, Wikipedia). The use of
computers and computer software to convert, store, protect, process, transmit and
securely retrieve information are all actives encompassed in the term information
technology. Today, the term is more recognizable then ever before. The umbrella
covering IT can be quite extensive and cover a wide range of fields. IT professionals
perform many duties including data management, networking, engineering computer
hardware, database and software design, as well as the management and administration of
entire systems. This tutorial is geared towards IT professionals dealing with the
management and administration of entire systems.
Those aspiring to improve the current way work is conducted must begin to
implement the capabilities of information technology to their design process. Standard
business process design and information technology are natural partners, yet managers
and companies have never fully exploited their relationship. Information technology
offers the potential for substantial improvements, however proper management of
projects is crucial for success.
The failure rate of IT projects is astounding. Brenda Whittaker defines project
failure in three ways: “overrunning its budget by 30% or more, overrunning its schedule
by 30% or more, or failing to demonstrate the planned benefits.” The 1995 Chaos Report
found that more than half the projects cost an average of 189 % of their original estimates
and 31% of software projects will be cancelled before completion at an estimated
combined cost of $81 billion. For example 60% of the failed projects were planned to
take less than one year to complete and exceeded this time frame (Whittaker, 1999). The
use of new and unproven technology along with poor estimations and weak definitions of
requirements at the project planning stage also lead to failure. With the 250 billion spent
each year in the USA on IT application development, wee see that the cost of failures and
overruns is staggering (Chaos Report, 1995). Because of these staggering numbers, the
software industry is often categorized as in a state of crisis (Ewusi-Mensah, 1997).
In order to best manage IT projects it is important to look at the causes of project
failure. We are forced to look at what exactly it is about IT projects that make them so
susceptible to huge fiascoes. A survey questionnaire distributed in April 1997 was sent to
Canada’s leading 1,450 public and private sector organizations focusing on IT project
management issues. The 1997 Survey of Unsuccessful Information Technology Projects
by KPMG Consulting established that more common reasons projects fail are because of
poor project planning, a weak business case, and lack of top management involvement
and support (Whittaker, 1999).
Difficulties and failures of IT projects also have issues associated with
organizational and human factors. A review of detailed case accounts will improve
knowledge among healthcare organizations and the finest implementation practices.
Currently there is little web-based information on “lessons learned” by others in their
own attempt for IT planning. The increasing push for Electronic Medical records (EMR)
would benefit greatly through sharing knowledge via the web on project difficulties,
design and implementation. Filling the information gap on IT project management should
be an essential goal of the health care community.
This tutorial outlines the crucial reasons behind the failure of information
technology projects in an effort to minimize the risk of future failures. Learning from past
mistakes allows us to improve project management techniques and avoid IT failures,
which greatly affect an organization.
(Kringsman, 2008)
Step-by-Step Guide: Why Information Technology Projects Fail
As it is easy to see from above, most information technology projects are likely to fail.
Below is a figure that outlines all the major reasons why projects tend to fail:
(Major Causes of Project Failure, 2008)
While there is no real step-by-step guide that leads to failure of a project, there are many
factors that contribute. The six most common are undeveloped project goals, poor project
team composition, lack of project management and control, an inappropriate
technological base, no senior management involvement, and an overrun schedule and
budget.
1. Undeveloped Project Goals:
Poor project planning will almost always lead to failure (Whittaker, 1999). One
main reason for this failure is the inability to agree on the missions, goals, or objectives
that the project is attempting to undertake (Ewusi-Mensah, 1997). It is necessary that
specific plans and requirements for the project are instituted in the development phase.
Failure to do this will most likely result in “fragmented efforts” and a “lack of team
focus” for the duration of the project. It is equally important to make sure that the chosen
goals and objectives are within reach of the project and team (Ewusi- Mensah, 1997). If
the intricacy or the effort that will go into the project are misunderstood, the chances for
failure certainly increase (Silverstein, 2007).
2. Poor Project Team Composition
A weak project team is a set up for failure. It is important to make sure there are
no problems between team members, and if problems arise, that the team will deal with
them accordingly in a timely manner. It is also important to make sure that each member
of the team is appropriate for the project, meaning that they understand how to do the
work and are technologically able to do so (Ewusi- Mensah, 1997). The team needs to
constantly remain organized and always be in communication with each other.
Differences between team members will give the opportunity for varying viewpoints,
which could be significant to the project. However, if communication between these team
members is not up to par, they will not be able to share their ideas and therefore the
project may suffer (Ewusi-Mensah, 1997).
3. Lack of Project Management and Control
Project failure will automatically occur if the project is not managed properly.
This not only involves poor leadership skills on the side of manager, but also includes
poor control methods for the project. Poor methods of control mean that there is no
system to measure progress or identify risks (Ewusi-Mensah, 1997). Project managers
must make sure that no team member is in the “wrong” position or doing a job for which
they are not suited. It is also important for project managers to know their responsibilities
and freedoms and act accordingly. Project managers, like the project team, must not only
be involved but must also be competent and sure of what they are doing (Silverstein,
2007).
4. Inappropriate Technology Base
If the organization or company is unequipped with the necessary technology to
complete the project, it will be almost impossible to succeed. This also means having a
staff that is equipped with the skills to use that technology, which sometimes gets
overlooked if the technology is new to the company (Ewusi-Mensah, 1997). Projects not
only fail due to outdated technology, but also because they use new technology that not
everyone is caught up on. Technology can also affect a project if learning to use it takes
longer then planned (Whittaker, 1999).
5. No Senior Management Involvement
The involvement of the senior management is just as important as the direction
the project team receives from the project manager. The senior management must be
involved in monitoring progress and making critical decisions through out the course of
the project. It is key that the job they are supposed to perform is not pushed onto project
managers or technical experts. Senior managers should hold review meetings so they are
up to date on everything and nothing is overlooked. Another possible problem that could
occur if senior managers are not involved is that there may be a concealment of
information or problems that they need to know about (Ewusi-Mensah, 1997).
6. Escalating Project Cost and Time of Completion
The Association for Computing Machinery once said “It is common knowledge in
the computer industry that projects are still over budget and behind schedule in far more
cases than information system professionals and management find acceptable” (EwusiMensah, 1997). Cases of projects where the cost and the time of completion skyrocket
almost always need to be canceled. However, both of these reasons for failure are almost
always due to deeper problems that lay in the projects history (Ewusi-Mensah, 1997).
While research has shown has that schedule overruns often lead to failure more often then
budget overruns, maintaining both are key to a successful project (Whittaker, 1999). The
following graph illustrates this point by showing the highest percentage of failed projects
as overrunning schedule and overrunning budget.
(Whittaker, 1999)
Minimizing Damage: What to do if a Project must be Cancelled
It is obvious that information technology projects fail for many different and
varied reasons. However, once a project has failed, there are steps to take in order to
reduce any further damage to the company, organization, and team. The first thing that
should be done when a project fails is to thoughtfully communicate the failure to the
entire project team. This needs to be done in a caring and respectful manner instead of a
in a harsh or angry tone. If the failure is communicated properly, the damage to the
morale of the team will be minimal, therefore giving them more hope in future projects
(Ewusi-Mensah, 1997).
Another way to reduce harm once a project has failed is to examine why the
failure occurred. Determining what went wrong should be done immediately so that no
important information is forgotten. Understanding the underlying causes of failure and
reporting them will help everyone involved in the project be more prepared in the future.
Breaking the current “code of silence” that surrounds many project failures would also be
helpful in reducing damage. If a company could report to the whole industry when, why,
and how a project failed, people could learn from the mistakes and information
technology projects could succeed much more often (Ewusi-Mensah, 1997).
Case Study: The California DMV in 1987
In 1987, the California Department of Motor Vehicles (DMV) embarked on a
project that they hoped would revamp their driver’s licenses and registration application
process. Although this may not sound very difficult to do, it was an information
technology project and therefore needed to be planned for as one. However, since the
DMV did not have any adequate resources or management, this IT project was disasterprone from the start (The Chaos Report, 1995).
This IT project was initially designed to update drivers licenses and registration
processes, redesign the DMV’s databases to make them more efficient, and prepare the
new systems for future changes (Bureau of State Audits, 1994). However, since the
project was not planned for appropriately, tremendous failure resulted. The main cause of
failure was reported to be the lack of planning that went into this project. In a report later
published by the California State Auditor, the DMV reported that they “progressed
beyond the developmental stages…rather than completing each stage as planned, the
DMV substantially modified the stages or failed to complete them altogether” (Bureau of
State Audits, 1994). The members of this team clearly did not follow their original plan,
and had not accounted for any changes that would need to be made if deemed necessary.
Instead of returning to the original scope, they continued on without completing
important phases of the project.
Another reason for the failure of California’s DMV re-development included that
it was not supported by the senior management or the state’s information management
staff. Other team members cited poor user involvement, poor design specifications, and
unclear objectives as a major reason the project failed. In 1993, the project was officially
cancelled, after $45 million dollars had already been spent on it. (The Chaos Report,
1995). Below is a figure that shows the success criteria for information technology
projects, along with the highest number of points available in comparison to the
California DMV case:
(The Chaos Report, 1995)
Conclusion
Although the failure of information technology projects is at an all time high, there are
ways to prevent their demise. One way of making your project more successful is
referring to reasons why projects have failed in the past. Appropriate planning,
management, and realistic goals will all help a project succeed. IT is a very important
field, and its projects have the potential for numerous benefits if they are handled
appropriately.
References:
Ewusi-Mensah, Kweku. "Critical Issues in Abondoned Information Systems
Development Projects." Communications of the ACM 40 (1997): 74-80. Google
Scholar. Washington DC. 11 Mar. 2008.
"Failure Rate." Statistics Over IT Failure Rate. IT Cortex. 1 Apr. 2008 <http://www.itcortex.com/Stat_Failure_Rate.htm>.
Heathfield, Heather, David Pitty, and Rudolph Hanka. "Evaluating Information
Technology in Health Care: Barriers and Challenges." British Medical Journal
316 (1998): 1959-1961. PubMed. Washingtin DC. 11 Mar. 2008.
"Information Technology." Wikipedia. 22 Apr. 2008. 10 Mar. 2008
<http://en.wikipedia.org/wiki/Information_Technology>.
Kringsman, Michael. One Year in an IT Project. 1 Apr. 2008
<http://images.google.com/imgres?imgurl=http://geekandpoke.typepad.com/geek
andpoke/images/2007/10/02/day0031.jpg&imgrefurl=http://geekandpoke.typepad
.com/geekandpoke/2007/10/&h=338&w=480&sz=146&hl=en&start=4&tbnid=dI
Yt5VLoztrEUM:&tbnh=91&tbnw=129&prev=/images%3Fq%3Dcartoons%2Bfo
r%2BIT%2Bproject%2Bfailure%26hl%3Den%26lr%3D%26safe%3Doff%26sa%
3DG>.
Major Causes of Project Failure. 1 Apr. 2008 <http://www.itcortex.com/images/Failure_Cause_Survey.264.gif>.
Rahanu, Harjinder, Jennifer Davies, and Simon Rogerson. "Failed IS Projects: Definition
in Terms of a Neglect of Professional Ethics." Failure & Lessons Learned in
Information and Technology Management 3 (1999): 1-22. Google Scholar.
Washington DC. 10 Mar. 2008. Keyword: Failure in Technology Management.
Silverstien, Scott M. "Why Healthcare IT Projects "Go Bad"" Drexel University. 2007.
Drexel University. 1 Apr. 2008
<http://www.ischool.drexel.edu/faculty/ssilverstein/failurecases/>.
States Financial Risk in the Database Redevelopment Project. California State Auditor/
Bureau of State Audits. California, 1994. 22 Apr. 2008
<http://www.bsa.ca.gov/reports/summary.php?id=27>.
The Chaos Report. The Standish Group. 1995. 22 Apr. 2008
<http://www.educause.edu/ir/library/pdf/NCP08083B.pdf>.
Wittaker, Brenda. What Went Wrong? Unsuccessful Information Technology Projects.
Information Management & Computer Security. MCB Univeristy P, 1999. 23-29.
11 Mar. 2008
<http://www.emeraldinsight.com/Insight/ViewContentServlet?Filename=Publishe
d/EmeraldFullTextArticle/Pdf/0460070102.pdf>.
Yeo, K.t. "Critical Failure Factors in Information System Projects." International Journal
of Project Management (2002): 241-246. Google Scholar. Washington DC. 11
Mar. 2008. Keyword: IT failures.
Index of terms:
Computer software- Computer software is a general term used to describe a collection of
computer programs, procedures and documentation that perform some tasks on a
computer system. The term includes application software such as word processors which
perform productive tasks for users, system software such as operating systems, which
interface with hardware to provide the necessary services for application software, and
middleware which controls and co-ordinates distributed systems.
Wordreference.com: WordNet® 2.0. Princeton University, Princeton, NJ.
Retrieved on 2007-08-19.
Data management- Data analysis is the process of looking at and summarizing data with
the intent to extract useful information and develop conclusions.
http://en.wikipedia.org/wiki/Data_analysis
Management- Management in simple terms means the act of getting people together to
accomplish desired goals. Management comprises planning, organizing, resourcing,
leading or directing, and controlling an organization (a group of one or more people or
entities) or effort for the purpose of accomplishing a goal. Resourcing encompasses the
deployment and manipulation of human resources, financial resources, technological
resources, and natural resources.
Management can also refer to the person or people who perform the act(s) of
management.
http://en.wikipedia.org/wiki/Management
Software design- Software design is a process of problem-solving and planning for a
software solution. After the purpose and specifications of software is determined,
software developers will design or employ designers to develop a plan for a solution. It
includes low-level component and algorithm implementation issues as well as the
architectural view.
http://en.wikipedia.org/wiki/Software_design
Peer Reviews:
From Maura McGroarty;
1. Circulate your paper to at least one other person (preferably someone
writing on the same topic) and offer to review their work as well. Every
member of the team must do a separate review. Send your review to the
instructor as well as all of the authors of the draft paper. Use the following
rubric to organize your response (make comments for each of the sections
indicated):
2. Dates: April 2, 2008 received and April 2, 2008 reviewed
3. Presentation:
a. Begin with what worked well. Point to specific sections of the paper
and use adjectives liberally to praise the authors. This is the only
place you are allowed to use adjectives, in all other sections avoid
use of adjectives.
The introduction is very descriptive; I like that everything is clearly
defined; even though I know what IT is, the explanation is very
precise and easy to understand for those unfamiliar with the
concept. The step-by-step guide is very informative I feel that the
guide covers every reason as to why a project would fail.
b. Discuss whether each major point has been made with an
appropriate visual aid.
The visual aids help to clearly identify what they are discussing in
their step-by-step guide. I really like them!
c. Discuss the use of font size to mark paper sections and the
hierarchy of ideas
 The font size emphasized the headers and then the subtext was
smaller but clearly visible.
d. Discuss if color has been used appropriately to highlight significant
points
 The points are in bold which is black; I think color would distract
from this paper
e. Discuss writing style and errors
 I like the writing style because it’s clear and concise
f. Discuss the organization of the paper.
 The paper is organized with the most important parts first in a
step-by-step format; which is easy to follow
g. Discuss if references are linked to PubMed and other literature.
 Yes, they used many different references, which appear to be
very reliable
4. Content:
a. Begin with what worked well. Point to specific content that made
reading the paper worthwhile. You can use adjectives in this
section to praise the authors but do not use any adjectives in
remaining sections.
 The introduction was probably my favorite part of the paper. I
describe exactly what they plan on doing in their paper and clearly
define specific points of their paper. I like the content on senior
management because I personally never thought of lack of senior
management would make an organization fail.
b. Discuss if the authors have followed the recommended outline and
whether their departures from the outline make sense.
 Yes they have followed the outline recommended and everything
in the paper makes sense and is clear. The outline constructed this
paper into a very well thought out tutorial.
c. Check that the title is appropriate for the paper. Make sure that the
paper does not digress into unrelated materials.
 The title is perfect! It’s describes exactly what the paper is going
to be about
d. Discuss the use of reference materials. Make sure that there are
no claims made that are not backed up by evidence from the
literature.
- Everything was cited correctly and all evidence was backed up with
citation-no false claims were made in this paper which added to how
strong of a tutorial this is.
e. Discuss whether the paper provides sufficient depth to serve as a
tutorial for you or for someone not familiar with the topic. What
could make the paper more useful?
 I think the paper is great for someone unfamiliar in the subject
area. Since everything is clearly defined, there is no confusion and
it is easy to follow the step-by-step guide. The visuals also help to
provide even more depth to this paper.
f. List what questions you had that were not answered by the paper.
 What about a project failing because of communication issues? I
think discussing communication issues would make this tutorial
even stronger.
5. What you learned:
a. Discuss what you learned from the paper that you would try to do in
your own draft. If the topic is new to you, discuss what surprised
you.
 I learned that simplicity makes a big impact, while they did discuss
in detail each step; I feel they didn’t ramble on which can lead a
student to become confused. They were very concise and I will need to
work on cutting out “the fat” of my paper, as in cutting out the
unnecessary wording
6. Grade
7. Do not give a grade
From Jaime Gloria:
o
Dates

o
o
Report the date you received the draft and the date you responded to the draft
The date I received the draft was April 2, 2008 and the response was
delivered April 2, 2008.
Presentation:
 Begin with what worked well. Point to specific sections of the paper and use
adjectives liberally to praise the authors. This is the only place you are allowed
to use adjectives, in all other sections avoid use of adjectives. I think your step
by step guide breakdown is very well organized and very effective broken
the way it is. I would just confirm it does not have to be an essay format.
List of terms also seems effective and referencing to the exact definition of
IT is also very helpful.
 Discuss whether each major point has been made with an appropriate visual aid.
Visual aids are reflective of respective text.
 Discuss the use of font size to mark paper sections and the hierarchy of ideas All
of these are used effectively to the point where they still make a
professional presentation. Ideas are arranged in an order that makes
sense and allows for building up of points made earlier in the text.
 Discuss if color has been used appropriately to highlight significant points Color
is used to highlight points and terms
 Discuss writing style and errors I do not feel comfortable commenting in this
section because style has always been a weakness for me. The paper does
make sense though and I did not pickup on any grammatical errors, except
for an extra e on the word we, which was fixed.
 Discuss the organization of the paper. Paper organization seems well thought
through. Ideas flow clearly and concisely. Details within paragraphs all
seem aligned with the main idea of its respective paragraph.
 Discuss if references are linked to PubMed and other literature. They are and
the literature is respective of the topic.
Content:
 Begin with what worked well. Point to specific content that made reading the
paper worthwhile. You can use adjectives in this section to praise the authors
but do not use any adjectives in remaining sections. Personal testimonies on
why projects fail are very effective. Breaking down each step and the
elaboration of each step is also greatly appreciated. The introduction is
also thorough and the signed permission seems very professional.
 Discuss if the authors have followed the recommended outline and whether their
departures from the outline make sense. They did follow the outlines, and I
think them doing so therefore reflects why the paper is so clear.
 Check that the title is appropriate for the paper. Make sure that the paper does
not digress into unrelated materials. Title is appropriate.
 Discuss the use of reference materials. Make sure that there are no claims
made that are not backed up by evidence from the literature. Work cited can be
matched to in text references.
 Discuss whether the paper provides sufficient depth to serve as a tutorial for you
or for someone not familiar with the topic. What could make the paper more
useful? The paper is sufficient. If anything, I would present the tutorial in a
PowerPoint or more interactive format because a paper can only do so
much. The assignment though is a paper, so considering a PP is not an
option, the tutorial is perfect as is.
 List what questions you had that were not answered by the paper. None
o
What you learned:
 Discuss what you learned from the paper that you would try to do in your own
draft. If the topic is new to you, discuss what surprised you. I learned the
reasons why projects fail as well as more proper terminology for when
talking about IT. What surprised me were the statistics of how many
projects failed, and the need for upper management to be involved in the
project. I always assumed that tasks force were the only ones involved.