JOURNAL OF MANAGERIAL ISSUES

Vol. XXX Number 3 Fall 2018

Strategies for Handling Failures in Development of

Information Systems

Terri Lenora Guidiy

Assistant Professor o f Management
W inthrop University
gnid 1 7 t@ w inthrop.edu

Brittany Brown Halligan

Senior Account Service Coordinator
Aflac Inc. - Columbia, SC
[email protected]

Cara Peters
Professor of Marketing
Winthrop University
[email protected]

Rapid obsolescence of technology and innovation create a constant need for new or
improved information systems. Systems development is defined by Laudon and Laudon
(2014) as the activities that go into producing an information systems solution to an
organizational problem. It includes all aspects of the process, from problem
identification to implementation of the system and ongoing maintenance. Creating a
new or modifying an organization’s information system is an expensive endeavor.
According to Stair and Reynolds (2015), annual expenditures on information
technology will increase from $3.8 trillion in 2014 to $4.4 trillion by 2018.
Many organizations now use enterprise-wide information systems, which integrate
functions across departments, processes, and industries (Ravasan and Mansouri, 2014).
Enterprise-wide systems have become so complex and interconnected that they present
a high chance of failure. Managers may want to consider them as works in progress
throughout their life cycle. In fact, as shown in Table 1, the final phase of the Systems
Development Life Cycle includes maintenance of the system. The complexity of

JOURNAL OF MANAGERIAL ISSUES VOL. XXX NUMBER 3 Fall 2018

( 363)
364 H a n d lin g I nform ation S ystem D ev elo pm ent F a ilu re

information systems and a lifetime of maintenance add to the increasing annual

expenditures noted by Stair and Reynolds (2015).
Annually, billions of dollars are lost on failed information systems projects. The
Standish Group International (2013) tracks the success rate of projects and their data
shows that over time, 39% of information systems projects have “succeeded,” while 43%
are “challenged” in that they are late, substantially over budget, or deliver only part of
the planned functions and features, and 18% have “failed” completely (i.e., were
cancelled or not usable). Taken together, these statistics translate into a 61% failure rate
for information systems projects. Furthermore, research has shown that 17% of all large
information technology projects fail so miserably that they threaten the very existence
of the organization (Bloch et al., 2012). According to Flowers (1996), an information
system is considered a failure if any one of the following factors is present: the system
does not operate as expected and performance is less than optimal; the system does not
perform as intended or is rejected by users; the cost of development exceeds benefits of
the system or, the system is abandoned before it is complete. One must also consider
that there may be many failed projects that are not publicly reported, so failure rate
statistics may be even higher than published estimates. Many companies choose not to
report failures for fear of loss of respect or trust from the public (Schillings, 2015), and
a high project failure rate leads to a loss of confidence in information systems by
companies and their employees.
The success of IS projects and prevention of failure of projects in systems
development and implementation are improving (McManus, 2014). As the methods,
tools, and training have become more advanced, success rates have increased and will
most likely continue to do so. Many published articles and books focus on improvement
of success rates using project management and various development methods, such as
the agile or waterfall implementation methods. A few examples include: Running an
Agile Software Development Project (Holcomb, 2008), Teaching Information Systems
Development via Process Variants (Tan and Tan, 2010), A Project Management Perspective of
Information Systems Development (McManus, 2014), and Scrum Project Management (Pries
and Quigley, 2010).
Success rates can be improved with monitored testing throughout the development
cycle (Poston et al., 2014). However, even when using the best of methods, there are
times when failure is imminent. At some point, when systems seem to be making little
or no progress, the project manager may question whether the organization should
continue on a path that is clearly leading to failure. And yet, there is little to no research
available on strategies to handle the failure of an information systems development
project. The purpose of this paper is to identify the possible paths that a manager could
take when faced with a failing information systems project with emphasis on projects
outsourced to a private vendor. A review of literature is presented below.

LITERATURE REVIEW

Data and knowledge are two of the most important assets to a business (Weinberger,
2013). As explained by Valacich and Schneider (2012; 226), business intelligence, the
use of information systems to gather and analyze information, is an integral part of an
organization. Often the terms information systems (IS) and information technology (IT)
are used interchangeably. Although they are closely related, they are not the same.

JOURNAL OF MANAGERIAL ISSUES Vol.XXX N umber 3 F all 2018

 G u id r y , H alligan , and P eters 365

Information technology refers to all technologies that collectively facilitate construction

and maintenance of information systems (Oz, 2006). An information system is an
interrelated group of components working together to collect, process, store, and
disseminate information to support decision-making in an organization (Laudon and
Laudon, 2014). Information systems have become a necessary tool for existence in
organizations. In some instances, organizations must adapt to a group of technologies
to survive in an industry. Carr (2003) notes that information technology is quickly
becoming commoditized. C an’s (2003) work suggests that information systems will
become a necessary commodity to businesses, similar to electricity that is required to
keep businesses running.
A number of different methodologies may be used when working on developing a
new information system. Experienced systems analysts often prefer to use a combination
of several development methods. The Systems Development Life Cycle (SDLC), as
shown in Table 1, is one commonly used method. It is a conceptual model that describes
the phases involved in developing an information system. Other commonly used
methods include rapid application development (RAD), joint application development
(JAD), and the spiral model.

Table 1
Systems Development Life Cycle by Valacich and Schneider (2012)
Phase Common Tasks
Systems Planning The goal of the planning and selection phase is to
and Selection identify, plan, and select a development project from all
possible projects. Some organizations have formal
information systems planning processes whereby a
senior manager, business group, or steering committee
identifies and assesses possible projects.
Systems Analysis One purpose of this phase is for designers to gain a
thorough understanding of an organization’s current
way of doing things in the area for which the system will
be developed. They may gain information through the
use of interviews, questionnaires, observations, and
document analysis.
Systems Design During this phase, the details of the chosen approach
are elaborated. The elements which must be designed
include the human-computer interface, databases and
files, and the processing and logic.
Systems During implementation, software testing, conversion,
Implementation documentation, and training takes place. Many types of
and Operation documentation including user guides and training
manuals are developed. Ongoing support and
maintenance is then provided during operation of the
system.

JOURNAL OF MANAGERIAL ISSUES VOL.XXX NUMBER 3 FALL 2018

366 H an dlin g I nform ation S ystem D ev elo pm ent F a ilu re

In the SDLC, although the core activities are completed in sequential order, the
process is often iterative. Problems may arise during the development process, which
require a previous phase to be revisited. Regardless of the methodology used, proper
development, implementation, and management of the project throughout every phase
is imperative to success.
Furthermore, outsourcing part or all of the systems development process is
common. Research in 2015 and published by Computer Economics in 2016 shows that
since 2011, the percentage of organizations outsourcing application development has
remained steady, between 60% and 66%. Even in outsourced projects, an understanding
of the SDLC by all parties involved will result in a higher degree of management control.
Proper management of the outsourced relationship is the single most important factor
in the success of an outsourced project (Valacich and Schneider, 2012: 382). Although,
the focus of this paper is on outsourced projects, listed below are the various paths that
a manager can take to address the issue of any failed information system project.

STRATEGIES FOR HANDLING FAILED PROJECTS

The popular press has detailed several examples of failed information systems
projects and how the organization responded to the failure. For purposes of this
research, the authors reviewed articles from the academic and popular press over a two-
year period. In gathering and analyzing examples of organizations dealing with these
failed projects, four general strategies were identified: delay, redirect, reduce, or
dissolve. Each strategy, along with its advantages and disadvantages, is described below.
It is also important to note that these strategies are not mutually exclusive; there can be
overlap in that an organization may start with one strategy but eventually be forced to
shift to another strategy before the project is completed or terminated.

DELAY

A delay strategy is based on the idea that the problems will be resolved on their own
over time without changes to the current plan or with very minor adjustments.
Advantages of the delay strategy are that it allows time to investigate causes limiting the
success of the project and to respond. Additional time to review complaints about the
progress and to investigate whether the complaints are valid is a necessary component
of the delay strategy. Furthermore, the delay strategy may allow time for adjustments or
improvements to new technologies as well as allow time to complete more thorough
testing of the systems being developed.
In a case analysis, Guidry and Peters (2015) report that a company named Carolina
Ingredients began using hand-held scanning devices throughout the production facility
in 2012 to facilitate data entry and increase accuracy. The handheld devices were
expected to seamlessly track inventory from the time it was ordered through the
manufacturing process in real time. The system allowed the use of barcodes to track
inventory from the time it was received throughout the production process. This
reduced the need for manual data entry, lowered the consumption of resources, and
minimized the probability of errors. However, the system did not work as planned when
it was purchased. At the time of the initial installation, the software had just been
released and did not yet contain the module that allowed the scanner software to interact

JOURNAL OF MANAGERIAL ISSUES Vol.XXX N umber 3 Fall 2018

 G uidry , H alligan , and P eters 367

with the ERP system at Carolina Ingredients. The scanner system was installed with
plans to continue the implementation to other parts of the company as soon as the
module became available.
Approximately three months later, the module was delivered and installed at
Carolina Ingredients with the hope of allowing the scanner system to be integrated with
the ERP system. After installation, the module did not work as expected. Multiple
attempts at configuration were made but the scanner system still did not integrate with
the ERP system. Since the module was relatively new, the technical support providers
from the software vendor could not easily resolve the problem. The problems between
the two systems persisted over time. The leadership team at Carolina Ingredients
decided to stick with the current vendor and waited for the patch to be delivered.
Approximately six months after initial installation, the patch was installed and the
scanner system became fully functional. The delay strategy allowed time for the vendor
to develop the patch, which led to resolution of the problems.
In the event of negative media attention with a failed system, the delay strategy
allows time for the negative attention to “die down,” so to speak. In the popular press,
a delay strategy was often seen in cases of fraud or alleged criminal activity of the parties
involved. At times, a delay strategy is used by default as decision-making processes are
slowed by mismanagement, bureaucracy, or through litigation. Mismanagement may
cause the delay strategy to be used by default in the case of problems being overlooked
or even hidden.
An example of the delay strategy is seen in the CityTime project, which was
launched in 1998 by the City of New York. As explained by Chen and Rashbaum (2011),
it was a contracted agreement for development of a new information system to
modernize its timekeeping and payroll operations. With an initial budget of $63 million,
costs had reached nearly $700 million by 2011. In 2010, the City of New York Office of
the Comptroller completed an audit of the project from 2001 through 2010. The audit
showed the project had been mismanaged from its inception, resulting in significant
increases in cost and duration of the project. The audit also concluded there was no way
to quantify the effects of the mismanagement.
Recommendations of the audit included the Board validate a budget to ensure
future costs do not outweigh system benefits (Liu, 2010). The project did continue and
the system eventually became operational. Later, as reported by Raymond (2014),
charges were filed against eleven individuals and one corporation alleging the
defendants defrauded the city. Details of this case are summarized in U.S. v. Mazer et al.
(2013), with the U.S. District Court for the Southern District of New York, No. 11-121.
The CityTime project dearly shows another advantage of the delay strategy in that it
can lead to changes in policies or procedures that reduce the probability of a repeat
failure. In response to the problems from the CityTime system, the New York City
Council passed an ordinance mandating that any IT project exceeding budget by 10%
or more must be reported to the city council for review (Standish Group International,
2013).
Disadvantages of the delay strategy include mounting project development costs, as
well as, the opportunity costs of delaying alternative solutions. Some may perceive the
delay strategy as being unresponsive or not recognizing the problem. For example, this
was seen in the CityTime project as stated by Collins (2011) in the Huffington Post’s
article, “CityTime Crime is Mayor Bloomberg’s Shame.” Collins (2011) opines that the

JOURNAL OF MANAGERIAL ISSUES Vol . XXX N u m b e r s F all 2018

368 H a n d lin g I nform ation S ystem D ev elo pm ent F a ilu re

scandal “involved hundreds of millions of dollars stolen or wasted from beneath the
mayor’s slumbering nose.” Other disadvantages are the obvious delay of a working
system and increased dollars being spent on a failing system.
The delay strategy resulted in satisfactory resolution in the case of the
implementation of the State of Tennessee’s Project Edison. The project began in 2006,
with phased implementation beginning in September 2008. In August 2010, a letter
detailing problems with the system was sent by Comptroller of the Treasury, Justin P.
Wilson (2010) to Governor Phil Bredeson and the members of the Tennessee General
Assembly. The primary consequence of the problems was that die Tennessee
Comprehensive Annual Financial Report (CAFR) was late, missing the mandated
deadline by seven months. Problems with the system included a lack of proper testing,
inaccuracies in financial reporting, and inadequate training manuals.
Recommendations in the letter included using the knowledge gained from the
experience as well as encouraging agencies to create an atmosphere in which the system
will be successful and to devote appropriate resources toward that effort. In 2011, the
Edison project had been fully implemented and was nominated for an award with the
National Association of State Chief Information Officers (NAISCO). The nomination
states the project, named Edison, replaced more than 30 fragmented systems; one of
which had been in use for 35 years. The new system includes modules for human
resources, financials, and procurement functionalities. The Edison system enabled the
State of Tennessee to realize numerous benefits to employees, vendors, and the state.

REDIRECT

In cases where the cause of failure was due to a breakdown in communication

between the parties involved or apparent lack of skill, redirecting the tasks to a new
vendor or project team worked for many organizations. In use of the redirect strategy,
the current management of the project team and/or other members are replaced.
Alternative vendors may be contracted or parallel development efforts may be put in
place. This strategy is necessary' at times due to unforeseeable circumstances such as
changes in employment or illness. Other times it is useful where project teams
underperform. Advantages of this strategy include bringing in a team with a new, fresh
perspective toward the problem. Redirection may allow additional or different skill sets
to be added to the team. The culture or structure of the project team may be reorganized
during redirection, which could allow for more efficient use of the available skillsets.
One example of successful redirection was seen in the development of the
HealthCare.gov website. The Affordable Care Act allowed for an online marketplace,
HealthCare.gov, to be used by Americans to shop for and purchase healthcare policies
from an approved list of providers. The Department of Health and Human Sendees
initiated development of the website in December 2011 (Borchers et a l , 2014). The
system was to be developed in only 22 months, even though it was very complex (meant
to act as an interface, while accessing other databases and information systems). The site
was launched on October 1, 2013. In the first few days it was online, only a small fraction
of users could create an account or log in. As reported by Ford (2013), Millward Brown
Digital, a consulting firm, reports that only one percent of over 3.5 million people who
tried to register using the site were successful. Foster (2013) also researched the system
and reported that access times were slow, the site would freeze, and users reported

JOURNAL OF MANAGERIAL ISSUES VOL. XXX NUMBER 3 FALL 2 0 1 8

 G uidry , H alligan , and P eters 369

getting kicked out during registration. In late October of 2013, House Democrats could
not explain how long it would take to fix the problems (Rogers, 2013). When asked
about a timeline, Rep. Henry Waxman (D-California) stated there was no timeline.
One of the contracting teams working on correcting the problems of the
government’s website, was known as Marketplace Lite (MPL) and was comprised of
Silicon Valley developers who came from all over the United States to work as a team
and resolve this immense IT issue (Meyer, 2015). These developers spent months
rewriting HealthCare.gov functions in full, working as a startup within the government
and replacing contractor-made apps with ones costing one-fiftieth of the price. The MPL
team achieved three significant milestones while working together for 16 months. First,
it served as a crack team, which understood the infrastructure of the site and could
resolve small issues as they arose. Second, it built an insurance application, called App2,
which signed up new users in less than half the time of the original app. Finally, Meyer
reports, it replaced the website’s poorly functioning login system with a better (and much
less expensive) system of its own design. If determining MPL teams’ success, based on
outcome of their end product, the updated website was faster and cheaper than the
previous version. The new version reduced annual maintenance fees by roughly 85%.
By mid-January of 2014, the site had been improved and was capable of handling up to
83,000 visitors at once. The redirect strategy proved successful in this example.
In order to use a redirect strategy, several factors must be considered carefully and
managed properly. Knowledge management is a critical factor for success in redirecting
a project. An attempt to capture as much knowledge as possible from the exiting team
and/or members should be made. Identifying activities that have been completed during
the previous work and acquiring information about completed tasks is also important.
It requires distributing copies of all project documentation, diagrams, copies of
communications, and all source code to the new team. Information about the existing
infrastructure, such as capability, constraints, and current cost analysis, needs to be
provided to the new team.
The redirect strategy was also seen in the case of the U. S. Census Bureau’s attempt
at Field Data Collection Automation in 2001. As reported by Calleam Consulting (2015),
the census takes a snapshot of the population of the U. S. every ten years. In 2001, the
bureau decided to eliminate paper-based data collection and replace it with hand-held
devices. The project was to be developed in-house, but by 2004, the bureau realized the
project was more complex than the bureau was prepared to handle. In 2006, the
progress of a contracted vendor failed to provide results that would allow use of the new
system for the 2010 census. The failure of the project resulted in expenditures of $3
billion and reverting to the paper and pencil method.
Disadvantages of a redirect strategy include increased time for completion of the
project and redundancy of some tasks, both of which led to increased financial expenses.
Another concern is that, when adopting an information systems project from another
team, it takes some time for the new team to become familiar with the work done by the
prior group. As a new team begins some aspects of the project, there may be significant
time in which no progress is made, while the new team evaluates all available material
from the prior work. It may be necessary to repeat some tasks in order to verify
completeness or accuracy of the processes used. In addition, new relationships of the
team must be formed.

JO U R N A L O F M A N A G E R IA L IS S U E S VOL. XXX NUMBER 3 FALL 2018

370 H a n d lin g I nform ation S ystem D ev elo pm ent F a ilu re

REDUCE
As reported by The Standish Group International, larger projects are ten times
more likely to fail than smaller projects. Larger projects have a greater chance of being
over budget, running late, and missing key features (Standish Group International,
2013). Managing scope can be one of the most important aspects of project management
as even the addition of new, small features or tasks can have a significant impact. These
changes are referred to as “scope creep.” The changes are so small that they are unlikely
to affect the overall project but as they accumulate, they can have a significant impact
on development of the overall project. Each project should be broken down into smaller
projects, or modules, that produce a concrete and usable product, not just milestones or
phases of the large project. Metrics should be developed to use throughout the
remainder of the project to measure value and cost at significant milestones before
moving forward.
Advantages of reduced size of the project include goals that are attainable and
verifiable in shorter time frames. Teams working on small projects may have better
communication, often talking to one another informally, rather than holding planned
meetings. Disadvantages of smaller projects include the necessity of team members
working on several aspects of the project, often simultaneously, instead of one well-
defined task. This can lead to distraction and lost time due to context switching. Smaller
projects and teams may cause team members to feel that commonly accepted
procedures, such as thorough documentation, are less important. Deadlines may be
unrealistically short on some smaller projects, which intensifies the problem of skipping
thorough documentation.
The example of the Federal Bureau of Investigation’s (FBI) Sentinel project
provides a case that used a reduce strategy in that they minimized the size and scope of
the project when facing failure. As reported by Eggen and Witte (2006), initially the FBI
began a project named Virtual Case File (VCF), which was unsuccessful. The FBI pulled
the plug on the VCF project after six years and $170 million. They restarted the project
as Sentinel. Reportedly, the Sentinel project was only about 15% complete after four
years with 400 people working on it, at a cost of about $405 million. After reducing the
size of the project, a smaller team of about 15 people finished the work in less than a
year.
The case of California’s Department of Motor Vehicles is another example of the
reduce scope strategy. Megerian (2013) discusses that the project originally began in
2006 with the goal of overhauling the current method for vehicle registration and
distribution of drivers’ licenses. As of February 2013, seven years after the project began,
$208 million had been spent and only half the project was completed. The decision was
then made by state officials to reduce the scope of the project. They would no longer be
concerned about the vehicle registration element, due to lack of progress. DMV officials
are still uncertain of what the overall cost of this project will be.
In 1992, Denver International Airport contracted with BAE for an automated
baggage handling system, which was to capture three concourses, all airlines, departing
and arriving flights as reported by Calleam Consulting (2008). Throughout the
following months, several change orders requesting additional capabilities, such as
handling oversized baggage and ski equipment were received. The target opening date
was postponed four times over a period of about a year. The fourth target date was May

JOURNAL OF MANAGERIAL ISSUES VOL. XXX N umber 3 F all 2018

 G uidry , H alligan , and P eters 371

1994, which resulted in a system that was malfunctioning. In August of that year, the
City of Denver began fining BAE for further delays. The actual opening of the system
was in February 1995 with the system being just a shadow of the original plan. Rather
than automating all three concourses into one integrated system, the system was used in
a single concourse, by a single airline, and only for outbound flights.

DISSOLVE

At some point, it may be necessary to completely dissolve a project, reverting to the

previous processes. Some projects have been shown to run forever, becoming an endless
source of costs and headaches. A “kill switch” may be necessary on projects that have no
productive resolution in sight. Some small projects have an automatic kill switch as
funding runs out. Often, no one, not even the CEO, has the courage to stop a project.
Because making the decision to dissolve a project is difficult, it is sometimes necessary
to bring in an unbiased person to help make the decision. The decision should be based
on weighing the expected future costs against the benefits. Examples may include
projects where requirements are not defined clearly or the technology available is not
acceptable or cost prohibitive. The decision should not be based on sunk costs, as they
can never be recovered.
Reasons to dissolve a project are not uncommon. Technology is changing so rapidly
that an alternative product, such as off-the shelf software, may become available that
meets the needs the project was meant to satisfy. Resources may run out or be pulled. It
may become apparent that the goal is not attainable. Perhaps the project team ran into
problems beyond their skill level.
The disadvantages of the dissolution of large projects must be considered. Large
projects may have political ties to (or for) stakeholders. Cancellation of an ongoing
project could lead to broken contractual agreements, severance pay for team members,
and the loss of sunk costs (tangible and intangible). The end of a project may be an
emotional blow to team members/employees who could become disillusioned. A
company’s reputation could be at stake, which could damage relationships with suppliers
or other stakeholders.
Although disadvantages to the dissolve strategy are great, the advantages cannot be
dismissed. In the case of a failed project that resulted in a substantial loss to the
organization, there may be some type of audit or investigation to find the cause of the
failure. Findings may lead to new and improved policies and procedures, which reduce
future losses. Another advantage is that it forces an end to a project that has become a
“money pit.” In cases of failures that have become public, dissolving the project will
allow the organization to “save face,” reducing any further damage to its reputation for
being a part of a failed project.
An example of a failing project in the press was Marin County California’s MERIT
(Marin Enterprise Resource Integrated Technology) effort to build a new financial
accounting, payroll, and HR system. As reported byjohnson (2013), the county selected
Deloitte Consulting LLP to implement the project. The first rollout of the system,
Release I, went live in July 2006 and resulted in significant losses due to errors and
incorrect posting of transactions. In January of 2007, Release II was implemented even
though the first release was still producing errors and experiencing other problems.
Soon after, Marin County fired Deloitte and initiated a program to try to recover losses

JOURNAL OF MANAGERIAL ISSUES VOL. XXX NUMBER 3 FALL 2018

372 H a n dlin g I nform ation S ystem D ev elo pm ent F a ilu re

and attain a working system. Marin County sued Deloitte in May, 2010. Marin County
alleged Deloitte had defrauded them and sought $30 million in damages. Officials
claimed the county was used as a “guinea pig” by Deloitte, which employed workers with
inadequate skills and rushed to meet deadlines simply to obtain payment. Further
allegations against Deloitte included: misrepresenting skills, withholding project
information, and having a conflict of interest. Specifically, court documents reveal Marin
identified the following phrases from the request for proposal (RFP) as being fraudulent:
that Deloitte is “uniquely qualified, assembled a highly skilled and experienced team,
and has great strength in all aspects of ERP implementations.” The MERIT project
exhibits three issues commonly seen in IT projects: skills and experience potentially
being exaggerated; failure to define acceptance criteria for release of a project; and lack
of communication/quality control. According to Henry (2013), the failed project cost the
taxpayers approximately $28 million. Moreover, the damage to employee morale and
public trust in the county’s information systems was not quantifiable.
Another example of the dissolution of a project was seen in the Los Angeles Unified
School District, in the fall of 2013. It was reported by Lapowsky (2015) that the school
district entered into agreements with Apple and Pearson. The plan was to put an iPad
in the hands of every student, more than 100,000 of them, at a cost of $1.3 billion.
Devices would have enabled teachers and students to access curriculum yet lock out
unauthorized content. Students quickly bypassed security. Technical issues caused some
students to have no access at all for months. Bernadette Lucas, the initiative’s director,
wrote that less than 5% of the students issued iPads had reliable access to the curriculum.
Rumors arose that Apple and Pearson received preferential treatment in acquiring the
contracts. The FBI began investigating whether emails exchanged between the school
superintendent and executives at Pearson and Apple referred to the agreement prior to
the bidding process.
In the Los Angeles Unified School District, after less than two years of using the
iPads, only 2 of 69 schools are still using the Pearson curriculum. The school district
approved another $40 million in late 2014 to purchase Chromebooks to be used in some
schools for testing. As of May of 2015, 58 schools were still using the iPads but only to
access other applications. The contracts with Apple and Pearson were halted. In the
spring of 2015, as reported by Lapowsky (2015) the district asked Apple for a refund
due to “crippling technical issues” that made it impossible for the devices to be used to
teach. The district may take legal action, if an agreement cannot be reached. Under new
leadership, the school district has formed a task force to develop a new' technology plan.
They hope to learn from the mistakes and use a strategic approach for using technology
in the classroom.
In 2010, Waste Management Inc. and SAP AG settled a lawsuit by Waste
Management accusing SAP AG of participating in a fraudulent scheme to sell an ERP
system (Kanaracus, 2010). Waste Management sought to recover more than $100 million
in costs. As originally reported by Kanaracus in 2008, Waste Management sought an
“out-of-the-box” solution that would meet their needs. They alleged SAP presented a
version of their product at a sales demonstration that had been customized to their
needs for the presentation. Waste Management claimed the “fake software” resulted in
their signing a sales agreement on Oct. 3, 2005. Soon after the contract was signed, SAP
discovered many gaps in the software’s functionality and Waste Management’s business

JOURNAL OF MANAGERIAL ISSUES VOL.XXX N umber 3 FALL 2018

 G uidry , H alligan , and P eters 373

requirements. Significant changes to the implementation timetable and final version of

the product were necessary, resulting in the filing of the lawsuit.
According to ComputerWorld magazine (Songini, 2005), in 2000 the state of
Arkansas awarded a contract to SAP to build a new enterprise resource planning system
to manage human resources and payroll functions, called the Arkansas Administrative
Statewide Information System. In 2001, the system was implemented without access for
visually-impaired users. Subsequently, employees sued due to the lack of accessibility. In
2004, parts of the system were shut down as a result of the noncompliance with handicap
accessibility requirements. In 2005, Governor Mike Huckabee announced plans to “pull
the plug” on the entire system.

DISCUSSION AND IMPLICATIONS

The strategies section above presents the different paths that a manager can take
when faced with a failing information systems project. When examined holistically, the
strategies can be integrated together into a strategic framework for managerial decision­
making. This holistic view is presented in Figure I. Although each of the individual
strategies identified has specific advantages and disadvantages, it should be noted that
they may overlap as a company may try to resolve an issue using one strategy and then
determine it is best to shift to another in order to get the most timely and efficient
resolution to the problem. For example, in the case of the FBI’s Virtual Case File,
initially the government chose to use the dissolve strategy, later salvaging the project by
renaming it and beginning again as a project of reduced scope.
A holistic view of the cases that were identified to illustrate project failure also
highlights the fact that the strategies presented appear to be driven by either an
underlying perspective of forfeit or fight. A forfeit strategy is one in which the company-
elects to give up the project or parts of it in order to reduce further loss. A fight strategy
indicates the company is going to do all it can to correct the problems and get the project
back on the path to success. The two strategies that involve forfeit include dissolve and
reduce scope. Both of these strategies often result in a significant loss of resources that
have been invested. The fight strategies may allow an opportunity to salvage much of
what has been invested but also have a risk of delaying the inevitable in the case of
projects that cannot be saved. As reported by The Standish Group International (2013),
implementations of information systems have an overall failure rate of 61%.
Organizations must be prepared to deal with failure and thereby mitigate the damages.
Several conclusions can be drawn from this study. First, information systems have
become a necessary tool for existence in organizations and are increasingly complex.
Proper management and strategy are necessary components of successful development
and implementation, as well as dissolution of information systems. As stated in the
examples presented above, inactivity or errors in management decisions are a common
thread among failures of management information systems. As early as 1978, Schmitt
and Kozar published that MIS failures are often due to a degenerative network of
management errors, which is difficult to escape once entered.

JOURNAL OF MANAGERIAL ISSUES VOL. XXX NUMBER 3 FALL 2018

374 H a n d lin g I nform ation S ystem D evelo pm en t F a ilu re

Figure I
Strategic Framework for Addressing Failure of Information Systems Projects

A second conclusion that can be drawn from this study is that many examples in the
popular press of failure of development or implementation of MIS projects are of
government entities. Examples of failures in private or corporate industry are less
common in the popular press. The authors believe this lack of published examples does
not indicate there are fewer failures in private industry, but rather that it is less common
for those to be made public. Freedom of Information laws make the details of failures
in government industries readily available to those who choose to research them.
A third and final conclusion drawn from this study is that, after a failure, it is
common for there to be an investigation, internal or external audits, and press coverage
of the failure. Information gained can then lead to improvements in processes in later
projects. In several of the cases studied, changes to policy were explicit. In others, formal
charges and litigation have occurred, which often lead to review of policies/procedures.
In closing, four strategies have been identified that managers can use when
handling a failed information systems project. The strategies are conceptual and based
on research of projects with real failures that have been documented. Furthermore, a
holistic view of these strategies was presented along with the underlying drivers of fight
and forfeit. The information in this study focused on outsourced projects. The

JOURNAL OF MANAGERIAL ISSUES Vol. XXX N umber 3 Fall 2018

 G uidry , H alligan , and P eters 375

conclusions drawn from this study clearly present a need for future research to examine
strategies for dealing with IT projects developed in-house. Future research should also
examine project failure strategies within private organizations to see if they are
consistent with the strategic framework presented in this paper. This study also presents
an obligation to further examine the role of government bureaucracy in project failure.
For example, questions to address might include, “Does bureaucracy or lack of flexibility
afforded to project managers in government projects increase the rate of failure?” and
“Were the managers of the failed projects aware of the potential for audit and how did
that factor into their decision-making?” Future research may need to be based on survey
data in order to validate the strategies identified and model presented using quantitative
methods.
Finally, these findings present an opportunity to study why each company selected
the strategy they chose, along with demographic information about each company, as
this endeavor may also shed light on relevant factors that should be utilized when a
manager is trying to determine what to do with a failed information systems project.

References

Bloch, M., S. Blumberg, and J. Laartz. 2012. Delivering Large-Scale IT Projects on Time,
on Budget and on Value. McKinsey & Company Digital McKinsey.
Borchers, A. S., K. Huggins, and J. Crawford. 2014. “Healthcare.gov Website Failure.”
Societyfor Case Research Vol. 7: 69-72.
Calleam Consulting Ltd. 2015. “US Census Bureau - Field Data Collection Automation
(FDCA) - Case Study. Why Do Projects Fail?” (accessed November 13, 2015).
Calleam Consulting Ltd. 2008. “Denver International Airport Baggage Handling
System - An Illustration of Ineffectual Decision-making - Case Study. Why
Technology Projects Fail.” (accessed December 30, 2016).
Carr, N. 2003. “I.T. Doesn’t Matter.” Harvard Business Review May 2003 Issue (accessed
September 12, 2015).
Chen, D., and W. Rashbaum. 2011. “City Payroll Project Was Riddled with Fraud, U.S.
Says.” The New York Times (accessed September 2, 2015).
Collins, D. 2011. “CityTime Crime is Mayor Bloomberg’s Shame.” The Huffington Post.
(accessed November 15, 2015).
Computer Economics. 2016. “App Dev Outsourcing Growth Slow.”
Eggen, D., and G. Witte. 2006. “The FBI’s Upgrade That Wasn’t.” Washington Post
(accessed September 12, 2015).
Flowers, S. 1996. Software Failure: Management Failure. Chichester, UK: John Wiley.
Ford, P. 2013. “The Obamacare Website Didn’t Have to Fail. How to Do Better Next
Time.” Bloomberg.Com. (accessed August 31, 2015 from Business Source Complete)
Foster, R. 2013. “HealthCare.gov: It Could Have Been Worse.” The New Yorker Blogs
(accessed September 3, 2015).
Guidry, T., and C. Peters. 2015. “Carolina Ingredients and the Maturation of a
Management Information System ."Journal of Case Studies 33(1): 45-52.
Henry, B. 2013. “Marin County, Why Projects Fail.” International Project leadership
Academy (accessed September 2, 2015).
Holcomb, M. 2008. Running an Agile Software Development Project. UK: John Wiley.

JOURNAL OF MANAGERIAL ISSUES VOL. XXX NUMBER 3 Fall 2018

376 H a n d lin g I nform ation S ystem D ev elo pm ent F a ilu re

Johnson, N. 2013, “Marin County Cuts Its Losses, Settles Computer Lawsuit for $3.9
Million.” Marin Independent Journal (accessed September 1, 2015).
Kanaracus, C. 2010. “Waste Management Settles Lawsuit.” ComputerWorld (accessed
December 27, 2016).
Kanaracus, C. 2008. “Waste Management sues SAP over ERP Implementation.”
ComputerWorld (accessed December 27, 2016).
Lapowsky, I. 2015. “What Schools Must Learn from LA’s iPad Debacle.” Wired (accessed
September 10, 2015).
Laudon, K., and J. Laudon. 2014. Management Information Systems, Managing the Digital
Firm. Boston, MA: Pearson, p. 15
Liu, J. 2010. Audit Report of the Office of Payroll Administration’s Monitoring of the Oversight
of the CityTime Project by Spherion Atlantic Enterprises LLC. City of New York Office of
the Comptroller, (accessed November 7, 2015).
McManus, J. 2014. “A Project Management Perspective of Information Systems
Development.” Management Services (accessed September 2015).
Megerian, C. 2013. “Half-finished $208 Million DMV Technology Overhaul Canceled.”
Los Angeles Times (accessed September 12, 2015).
Meyer, R. 2015. “The Secret Startup That Saved the Worst Website in America.” The
Atlantic. July 9, 2015. (accessed September 2, 2015).
Oz, E. 2006. Mamgement Information Systems. Canada: Thomson Course Technology, p.
13.
Poston, R., J. Patel, and J. Dhaliwal. 2014. “Monitoring for Testing Throughout the
Development Lifecycle. "Journal ofInformation Technology Management Volume XXV,
3. (accessed October 2015).
Pries, K., and J. Quigley. 2010. Scrum Project Management. Boca Raton, FL: CRC Press.
Ravasan, A., and T. Mansouri. 2014. “A FCM-Based Dynamic Modeling of ERP
Implementation Critical Failure Factors.” International Journal of Enterprise
Information Systems 10.1: 32+. (accessed 14 Mar. 2016).
Raymond, N. 2014. “Three Men Get 20-year Sentences in New York City Payroll Fraud
Case.” The New York Times (accessed September 2, 2015 from Rueters.com).
Rogers, A. 2013. “House Democrats Angry at Botched Obamacare Website Rollout.”
Time.com (accessed August 31, 2015).
Schillings. 2015. “Safeguarding Corporate Reputation.” The Lawyer Research Service
(accessed April 27, 2015).
Schmitt, J., and K. Kozar. 1978. “Management’s Rose in Information System Failures:
A Case Study.” MIS Quarterly June 1978.
Songini, M. 2005. “Arkansas Set to Pull the Plug on Second Budgeting App.”
Computerworld.. Vol. 39 No. 6.
Stair, R., and G. Reynolds. 2015. Principles of Information Systems 12th ed. Boston, MA:
Cengage. p. 550
Standish Group International. 2013. “CHAOS Manifesto 2013, Think Big, Act Small.”
(accessed September 11, 2015).
Tan, W., and C. Tan. 2010. “Teaching Information Systems Development via Process
Variants ."Journal of Information Systems Education Vol. 21, No. 2: 159-172.
U.S. v. Mazer et al. (2013). U.S. District Court for the Southern District of New York,
No. 11-121

JOURNAL OF MANAGERIAL ISSUES Vol. XXX N umber 3 Fall 2018

 G uidry , H alligan , and P eters 377

Valacich, J., and C. Schneider. 2012. Information Systems Today, Managing in the Digital
World 6th ed. Boston, MA: Pearson, pp. 226, 382.
Weinberger, D. 2013. “A Limit to Business Intelligence?” KM World July/August 2013.
(accessed September 2015).
Wilson, J. 2010. Letter from the Comptroller to Members of the General Assembly in
the State of Tennessee, (accessed December 27, 2016).

JOURNAL OF MANAGERIAL ISSUES Vol.XXX N umber 3 Fall 2018

Copyright of Journal of Managerial Issues is the property of Journal of Managerial Issues /
PSU and its content may not be copied or emailed to multiple sites or posted to a listserv
without the copyright holder's express written permission. However, users may print,
download, or email articles for individual use.