TEACHING CASETargeting Target with a 100 million dollar da.docx

TEACHING CASE
Targeting Target with a 100 million dollar data breach
Federico Pigni1 • Marcin Bartosiak2 • Gabriele Piccoli3 • Blake
Ives4
Published online: 16 November 2017
� Association for Information Technology Trust 2017
Abstract In January 2014, the CEO of the renowned U.S.
discount retailer Target wrote an open letter to its cus-
tomers apologizing for the massive data breach the com-
pany experienced during the 2013 holiday season.
Attackers were able to steal credit card data of 40 million
customers and more were probably at risk. Share prices,
profits, but above all reputation were all now at stake. How
did it happen? What was really stolen? What happened to
the data? How could Target win consumer confidence
back? While the company managed the consequences of
the attack, and operations were slowly back to normal, in

the aftermath the data breach costs hundreds of million
dollars. Customers, banks, and all the major payment card
companies took legal action against Target. Some of these
litigations remained unsettled 3 years later. The importance
of the breach lays in its far broader consequences, rippling
through the U.S. Congress, and raising consumer and
industry awareness on cyber security. The case provides
substantial data and information, allowing students to step
into the shoes of Target executives as they seek answers to
the above questions.
Keywords Teaching case � Cyber security � Hacking �
Data breach � Target � Information systems
Introduction
On January 13th and 14th, 2014, Greg Steinhafel, Chair-
man, President, and CEO of Target, published an open
letter to customers (Steinhafel 2014) in The New York
Times, The Wall Street Journal, USA Today, and The
Washington Post, as well as in local papers of the firm’s 50

largest markets. In the letter, he apologized for the massive
data breach his company experienced during the 2013
holiday season.
Target learned in mid-December that criminals
forced their way into our systems, gaining access to
guest credit and debit card information. As a part of
the ongoing forensic investigation, it was determined
last week that certain guest information, including
names, mailing addresses, phone numbers or email
addresses, was also taken.
I know this breach has had a real impact on you,
creating a great deal of confusion and frustration. I
share those feelings. You expect more from us and
deserve better. We want to earn back your trust and
confidence and ensure that we deliver the Target
experience you know and love.
The breach, announced to the public 6 days before
Christmas, included credit card data from 40 million

customers. It was later discovered that data for another
70 million customers were also at risk.
& Federico Pigni
[email protected]
1 Grenoble Ecole de Management, 12, rue Pierre Sémard,
38000 Grenoble, France
2 Department of Economics and Management, University of
Pavia, Pavia, Italy
3 E.J. Ourso College of Business, Lousiana State University,
Baton Rouge, LA, USA
4 C.T. Bauer School of Business, University of Houston,
Houston, TX, USA
J Info Technol Teach Cases (2018) 8:9–23
DOI 10.1057/s41266-017-0028-0
Target Inc.
Target’s chain of discount stores sold low-cost clothing,
items for the home, and—in some stores—groceries. Major
competitors in the U.S. included Walmart, Kmart, CostCo,

Kohl’s, J.C. Penney and, in Target’s still small but growing
online segment, Amazon. The first Target store, a low-cost
subsidiary of the department store chain Dayton Hudson,
opened in 1962; by December of 2014, Target’s 366,000
employees staffed a network of nearly 2000 stores located
in the U.S. (1801) and Canada (133). Target’s stores also
included larger SuperTarget stores, smaller CityTarget
stores, and still smaller Target Express stores. In 2014,
Target reported revenues of USD 73 billion.
Headquartered in Minneapolis, Target differentiated
itself from low-cost competitors by offering Target brands,
exclusive deals with other brands, quality and trendy
goods, as well as fashion items from well-known design-
ers—all at modest prices; Fortune magazine characterized
Targets merchandising focus as ‘‘Cheap and Chic’’ (Wahba
2014).
The breach
Target announced the data breach (see Exhibit 1), one day

after an independent reporter and investigator of Internet
security, Brian Krebs, broke the story on his blog:
…Target is investigating a data breach potentially
involving millions of customer credit and debit card
records… According to sources at two different top
10 credit card issuers, the breach extends to nearly all
Target locations nationwide, and involves the theft of
data stored on the magnetic stripe of cards used at the
stores (Krebs 2013).
For several days prior to Kreb’s posting, banks had
witnessed an uptick in illegal card activity, with a
disproportionate number of those transactions traceable to
card numbers recently used by Target customers. The
banks notified the Federal Bureau of Investigation (FBI).
The U.S. Department of Justice (DOJ) alerted Target on the
evening of December 12th. The following day, DOJ and
U.S. Secret Service personnel met with Target executives.
By December 15th, outside experts, hired by Target, helped
to discover and remove malware in Target’s point-of-sale

(POS) terminals and on several of the company’s servers.
On December 16th, Target notified banks and payment
processors (e.g., Visa) that it had been breached.
From November 27th onwards, debit and credit trans-
actions from Target’s U.S. store’s point-of-sale checkout
terminals had been compromised and customer data stolen.
By December 15th, the hemorrhaging had slowed to a
trickle, and by the 18th was stopped. By then the data
contained on magnetic stripes of 40 million debit and
credit cards had been copied and, through a circuitous
route, transmitted to a server in Russia. Almost immedi-
ately, customer credit card data surfaced on the black
market at Internet ‘‘card shops.’’
On December 27th, Target announced that encrypted
personal identification number (PIN) data from some cards
had also been scraped. Then, on January 10th, 2014, Target
reported that non-financial data from as many as 70 million
additional customers had also been stolen from Target

servers; included were names, addresses, phone numbers,
and email addresses. Because of duplicates between the
two sets of data, the total number of customers affected
was approximately 100 million.
Data breaches
The Identity Theft Resource Center (ITRC) defines a data
breach as (ITRC 2015, p. 2):
An incident in which an individual name plus a
Social Security number, driver’s license number,
medical record or financial record (credit/debit cards
included) is potentially put at risk because of
exposure.
Data breaches were classified in several ways. Breaches
could be criminal or accidental, carried out by insiders or
outsiders, computer-based or manual. The external, com-
puter-based, criminal variety often involved changes to, or
tapping into, the network, computer, or terminal hardware
(called skimming). For instance, fake ATM fronts or card

readers were surreptitiously attached to ATM machines; or,
for as little as USD 1000 an ATM could be acquired and set
up as a honey pot for capturing unencrypted data from
legitimate cards (Satanovsky 2011). An alternative
approach, called RAM or Memory Scraping (Zetter
2014), required the use of software tools, either malware
or legitimate software employed in an illegitimate manner
on customer facing devices including ATMs, POS, or even
consumers own computers or phones. Scraping, unlike
skimming, required no physical access; it could be carried
out from anywhere in the world, thus lowering the risk to
the perpetrator, while presenting still greater exposure to
the victims.
The Target data breach was but one of an increasingly
common phenomenon. One compilation (ITRC 2015)
identified 781 breaches in the U.S. that exposed 169 mil-
lion records in 2015, a significant increase from 498
reported breaches and 22 million records reported six years

10 F. Pigni et al.
earlier (Fig. 1). In ten years, the ITRC had identified over
6000 breaches exposing more than 850 million records. A
fourfold increase in a decade, affecting financial services,
business, education, government, and healthcare sectors.
As many breaches went unreported, these were conserva-
tive numbers.
U.S. firm’s reported having had more than a million
records exposed in the year following the Target breach;
among them were three retailers: Home Depot, Michael’s
Stores, and Neiman Markus. In each case, the perpetrators
appeared to have employed tools, and taken advantage of
organizational lapses, in ways similar to Target’s Breach.
Among notable, other victims of data breaches in 2014
were AliExpress (owned by Alibaba.com), American
Express, Korean Credit Bureau, JPMorgan, The U.S. Postal
Service, the U.S. Internal Revenue Service, Rumbler.ru

and, perhaps most notoriously, SONY Pictures.
In 2016, data breaches were still increasing 15% year on
year, and the number of stolen record was growing at twice
that peace (31%), with an average of 3 million records
stolen per day. North America (see Fig. 2) was experi-
encing the largest number of data breaches, accounting for
almost 80% of the world total (Breach Level Index, 2016).
The United States led the world in data breaches with over
400 million compromised records (70% of the total).
Europe, the next highest, accounted for 10% of the total
breaches with close to 50 million stolen records. The Asia
and Pacific region was close behind in breaches (8%) but
far outstripped Europe with 110 million compromised
records (20%). U.S. security breach notification laws and
European directives and regulations (e.g., the General Data
Protection Regulation 2016/679) required organizations to
disclose and to inform promptly customers, authorities, and
other parties when personal data were stolen or compro-

mised; an obligation not all countries were under. These
regulations had the double objective of encouraging firms
to improve their practices and consequently reduce con-
sumers’ risk.
Healthcare, government, financial, retail, education, and
technology were the main target sectors for data breaches.
In the U.S., 2016 saw an increase in breaches to POS
systems at several hotel chains and retailers (see Fig. 3).
Senior management’s rising concern regarding com-
puter and network security were on display in the results of
the 2016 PwC Annual Global CEO Survey, where 61%
percent of the executives interviewed described cyber
threats and lack of data security as a threat to both national
and commercial interests (PwC 2016). Moreover, an even
higher proportion (78%) of them considered cyber security
technologies to be strategically important for their firms.
While security became a top priority in CEOs’ agendas
and a prominent topic in boardroom discussions, the data

showed that corporations were losing ground in responding
to the threat.
Payment systems and fraud
The U.S. Federal Reserve Bank reported (Federal Reserve
Board 2014, p. 41) in 2012 that credit cards made up 21%
of the total number of non-cash transactions in the US and
1.4% of the non-cash value; the corresponding numbers for
debit cards were 38% and 1% and for checks, 15% and
14.8%. For Automated Clearing House (ACH) transac-
tions, such as online bill-pay and wire transfers, commonly
used for large, non-retail transactions, the transaction and
value numbers were 18% and 83%. Cash, an essentially
0
100
200
300
400
500

600
700
800
900
2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
nu
m
be
r o
f b
re
ac
he
s
Banking/Credit/Financial
Health/Medical
Government/Military
Educational
Business
Fig. 1 Evolution of data
breaches in the U.S. (ITRC

2016)
Targeting Target with a 100 million dollar data breach 11
anonymous payment system, was still the most common
payment method, constituting 40% of transactions in the
U.S. (Bennett et al. 2014, p. 3). An average consumer in the
month of October 2012 used cash for 23 of 59 payments
(Bennett et al. 2014, p. 2). Cash, however, was primarily
used for small dollar value purchases, constituting only
14% of purchases at retail, and averaging USD 21 per
transactions (Bennett et al. 2014, p. 3). At brick & mortar
stores such as Target, a high, and increasing, proportion of
purchases were made with credit or debit cards.
Payment cards, particularly credit and non-pin protected
debit cards and prepaid cash cards, presented tempting, and
still relatively risk-free, opportunities for criminals. The
ability to tap into U.S. payment systems from other coun-
tries, particularly those with weak enforcement or no

extradition treaties with the U.S., further lowered the risk.
In 2012, the Federal Reserve reported over 31 million
fraudulent payment transactions with a value of over USD
6 billion; 26 million of these transactions, and over USD 4
billion of value, were from credit, signature-only debit, or
prepaid cash cards. Pin-protected debit cards were far more
secure, experiencing only 20% of the fraud rates of sig-
nature debit cards (Federal Reserve Board 2014).
The biggest vulnerability in card payment systems in the
U.S. was the card’s magnetic stripe. The data written on the
‘‘magstripe’’ included the primary account number, the
United
States
United
Kingdom
New
Zealand Japan China Israel
South
Africa
2016

2015
2014
2013
Canada Australia India
1008 82 55 34 17 12 7 9 8 8
1370 158 65 45 22 23 21 9 5 5
1259 135 65 34 7 13 12 15 17 4
911 86 30 26 12 13 12 5 8 3
1
10
100
1,000
Nu
m
be
r o
f b
re
ac
he
s
Fig. 2 Data breaches by
country—logarithmic scale

(authors on Gemalto’s data,
October 2016—http://www.
breachlevelindex.com/data-
breach-database)
2016
2015
2014
2013 2623411097165
Healthcare Government Financial Retail Technology Education
Hospitality Other
375 197 169 142 133 122 11 195
445 296 276 238 120 165 1 322
446 289 211 194 138 173 274
119342
0
150
300
450
Nu
m
be
r o
f b

re
ac
he
s
Fig. 3 Data breaches by
industry (authors on Gemalto’s
data, October 2016—http://
www.breachlevelindex.com/
data-breach-database)
12 F. Pigni et al.
account holder’s name, the expiration date, a service code
indicating the types of charges that could be accepted, and
discretionary data, such as a PIN code. Once compromised,
either by scraping or skimming, these data could be used to
make online purchases or to legitimate counterfeit cards,
which could then be used in physical stores. While in-store
use might seem risky, it did not require a mailing address to
collect the ordered merchandise. Moreover, the stolen

merchandise, mostly electronics or gift cards, could often
be immediately resold.
‘‘Big Box’’ and discount retailers were particularly
vulnerable to payment card fraud and data breaches due to
the size of their customer population, their high daily
transaction volumes, the liquidity of some of their mer-
chandise, and their customers’ desire for fast and conve-
nient checkout. Moreover, huge past investments in point-
of-sale check-out devices, as well as the typical customer’s
comfort with mag-stripe credit and debit cards, had retar-
ded retailers’ transition to more secure technologies (Geuss
2015).
The complexity of the payment network added further
vulnerability. The observation of a judge in an earlier data
breach case described that complexity and, implicitly, its
consequent vulnerability:
‘‘Every day, merchants swipe millions of customers’
payment cards. In the seconds that pass between the

swipe and approval (or disapproval), the transaction
information goes from the point of sale, to an acquirer
bank, across the credit-card network, to the issuer
bank, and back. Acquirer banks contract with mer-
chants to process their transactions, while issuer
banks provide credit to consumers and issue payment
cards. The acquirer bank receives the transaction
information from the merchant and forwards it over
the network to the issuer bank for approval. If the
issuer bank approves the transaction, that bank sends
money to cover the transaction to the acquirer bank.
The acquirer bank then forwards payment to the
merchant.’’ (Rosenthal, 2011)
The judge described a four-party payment system: A
credit-card network, usually Visa or MasterCard, is a
network intermediary between the merchants’ bank (‘‘ac-
quirer’’), the merchant, and the customer’s bank (‘‘issuer’’).
The alternative, a three-party approach, links three partic-

ipants: the card-carrying customer, the merchant, and the
card issuer (e.g., American Express or Discover). In 2013,
82% of card payments went through the four-party system.
To further the complexity, many merchants relied on
outside payment processors for the link between their POS
devices and acquiring banks. Two of these, Global
Payments and Heartland Payments, had themselves been
major victims of hackers.
Anatomy of the Target breach
The first victim in the heist was not Target, but Fazio
Mechanical Services, a provider of refrigeration services to
Target. Themeans of attackwas uncertain, but likely executed
via a bogus link or attachment as part of an email ‘‘phishing’’
broadcast to multiple Target third-party vendors—a list of
which was openly available on the Internet. To get inside the
supplier’s network, the attackers used a malware package
called Citadel (Olavsrud 2014) and then found and used
Fazio’s credentials to exploit its previously authorized access

to Target’s computer network. Fazio had access to several
Target systems, including contract management, project
management and electronic billing.OnNovember 12th, 2013,
the attackers gained access to Target’s internal network,
probably by uploading an executable file disguised as a
legitimate document attachment through a Web application.
The name of the uploaded file was apparently chosen to be
similar to that of other files commonly seen on the system.
Once inside Target’s internal network, the attackers
sought out logins, passwords, and network diagrams.
Failing to find credit card credentials on Target servers,
they instead, apparently patiently and successfully, pene-
trated Target’s POS terminals. Harnessing a computer
account they had created on Target’s network, they
deployed malware to POS terminals that the investigators
named Kaptoxa (pronounced kar-toe-sha), available for
about USD 2000 on black market Web sites. The software
then scraped each unencrypted card as it was read.

Between November 15th and 28th, the attackers tested the
malware1 on a few of Target’s POS devices. By November
30th, the hack was fully installed on almost all POS devices
and fully operational. That day, the attackers also installed
malware to transfer the stolen data to an internal server. This
data exfiltration malware,2 the file name of which was dis-
guised to look like a legitimate application, was updated
twice: on December 2nd, and again on December 4th. On
December 2nd, the perpetrators began to transfer data to
another Target server, one that was authorized for file
transfers through Target’s firewall. The data were moved
from that server to servers outside the U.S., eventually
ending up on a server in Russia. Data were moved during
business hours to hide the illicit activity within an otherwise
busy network traffic.
1 While not definitively linked to the Target data breach, in
August of
2014 the U.S. Secret Service Identified malware called
‘‘backoff’’ that

was first detected in October of 2013 but not detectable by anti-
virus
solutions until almost a year later. Backoff was estimated to
have already
affected over 1000 U.S. Businesses.
https://www.documentcloud.org/
documents/1279345-secret-service-malware-
announcement.html.
2 Data exfiltration is the transfer of stolen data from a
compromised
system within victims’ network back to the attacker while
attempting
to remain undetected.
Stolen card numbers were almost immediately available
on Internet black markets. One market, Rescator, had been
described as ‘‘The Amazon.com of Stolen Credit Cards.’’
(Lawrence 2014) Here batches of credit cards could be
purchased, sometimes for prices exceeding USD 100
(Fig. 4). Cards data contained in the earliest batch released
on Rescator sold for between USD 26.60 and USD 44.80 in

the days before December 19th (Exhibit 3), when Target
went public on the data breach (Krebs 2014).
Failed security measures
Target’s attackers exploited numerous security weaknesses.
Target had publicly posted the names of its suppliers on the
Internet. One of them, FazioMechanical Services, had relied
on a free malware detection package, intended for use by
individuals, rather than for commercial use. The malicious
detection package, installed at Fazio, probably captured
login and password information during transactions. While
two-factor authentication was required by PCI3 for payment
servers, it was not required, and from reports was rarely used,
for non-payment related, externally accessible applications
on Target’s external network. Instead, Target relied on a
scheme required by PCI policy: payment servers were seg-
regated from the rest of the network. Indeed, PCI had
recently given a clean audit of Target’s network segrega-
tion—a segregation that subsequently proved inadequate.

Two different security packages triggered alarms as the
data exfiltration malware was installed on November 30th,
and then again when it was updated. One of these pack-
ages, FireEye, installed at a cost of USD 1.6 million a few
months earlier, recommended to its Target minders in
Bangalore the deletion of the malware—a recommendation
reportedly passed on to, but ignored by, the personnel in
Target’s security operations center in Minneapolis (Riley
et al. 2014). Target also apparently did not maintain a
‘‘white list’’ of authorized processes, often used to ensure
that malware is not allowed to run on a device or server.
Neither did Target adequately monitor the creation of new
Fig. 4 Rescator’s efficient and user friendly web shopping
interface
3 The Payment Card Industry Security Standards Council (PCI
SSC)
was created in 2006 to develop security standards for the
evolving
Payment Card Industry (PCI). The resulting Payment Card
Industry

Footnote 3 continued
Data Security Standard (PCI DSS) is intended to ensure
participating
companies that process, store, or transmit credit card
information do
so in a secure manner.
14 F. Pigni et al.
accounts, nor effectively block access to certain external
file servers (e.g., servers in Russia).
Financial consequences
The breach proved to be immediately costly as reflected in
the CEO’s comments to analysts in a February 2014
earnings conference call.
Target’s fourth quarter financial results reflect better
than expected US segments performance through the
first three weeks of the holiday season, followed by
meaningfully softer results following our December
19 [data breach announcement] … fourth quarter

comparable sales decreased 2.5%, consistent with our
updated guidance in January. (Target 2014c, p. 3)
Target’s cumulative stock return had beaten both the S&P
500 and Target’s peer comparison group in February of 2013
but, by the following February, 2 months after the breach,
had fallen precipitously behind both groups. Earnings per
share had also fallen (Target 2014a, pp. 15–16). Profits in the
4th quarter of 2013 were off 47% from the previous year,
though the decline was partially attributed to poor perfor-
mance at Target’s Canadian stores.
Costs piled up. Eight months after the breach, the com-
pany reported USD 236 million in breach-related costs, of
which USD 90 million were covered by insurance (Target
2014e, p. 9). One big expense was the cost to provide Tar-
get’s customers with a year of credit screening services.
Those reported expenses, coupled with a drop in expected
earnings from 85 to 78 cents a share, stunned Wall Street;
Target’s stock price fell 4.4% the next day (Abrams 2014).

John Kindervag, a Vice President and principal analyst
at Forrester Research, predicted that the eventual costs of
the breach would be much higher:
I don’t see how they’re getting out of this for under a
billion, over time… One hundred fifty million in a
quarter seems almost like a bargain. (Abrams 2014)
Legal consequences
In its 2014s quarter earnings conference call (Target 2014e,
p. 9), Target trumpeted ‘‘dramatically lower’’ breach-re-
lated costs as compared to post-breach external estimates
that had been more in line with Kindevag’s billion dollar
estimate. But, 3 months later, in the risk assessment section
of Target’s November 2014 10-Q filing to the SEC (Target
2014b, p. 9), Target identified many, still unresolved
potential sources for further costs and legal uncertainties.
… more than 100 actions have been filed in courts in
many states, along with one action in Canada, and other
claimshave been ormaybe asserted against us on behalf
of guests, payment card issuing banks, shareholders or

others seeking damages or other related relief allegedly
arising out of the Data Breach. State and federal agen-
cies, including State Attorneys General, the Federal
Trade Commission and the SEC, are investigating
events related to the Data Breach, including how it
occurred, its consequences and our responses…
Target customers’ numerous lawsuits were combined into a
single class action suit, to be adjudicated in a Federal District
Court in Minnesota. One of nearly 100 customer reports
included in the lawsuit described the damages and inconve-
niences suffered by one misfortunate Target customer:
[A Target customer] used her Savannah State Bank
Visa debit card to purchase goods at a Target store in
Georgia during the period of the Target data breach.
[The customer’s] personal information associated
with her debit card was compromised in and as a
result of the Target data breach. [The customer] was
harmed by having her financial and personal infor-

mation compromised. She incurred multiple unau-
thorized charges totaling approximately $1900 in
December 2013. [The customer] also experienced a
loss of access to her funds, paid a replacement card
fee for which she remains unreimbursed, and incurred
late payment fees due to failed automatic payments.
She also paid for credit monitoring services as a
result of the Target data breach. (United States Dis-
trict Court: District of Minnesota 2014, p. 23)
Estimates of the eventual total cost of fraudulent charges to
customer cards ranged from USD 240 million to USD 2.2
billion (Weiss and Miller 2015). Among the numerous
damages enumerated by customers’ lawyers were: unau-
thorized charges to debit and credit card accounts; theft of
personal and financial information; costs of detecting and
protecting against identity theft and unauthorized use of
accounts; lack of access to account funds; costs associated
with that lack of access (e.g., late charges and fees, credit

rating harm); time and loss of productivity stemming from
the need to deal with the challenges faced.
The customers’ lawyers accused Target of:
… failing to take adequate and reasonable measures to
ensure its data systems were protected, failing to take
available steps to prevent and stop the breach from ever
happening, failing to disclose to its customers the
material facts that it did not have adequate computer
systems and security practices to safeguard customers’
financial account and personal data, and failing to
provide timely and adequate notice of the Target data
breach (United States District Court: District of Min-
nesota 2014, p. 4)
That sameU.S.District Court inMinnesotawould adjudicate
another set of class action lawsuits, this time brought by
banking institutions adversely impacted by their own
customers’ misfortune. Because of contracts with payment

networks like Visa, historically the banks had shouldered the
bulk of the losses for credit card breaches. This time they
hoped, because of the retailers’ alleged negligence, more of
the responsibility would be assigned to Target. Estimates of
the potential fines thatmight be levied on Target ranged from
USD 71 million to USD 1.1 billion, numbers that repre-
sented anywhere from 2 to 37% of Target’s net income for
2013 (Weiss and Miller 2015). The American Bankers
Association estimated that the data breach affected more
than 8% of debit cards and …
T E A C H I N G C A S E
An IT outsourcing dilemma at Sick Kids Hospital
Ron Babin1 • Mohamed Shazadh Khan1 • Kyle Stewart1
Abstract This teaching case is based on a true situation at
the Hospital for Sick Children, in Toronto Canada. The

case asks students to either assume the role of the CIO or to
advise the CIO in making a decision to outsource IT at Sick
Kids Hospital. The case requires students to understand
three important issues: First, while health care costs con-
tinue to increase, automation of information is an important
opportunity to streamline patient care and reduce costs in a
hospital environment. Second, IT outsourcing, relying on
external service providers to deliver complex technology
services, is a fundamental business strategy across all
industries and has great potential in the health care indus-
try. Third, hospitals and health care have unique require-
ments for IT outsourcing, particularly the critical
importance of patient data security and privacy.
Keywords IT outsourcing � Hospital information systems �
Information systems security � Data privacy
Introduction
The Hospital for Sick Children (known as Sick Kids) is a
premier children’s hospital with a global reputation. It is a

tertiary institution, offering a large variety of specialist care
to children afflicted and affected by many serious medical
conditions. Founded in 1875, Sick Kids has grown from a
rented 11-room house to a 370-bed facility that carries out
leading edge pediatric medical research. Currently at Sick
Kids, the projected number of admissions per year is
16,500, treating over 100,000 patients per year and with an
annual budget of over $500 million.
Sarah began her term as CIO at Sick Kids in the
summer of 2015. After an initial review of the IT assets
including software applications, hardware, networks and
IT management, and professionals, she realized that a
number of critical IT services needed to be upgraded. Her
concerns were reinforced by a number of consulting
studies that had been commissioned prior to her arrival,
which recommended improvements in IT governance and
allocation of IT resources to support the existing systems.
One IT assessment report suggested that due to lack of

processes, multiple platforms, and aging information
technologies, ‘‘a much-needed overhaul is required in IT.’’
Another consulting study evaluated IT risk and concluded
that five out of seven areas were either medium or high
risk in terms of IT governance. Executive management at
Sick Kids were concerned that IT needed to be improved
and made more secure, to avoid outages and system
failures.
1
The executive management team were interested
in the benefits and costs of outsourcing, and had recently
held a discussion with an external advisor on this topic.
Selected slides from the discussion document are provided
in Exhibit A.
Sarah launched two important IT initiatives late in 2015.
Firstly, requirements were defined in order to issue a
request for proposal (RFP) to replace the core Hospital
information systems (HIS). The RFP was released in
& Ron Babin

[email protected]
1
Ryerson University, 350 Victoria Street, Toronto, Canada
1
In May 2017, computer systems in most UK hospitals under the
National Health Services (NHS) were shut down by a malicious
software attack. The attack gained access through outdated
software
running in most of the NHS hospitals. For more information see
https://www.theguardian.com/society/2017/may/12/hospitals-
across-
england-hit-by-large-scale-cyber-attack.
DOI 10.1057/s41266-017-0027-1
December 2015. By May 2016, the executive team had
selected an external HIS vendor.
Secondly, a key component of the RFP was a request to
operate or host the HIS outside of Sick Kids, in other
words, to outsource the operation of the HIS to an external
service provider. Members of the executive team were

developing an appreciation for outsourcing. The Peo-
pleSoft Financial and HR system had been installed by a
global consulting firm who had then proposed an out-
sourced application management service (see Exhibit B for
details). The HIS represents a healthcare-specific applica-
tion, while the PeopleSoft application is a more general
purpose system that supports organizations in many
industries. Table 1 below provides an overview of the two
systems.
Patient information within the HIS is governed by the
Ontario Personal Health Information Protection Act, which
defines the rules for collection, use, and disclosure of
personal health information. Most jurisdictions have simi-
lar laws in place, such as the Health Information Portability
and Accountability Act in the US and the Data Protection
Act in the UK. Personal information within the HR system
is also protected under government legislation such as
Canada’s Personal Information Protection and Electronics

Document Act.
The executives at Sick Kids expected that outsourcing
would reduce IT costs and improve the overall IT services;
the consulting firm had certainly given the impression to
the executives that IT costs could be significantly reduced.
For these reasons, Sarah realized that she and her IT
management team required a better understanding of the
risks and benefits of outsourcing as well as outsourcing
trends in the hospital and health services industry. She
needed to improve IT’s capability in order to continue
supporting core services and to help the hospital continue
its growth while maintaining its excellent global reputation
as a pediatric hospital. At a time when other hospitals and
large organizations were discussing Digital Transforma-
tion, Sarah needed to improve Sick Kids capability to
simply provide reliable IT services and keep the lights on,
and to support Sick Kids core services as it continues to
grow.

Healthcare spending growth
With the rising costs and budget restrictions to healthcare,
managers and CIOs of hospitals are always searching for
ways to reduce their costs and find a way to make their
organizations work more efficiently (Roberts 2001).
According to the Canadian Institutes for Health Informa-
tion (CIHI), the ratio of Health expenditures to GDP has
declined from 11.6% to an estimated 10.9% in the period of
2011–2015 (CIHI 2015). Hospital spending growth rate is
at 0.9% as of 2015 which is the lowest it has been since the
1990s (Canadian Institute for Health Information 2015).
Hospital expenditure per capita in Canada has increased by
3.5% throughout the period of 2014–2015 which is putting
a strain on managers and CIOs and forcing them to find
new ways to reduce costs.
According to the Canadian Institute for Health Infor-
mation (CIHI), total health expenditure was expected to
reach over $219 billion in 2015. This represents over

10.9% of Canada’s gross domestic product (GDP).
2
Despite this share reducing since 2009, there are still rising
costs within the healthcare sector. Hospitals account for
29.5% of total health spending which is continuing to grow
each year although the pace has slowed down over the past
few years. In fact, hospitals account for the highest portion
of Canadian healthcare expenditures with Physicians and
Prescription Drugs following behind at 15.5 and 13.3%,
respectively. Healthcare spending is expected to account
for $1804 per person in 2015. It is believed by the Cana-
dian government that ‘‘The possibility of technological
change could create cost savings due to process efficiency
or could generate cost increases due to new or expanded
diagnostic services and treatments’’ (Canadian Institute for
Health Information 2015).
The information systems support category increased
from 1.8% in 1999 to 2.4% in 2008 of hospital expendi-

tures.
3
A higher share for systems support may reflect the
increasing complexity and widespread adoption of elec-
tronic systems for clinical records, monitoring, and man-
agement of hospital functions.
The above literature shows that there is a slow increase
in healthcare spending and even in hospital spending itself.
With information support systems rising to 2.4% in 2008 of
hospital expenditures and 60% of the hospital spending
being used to compensate the hospital workforce, there lies
potential savings there are potential savings from labor cost
reductions for hospital IS support services. One suggestion
for cost savings and access to skilled information systems
support is the phenomenon of outsourcing.
Why outsourcing?
Executives typically expect outsourcing of IT services to
reduce costs and improve service through five enablers,
described below.

2
See Canadian Institute for Health Information (2015) National
Health Expenditure Trends, 1975 to 2015.
3
See Canadian Institute for Health Information (2012) Hospital
Cost
Drivers Technical Report.
82 R. Babin et al.
1. Economies of scale External service providers are
expected to have sufficient size that allows them to reap
the benefits of the economies of scale, for example in
running telecommunication networks or data centers or
software development centers. The economies of scale
allow a vendor to deliver the IT service at a lower cost
than an in-house IT organization.
2. Economies of skill Outsourcing vendors focus on a very
narrow range of services and concentrate their human
skill acquisition and development in those areas which

are their core competencies. Their core competencies, a
concept defined in 1990 by Pralahad and Hamel, will be
different than those required in a hospital, or any other
organization (Prahalad and Hamel 1990).
3. Technology exploitation Many outsourcing vendors are
also technology developers and manufacturers, and are
experts at exploiting ongoing technology innovation.
Moore’s Law typifies this innovation, which predicts
that the cost of computer processing continues to
decline by approximately 50% every 18 months.
4. Labor arbitrage Outsource providers are able to move
digital activities to global locations where labor costs
are lower. Thomas Friedman describes the IT labor
arbitrage model in his 2005 book ‘‘The World Is Flat.’’
(Friedman 2005)
5. Transaction cost economics Ronald Coase defined the
concept of transaction costs in his 1937 paper on ‘‘The
Nature of the Firm’’ where he proposed that when

market transaction costs for providing services are
lower than internal transaction costs, organizations will
choose to buy from external firms for those services.
Researchers have applied transaction cost economics
(TCE) to the field of outsourcing, notably Bahli and
Rivard (2003), Dibbern et al. (2004), and Ngwenyama
and Bryson (1999).
Outsourcing in health care
For years, healthcare organizations have outsourced non-
core departments such as food service and housekeeping.
Now, managers and health professionals are attempting to
reduce healthcare costs and they are turning to outsourcing
in new ways to obtain high standards of care while keeping
costs low (Moschuris and Kondylis 2006).
Outsourcing can provide hospitals with the ability to
focus on the core competencies and customers. If the
hospitals partner with industry IT leaders, they can achieve
greater efficiencies (Roberts 2001). As outsourcing by

healthcare organizations increases, the potential market of
vendors that can provide these services will also increase
(Burmahl 2001). According to Lorence and Spink (2004), it
is believed that the less the healthcare organizations use
outsourcing, the slower will be the development of indus-
try-wide standards and practices across vendors (p. 132).
Outsourcing can provide lower costs and risks, while
greatly expanding flexibility, innovative capabilities, and
opportunities for creating value-added shareholder returns
(Roberts 2001). Thouin et al. (2009) found under the
transaction cost perspective that IT activities that have
become commodities should be outsourced to improve a
firm’s financial performance. Kern and Willcocks (2000)
slightly agreed that outsourcing is driven by economic
action but that it is embedded within social relations and
organizational strategy. While in Menachemti et al.’s
(2007) findings, IT outsourcing was not a cost-lowering
strategy but instead a cost-neutral way hospitals would use

to implement an organizational strategy, Lorence and
Spink (2004) examined over 16,000 healthcare information
managers’ viewpoints on outsourcing and found that the
top two reasons why they purchase external information
resources were to improve patient care and to save money.
Table 1 An overview of HIS and Financial/HR systems
Hospital information system (HIS) Financial and HR system
Purpose Single secure source of information for a patient’s
medical
care history
Administration of financial and human information
Processes &
information sets
Patient information system
Prescription history
Operation history
Laboratory information
Radiology information
General ledger

Accounts receivable/payable
Expense reimbursement
Capital projects
Payroll
Benefits management
Pension management
Principle users Physicians
Nursing staff
Clinical staff (radiology, laboratory, pharmacy, etc.)
Corporate managers and supervisors in Finance,
Accounting, HR
Departmental managers and supervisors throughout
the hospital
An IT outsourcing dilemma at Sick Kids Hospital 83
Another advantage is the cost efficiency associated with
outsourcing due to economies of scale and of experience.
Because the outsource provider specializes in IT manage-

ment, it can provide good service levels at lower cost than
the internal IT department (Thouin et al. 2009).
A simplified view of different outsourcing layers or
levels is provided below in Table 2.
The experience of other hospital CIOs
Sarah had the results of an environmental scan which was
conducted in mid-2016 by a team of external consultants,
to understand current IT outsourcing trends in health care.
Semi-structured interviews were conducted with CIOs at
seven local hospitals. There was mixed reaction regarding
outsourcing of applications such as the HIS, which is the
core application at every hospital. Some hospitals maintain
and operate the HIS in-house and had retained staff who
were skilled at maintaining and operating the systems.
Others had outsourced the HIS and were convinced that
retaining current knowledge of the complex technology,
applications, and interfaces was beyond the ability of the
in-house staff.

CIO experiences: motivation for outsourcing
Across all seven interviews, the CIOs commented that
reduced operating cost was not the primary motivation for
outsourcing. The CIOS consistently identified three bene-
fits of outsourcing: (1) quality and speed of service, (2)
access to skilled resources, and (3) focus human resources
on strategic activities. Each benefit is described in more
detail below.
1. Quality of service and speed of delivery were the
reasons most cited for outsourcing. One CIO men-
tioned that IT infrastructure, which was the most often
outsourced, is a commodity service that vendors have
focused on delivering with a high degree of reliability:
‘‘we plug-in and expect it to light up,’’ ‘‘we don’t
worry about it, it’s a generic resource.’’
2. Access to skilled resources. One CIO commented
regarding software outsourcing that it would be
‘‘impossible for my staff to support an immensely

complex software application of six million lines of
code.’’
3. By outsourcing generic services, the CIOs are able to
focus their resources on strategic activities within the
hospital: ‘‘we didn’t want to be in that [IT] business…
We focus on strategy and architecture, and how to
improve the customer experience’’; ‘‘focus on devel-
oping relationships with the clinicians’’ and ‘‘new and
innovative use of technologies that are relevant to the
business’’; infrastructure ‘‘is not my role, my role is to
help the business transform and change.’’
CIO experiences: challenges of outsourcing
However, managing an outsourced service does have some
challenges: (1) outsourcing may cost more than in-house
services, (2) external service providers may not be strate-
gic, and (3) additional time is required to manage and
govern the external relationship. These challenges are
described below.

1. Although a few CIOs mentioned that outsourcing will
avoid future costs, for new staff or additional IT
infrastructure, every CIO mentioned that outsourcing
typically costs more than delivering the same service
with in-house resources. One CIO cited a 30% cost
increase for outsourcing. A few CIOs have chosen
selective outsourcing for highly specialized services,
where the financial case can be demonstrated to the
hospital board or when in-house skills cannot be
readily hired.
Table 2 Simplified view of outsourcing levels
Level Description Examples
3 Business processes Finance and accounting
Payroll
2 Application software and data General—office software such
as email, word processing, spreadsheets
Industry related—Finance, accounting, payroll
Location specific—Hospital information system
1 Infrastructure Servers

Network
Help desk
Device deployment and management (PCs, laptops, phones,
tablets)
84 R. Babin et al.
2. Outsource providers may not be innovative or strate-
gic, although they are very good at delivering a well-
defined service such as IT infrastructure. ‘‘I have to tell
them what I want’’ said one CIO, suggesting that the
external service providers are unable to anticipate
future innovation in the hospital sector.
3. Approximately 30% of management time was identi-
fied for ongoing management and governance of the
external providers. One CIO mentioned an outsourcing
contract where the vendor has 16% of total revenue at
risk if it fails to perform. To manage this contract, the
CIO stated: ‘‘You have to hold the vendor’s feet to the

fire.’’
CIO experiences: lessons learned from outsourcing
In terms of lessons learned, three stand out. First, managing
outsourcing, both internally and externally, takes time and
improves after several generations of contract experience.
Second, the governance of outsourcing is important, and it
requires involvement of the hospital senior executives and
potentially board members. Third, IT Infrastructure is the
most common service to outsource because the services are
more industry generic (e.g. help desk, PC support, network
monitoring) and less specific to a hospital.
What to do?
Sick Kids Hospital is at a turning point. It has recently
decided to acquire and install a sophisticated Health
Information System. It is seriously considering opportuni-
ties to rely on external vendors and outsource some or
major portions of the IT infrastructure operations. The
senior executives are searching for opportunities to reduce

cost and improve IT services, which may be realized
through outsourcing.
Sarah considered her options. Although she knew the
HIS vendor would install and start up the new system, she
had concerns about the long-term support costs, for
example the costs of servers and network within the hos-
pital as well as the costs of the failsafe mechanisms for
uninterrupted power supply and data redundancy that are
required in the hospital IT environment. She was concerned
about the ability of her staff to become knowledgeable and
capable of supporting and enhancing the software into the
future. This would become increasingly important as doc-
tors relied more heavily on the HIS for patient information,
and as the HIS became the central repository for all elec-
tronic patient data. As well, patient health data were
extremely sensitive, and many laws and regulations were in
place to protect the privacy and security of that data. Sarah
was a doctor herself and understood completely the

importance of the accurate and available electronic patient
information. Her decisions as CIO would have a significant
impact on the ability of her colleagues to deliver the best
care to patients at Sick Kids, as well as protecting Sick
Kids Hospital from significant risk and legal liability.
Apart from HIS, Sarah needed to address software
maintenance requirements for the PeopleSoft Finance and
HR systems: should the IT organization continue to support
these applications or should they outsource to an external
services firm? (Exhibit B provides more details) Finally,
Sarah needed to address the issues identified in the con-
sulting reports particularly about the multiple hardware
platforms, aging technology, data privacy concerns
regarding patient information, and security concerns
regarding reliable availability of the HIS. Could this be
outsourced to a single vendor and then consolidated to a
more manageable technology infrastructure? She also had
to consider the perspectives of her internal IT Managers;

see Exhibit C for an overview of their concerns regarding
outsourcing.
The CEO had planned an executive retreat later in the
year. One of the agenda items would be the strategy and
direction for the IT department, and the potential to engage
external service providers for more IT work. Sarah began
to prepare a discussion document to answer key questions
for the CEO at the executive retreat. Her presentation had
to set a clear direction for IT outsourcing at Sick Kids
hospital and had to address three topics:
A. Why would outsourcing of IT services within a
hospital be treated differently than similar IT services
in other organizations, such as a bank, a retail
enterprise, or a government organization? What effect
does this have on the decision to outsource IT services
or retain in-house at Sick Kids Hospital?
B. Assuming all data regulatory requirements can be met,
what are the issues that should be examined by Sarah

and the executive team when deciding to outsource IT
services or retain in-house?
C. What are the risks and opportunities for application
maintenance outsourcing regarding both the HIS and
the PeopleSoft finance and HR systems?
Appendices
Exhibit A: selected slides from executive discussion
on IT outsourcing
86 R. Babin et al.
Exhibit B
A recent internal analysis that examined options for Peo-
pleSoft Application Management Services (AMS) had
found the following. An AMS proposal had identified costs
of about $1.8 million per year, which would be approxi-
mately three times the current spending on in-house sup-

port for PeopleSoft. The proposal identified staffing levels
from a high of 14.4 FTEs to a steady-state level of 11.5
FTEs, approximately double the current Sick Kids support
staff of 6.8. The proposed AMS would be delivered by a
mix of onshore and offshore personnel based in India.
Table 3 below provides a comparison between the
external benchmark and internal costs. As the table shows,
the external per-FTE costs may range from 1.6 to 1.8 times
the cost of internal AMS.
Exhibit C: a workshop with IT staff at Sick Kids
A workshop was conducted with 12 senior managers of the
Sick Kids (SK) IT organization. The workshop was a
facilitated discussion to capture the perceived risks, chal-
lenges, and obstacles of outsourcing as well as the oppor-
tunities and benefits. Table 4 below presents the summary
comments from the workshop.

A few other interesting points surfaced during the
workshop. Sick Kids IT managers would not like to be at
the ‘bleeding edge’ of technology, but would like to be
abreast of current working technology. Consequently, they
were interested in refresh cycles, how often should
equipment and software be replaced and upgraded. For
Sick Kids, HIS may not yet be a commodity, and the area
of pediatric research, which is ever changing as new
developments and discoveries are made, may not be
suitable for a one-size-fits-all kind of software
commodity.
Table 3 Comparison of
internal costs to market costs for
PeopleSoft AMS
Sick Kids internal Proposal—high Proposal—low
Staff (FTE) 6.8 14.4 11.5
Total staff cost $636,000 $2,433,000 $1,717,000
Cost per FTE $93,500 $169,000 $149,300
Market cost above Sick Kids 1.8 1.6

Table 4 Outsourcing challenges and opportunities from the Sick
Kids management workshop
Risks, challenges, obstacles Opportunities, benefits
Quality will be compromised as there is no supervisory
oversight of
resources applied to tasks
Relationship with client (Clinicians) will not be there in an
outsourced
environment
Loss of control
SK is very early in the OS learning curve, consequently
capacity is not
there to properly manage outsourced contracts
RFP for any outsourced item may be deficient as there is not the
capacity
in-house to ensure that all considerations are taken into account:
may
result in many changes and hence cost increases
Outsourcing would necessarily mean a change in the financial
structure
Change management—managing user expectations of what the

outsourced environment will eventually become
The biggest risk is the culture change that would be needed as
culture of
silos changes to standardized
OS company may not be fully aware of infrastructure at time of
proposal
and even during implementation
Fear of not being able to design a successful governance
structure that is
appropriate
Speed of delivery of services
Would help to proactively make underlying infrastructure better
and
closer to leading edge as opposed to having outdated technology
Easier to scale and expand
Development of dynamic capacity
Economies of savings
Short-term increase in capacity
Allows in-house resources to focus on value added
Allows in-house resources to interface more with
clinicians/front-end

interaction with clients
Allows for resources to engage in requirements
gathering/education
Standardization
More availability of resources
Better equipped for disaster recovery
Less stress—would be able to sleep at night
Would be able to stay abreast of technology and data security
88 R. Babin et al.
References
Bahli, B., and S. Rivard. 2003. The information technology
outsourcing risk: a transaction cost and agency theory based
perspective. Journal of Information Technology 18 (3): 211–
221.
doi:10.1080/0268396032000130214.
Burmahl, B. 2001. Making the choice. The pros and cons of
outsourcing. Health Facilities Management 14 (6): 16–22.
Canadian Institute for Health Information. 2012. Hospital Cost

Drivers Technical Report. Retrieved from https://www.cihi.ca/
en/health_costdriver_phys_tech_en.pdf.
Canadian Institute for Health Information. 2015. National
Health
Expenditure Trends, 1975 to 2015. Retrieved from
https://secure.
cihi.ca/free_products/nhex_trends_narrative_report_2015_en.
pdf.
Coase, R.H. 1937. The nature of the firm. Economica 4 (16):
386–405. doi:10.1111/j.1468-0335.1937.tb00002.x.
Dibbern, J., T. Goles, R. Hirschheim, and B. Jayatilaka. 2004.
Information systems outsourcing: a survey and analysis of the
literature. SIGMIS Database 35 (4): 6–102. doi:10.1145/
1035233.1035236.
Friedman, T. 2005. The World is Flat. New York: Farrar, Straus
and
Giroux.
Kern, T., and L. Willcocks. 2000. Exploring information
technology
outsourcing relationships: theory and practice. The Journal of

Strategic Information Systems 9 (4): 321–350. doi:10.1016/
S0963-8687(00)00048-2.
Lorence, D.P., and A. Spink. 2004. Healthcare information
systems
outsourcing. International Journal of Information Management
24 (2): 131–145. doi:10.1016/j.ijinfomgt.2003.12.011.
Menachemi, N., J. Burkhardt, R. Shewchuk, D. Burke, and R.G.
Brooks. 2007. To outsource or not to outsource: examining the
effects of outsourcing IT functions on financial performance in
hospitals. Health Care Management Review 32 (1): 46–54.
Moschuris, S.J., and M.N. Kondylis. 2006. Outsourcing in
public
hospitals: a Greek perspective. Journal of Health Organization
and Management 20 (1): 4–14. doi:10.1108/14777260
610656534.
Ngwenyama, O.K., and N. Bryson. 1999. Making the
information
systems outsourcing decision: a transaction cost approach to
analyzing outsourcing decision problems. European Journal of

Operational Research 115 (2): 351–367. doi:10.1016/S0377-
2217(97)00171-9.
Prahalad, C.K., and G. Hamel. 1990. The core competence of
the
corporation. Harvard Business Review 68 (3): 79–91.
Roberts, V. 2001. Managing strategic outsourcing in the
healthcare
industry. Journal of Healthcare Management 46 (4): 239–249.
Thouin, M.F., J.J. Hoffman, and E.W. Ford. 2009. IT
outsourcing and
firm-level performance: a transaction cost perspective.
Information
& Management 46 (8): 463–469. doi:10.1016/j.im.2009.08.006.
TEACHING CASE
Lessons from attempting to backsource a government IT system
Nicholaos Petalidis1

Abstract Backsourcing is not a common term and refers to
the process of taking back development of a system that
was previously outsourced. Even though the term is not a
common one, the process that it describes is. Businesses try
to reverse outsourcing and start insourcing all the time. The
process however is not cost free and certainly is not paved
with roses. Herein we report from our own experience of
trying to backsource the development and maintenance of a
large information system, focusing on the technical prob-
lems encountered. The novel aspect of this paper is that it is
one of the few that provide insights into the specifics that
one has to include in any outsourcing contract, for back-
sourcing to be possible.
Keywords Code comprehension � Software maintenance �
Backsourcing � E-government � Technology management
Introduction
Backsourcing refers to the process of bringing previously
outsourced operations back. Backsourcing occurs when

outsourcing is deemed as unsuccessful, or when a company
wants to take back control of its own operations. Solli-
Sæther and Gottschalk (2015) reported that 34% of the
firms surveyed in the US and Canada had backsourced at
one point. Contrary to what one would expect then, the
literature looking into the problems of this process is scant.
Most of the published literature on the subject, like -
Akoka and Comyn-Wattiau (2006), Whitten and Leidner
(2006), or Wong and Jaya (2008), narrowly focuses only
on the reasons behind backsourcing.
Akoka and Comyn-Wattiau (2006) present a framework
to understand the antecedent of backsourcing and clarify
why organisations backsource. Similarly, in Whitten and
Leidner (2006) the factors that are associated with the
decision to backsource or switch vendors are examined.
Similar research is also presented in Wong and Jaya
(2008), which examines the factors that drive organisations
towards backsourcing.

In Solli-Sæther and Gottschalk (2015), a stages-of-
growth model is proposed and it is argued that the constant
move of services from an in-house function to an out-
sourced and offshored function and finally to a backsourced
function is an evolution path and not simply a return to the
beginning.
There are very few studies or case studies that look into
the problems that one can expect when attempting to
backsource: Butler et al. (2011) present a case study of an
organisation that had backsourced its IT department. The
authors look into the different phases of the backsourcing
process, concluding that the research on the transitional
phase from one mode of operation to the other has attracted
little attention so far.
Two case studies of IT backsourcing are also presented
in Kotlarsky and Bognar (2012). One of these studies
looked into the backsourcing of an IT service, whereas the
other one looked into the backsourcing of an IT product

development. The focus of both case studies, though, is the
process through which backsourcing occurred and not the
problems that the projects faced.
The challenges of backsourcing information systems in
the case of government organisations are presented in
& Nicholaos Petalidis
[email protected]
1
Department of Informatics Engineering, TEI of Central
Macedonia, Serres, Greece
DOI 10.1057/s41266-017-0026-2
Samsudin et al. (2012). The study is based on interviews
contacted with government agencies and focuses on the
process that an agency should follow, suggesting that a
knowledge transfer should start at least a year earlier from
when the actual backsourcing takes place. Finally, in Nu-
jen et al. (2015) a specific strategy is suggested to be fol-
lowed in order to re-integrate knowledge coming back into

the organisation.
Thus, with the exception of Samsudin et al. (2012)
and Nujen et al. (2015), all of the studies try to answer the
why of backsourcing, providing little insight into the how.
Nujen et al. (2015) on the other hand do not focus on IT-
specific problems, whereas Samsudin et al. (2012) present
findings from information gathered through questionnaires
from external observers.
This report, similarly to Samsudin et al. (2012), also
looks into the case of backsourcing an e-government ser-
vice. However, unlike Samsudin et al. (2012), it is based
on first-hand experience and presents the resultant guide-
lines to help avoid the problem of knowledge re-integration
and increase the chances of backsourcing success.
In the next section, the environment under which the
backsourcing was attempted is described, followed by a
section that presents the backsourcing attempt. Conclusions
are presented in the final section.

Background
Despite the push for the use of open source software in the
public sector during the later years, a large number of
government agencies still base their operations on custom-
made software that is outsourced to private contractors.
The case study in this report focuses on such a government
agency. The agency in question has a multitude of IT
systems, the development and operation of which have
been outsourced. The agency has an IT department, but so
far the department has tackled only the development of
considerably smaller projects.
The particular system to which this case study refers has
been under development for at least a decade. In its current
state, the system consists of a number of PL/SQL databases
and their associated Java-based back end with a Javascript-
based front end. Most of the logic of the system is however
implemented at the database level as stored procedures.
This is typical of many government IT systems, although

the one in question is probably one of the bigger ones in the
Greek public sector. For each new version, more than 3000
tables and 3 million lines of Oracle PL/SQL code are
added, even though it seems that a lot of it is simply copied
and slightly altered from previous years. The system serves
more than six hundred thousand citizens; at its peak it has
around 3000 concurrent users.
Architecturally, it consists of a number of diverse sub-
systems, each related to a specific function in the agency.
The outsourcing process
Each year, a new Request for Tenders is issued (RFT)
asking potential contractors to bid for the maintenance of
previous versions as well as for the development of new
functions required to take into account new government
regulations. The tender also lays down the legal, financial,
and technical framework for the required services.
The outsourcing process starts with the drafting of the
Request for Tenders. Each of the agency’s departments is

asked to fill in the relevant section regarding the new
functionality that will be desired for the next year. It is
quite common that the exact requirements for the next
year’s version are not known, mainly because the legisla-
tion is not ready yet, so in most cases the requirements are
quite vague, e.g. The software must conform to the direc-
tive XXX. On the one hand, having a too generic description
makes the process of cost and time estimations difficult; on
the other hand, having overspecified the requirements
might create problems if the final version of legislature
differs from the initial.
Once the functional requirements are gathered, one or
more software engineers are tasked with completing the
tender with non-functional requirements such as the system
architecture, adherence to standards, mode of delivery, and
training requirements. As a matter of fact, the list of such
non-functional requirements is longer than the one of the
functional requirements.

Quite often, however, the non-functional requirements
are routinely copied from the previous year’s tender to the
current year’s tender, given that not a lot changes in these
areas. The non-functional requirements typically include
generic statements such as
The system must be parameterisable, modular and of
an open architecture.
The tender also tries to make clear that any source code
developed for the project is owned by the agency and not
by the contractor. To this end, statements such as the
following are included in the tender:
For any modification to the system, the source code
should be delivered to the agency. The source code is
property of the agency. Any modifications will be
accompanied by associated documentation describing
the implemented functionality, the data structures and
its dependence on other parts of the system.
The general understanding in this and other tenders as

mentioned later is that ownership of source code ensures
Lessons from backsourcing an IT system 91
that the agency is not tied to any particular vendor for
maintenance or extensions of the system in the future.
A committee is responsible for making sure that all the
requirements laid out in the tender, as well as the signed
agreement, are met. The committee usually consists of
people from the departments that will be using the system
as well as at least one from the agency’s IT department.
At predefined points in time, the contractor submits the
required artefacts and the committee ensures that they are
according to standards. When the software is finally
delivered, the committee’s focus is usually on ensuring that
it conforms to its functional requirements. After all, the
running software is the artefact to watch for. From our own
experience, other artefacts like documentation or source
code were noted but were rarely examined with respect to

their quality or usability.
During the system’s development, there is a close co-
operation between the agency’s departments and the con-
tractor in order to lay down the specific functional
requirements. The agency’s IT department has a small part
in this, as most requirements are communicated directly
from each of the departments to the contractor in various
forms: word documents and e-mails, which are a common
form of requirement exchange. An issue-tracking system is
in place but not always used.
Outsourcing perceptions
The process that was described previously is not unique,
but it is similar to the way outsourcing takes place in many
government agencies. As a matter of fact, we have
reviewed five more requests for tenders, published by
various agencies of the Greek public sector. The main
procurement requirement for all of them was the devel-
opment of a software system and a total budget that

amounted (for the five of them) to more than 11,000,000,
i.e. they were large and complex systems. They all con-
sisted of multiple subsystems and had to be integrated with
existing systems. Moreover, they required the contractor to
pass ownership of the source code developed for the pro-
ject to the procuring agency.
The tenders were about projects from different services in
the public sector, handling different problems: These ranged
from information systems handling digitisation and encod-
ing of rules for managing Social Security benefits, to Man-
agement Information Systems and workflow management.
In all of these tenders there is a common pattern:
• The contractor is responsible for drafting the require-
ments document.
• The main documentation required by the contractor as
far as the system’s design is concerned is an ER
diagram (or class diagram in some cases).
• In all of the calls, there is a requirement for a modular
solution but this seems to refer to the communication of

the system under development with the rest of the
agency’s systems. For this reason, all calls require
adherence to the Greek e-Government Interoperability
Framework (see http://www.e-gif.gov.gr/portal/page/
portal/egif/) or the more abstract European Interoper-
ability Framework, which describe, among other things,
the standards that need to be followed when interacting
with external systems (web services guidelines) but
make no reference to the internal design.
• There is no specific requirement for the system itself to
be modular, other than being separated into three layers
(presentation, business, and data).
• The database seems to be the central point of connec-
tion with everything else. This is evident in the calls
themselves where the requirement for separate modules
is in contrast with the database-centric approach they
all imply: All calls made reference to the presence of a
single database. One of the calls literally enforced it as
a requirement. Another call made it clear that the

database was to be considered as the point for
information exchange:
Technical description of the database schema (logical
and conceptual design) (is required to be delivered) in
order to be able to interconnect the application with
third party systems.
and even went further on explicitly accepting that, even
though the source code is owned by the agency, ‘‘...Before
any such intervention (to the database) the contractor’s
opinion will be requested’’.
• None of the calls put any specific requirements on how
the source code will be delivered and what should be
part of the delivered code. Unit tests were not explicitly
mentioned as part of the source code in any of the calls.
One may argue that this is implicitly assumed but it is
our experience that it is not even when the contractor
proposes an agile methodology for the product’s
development. No adherence to a coding standard was
mentioned.

• All calls stated the requirement for the performance of
user acceptance testing without, however, any distinc-
tion between manual and automated tests.
• None of the tenders requested any artefact describing
the deployment procedures and there was no require-
ment for the contractor to deliver automated deploying
procedures for any of the systems developed. In cases
where training was required, this mostly referred to
end-user training or everyday operation training.
• None of the tenders required the contractor to deliver
the whole history of the source code, and there was not
92 N. Petalidis
even a requirement that such a history should be
maintained. There was no reference either to maintain-
ing an issue management system or to any deliverables
related to configuration management.
• In all cases, the contractor could choose its own
methodology for managing the project. There was no
requirement that the government agency will have to

participate in design meetings with its own personnel.
In all tenders, the contractor and the agency would have
to co-operate during the drafting of the requirements as
well as the general working plan, but no other form of
co-operation was described. There was no requirement
for the contractor to submit the updated project plans or
any other project information once the project
concluded.
The backsourcing process
Typically, the procurement process described previously
should have given equal chances to all prospective bidders.
The reality, however, was that the bidder who developed
the initial version of the system had much better chances of
succeeding. It had a better understanding of the architec-
ture, so maintaining the previous versions of the system
required considerably less effort than of any new player.
Similarly, any new functionality developed would have to
be connected to the existing one, so again the original

designer had an unfair advantage over the other bidders. In
essence, the agency had fallen in the trap of the vendor
lock-in.
For these reasons, and in order to avoid the problem of a
vendor lock-in for future tenders, the agency decided to
form a team with the purpose of laying out the required
steps to backsource the system’s design. A successful
outcome would lay out the foundations for outsourcing,
during the next years, only specific parts of the system,
keeping development of important features in-house. The
team consisted of two software engineers, a database spe-
cialist as well as two more members who have been
involved with drafting the tenders or outlining functional
requirements during the previous years.
Division into knowledge areas
It was clear from the start that backsourcing a project
meant that knowledge pertaining to all of its aspects had to
be transferred back to the agency.

It was conjectured that all software projects go through
some form of requirements capture and analysis, design of
system architecture, implementation and testing, and
finally deployment, irrespective of any development
methodology followed. Of course, different methodologies
might perform these sequentially, iteratively, or incre-
mentally giving different emphasis to them in different
stages, but the fact remains that, more or less, this is what
goes on in a software project. In parallel with these, two
more disciplines that cut across all of them were also
considered to be of importance: that of the software con-
figuration and change management as well as the project
management itself (see Fig. 1).
In the following, we report the problems we encountered
when attempting to transfer knowledge back to the
organisation for each of these disciplines and the lessons
learned.
Discipline 1: requirements capture and analysis

The main purpose in this discipline was to gather infor-
mation regarding the business domain and modelling. The
team’s task was to gather all requirements and understand
the business model. Given that the agency itself specified
the requirements, this should have been an area with no
problems. Indeed, each department provided a list of
requirements on which the system was developed. Unfor-
tunately, it was also revealed, during the investigation, that
some of the requirements were also informally put across
to the contractor through e-mails, whereas the same went
for bug fixes or other problems. Discussions also revealed a
number of hidden requirements. So a lot of effort was made
to gather them into one place.
A requirements document, for each of the subsystems
implemented, was also among the deliverables the con-
tractor produced. However, these documents recorded the
end-user requirements but nothing that would describe the
actual business processes. For example, there was plenty of

information on what each field in a form represents, but no
description of how the data submitted to the form should be
processed. Similarly, there was no information that would
describe the flow of information between the subsystems.
In essence, the contractor’s requirement document was a
user manual. Overall, the team felt that the time spent on
this discipline was a lot more than what was planned for,
Fig. 1 Project’s disciplines where transfer of knowledge was
deemed
important
and a lot of new knowledge had to be produced and not
merely transferred from the contractor to the agency.
Discipline 2: system design and architecture
The main purpose in this discipline was to understand the
design of the system, identify its separate subsystems,
isolate them, and start working first on the ones that were
deemed critical. The main task of the team was to map

software constructs (database schemas, groups of stored
procedures, and so on) to the identified subsystems and
understand design decisions. For this reason, the team
started looking thoroughly into the design documents the
contractors produced as well as the database structure.
All of the design documents delivered were entity
relationship (ER) diagrams. However, these were found
inadequate and proved of little help to the process of
understanding the system design and architecture.
Another point that presented difficulties was the fact that
all communication went through the database. Most of the
subsystems seemed to have direct access to tables; the ones
that did not were accessing it via stored procedures. Given
that the system included thousands of them (tables or stored
procedures), it was practically impossible to view one sub-
system independently of the others and understand it.
Discipline 3: implementation and testing
Focus here was on understanding implementation issues and

being able to purposely alter the behaviour of the system for
specific use cases. The team started gathering the source
code, attempting to execute it and debug it. In order to be able
to do any of these of course, one would need to comprehend
the code. The first main hurdle was the lack of any descrip-
tion on how to set up the necessary development environ-
ment. The requirement for the inclusion of this information
in some deliverable by the contractor was a serious omission
that created major problems. Apart from an actual develop-
ment environment, missing libraries also hindered the
attempts to produce an executable.
A critical issue was the high degree of coupling we
mentioned already when looking into the design: All intra-
module communication in the systems we examined took
place through the database, making it extremely difficult to
implement changes without the fear of breaking some
unrelated subsystem.
Another issue that might seem minor, but created

comprehension problems, was the lack of any standardis-
ation across the delivered code.
In addition, a lot of the front end Javascript-based code
was automatically generated by code generators. Code
generators are very useful since they can automatically
produce code and have been in use in software engineering
for quite some time: a parser generator will nicely produce
a parser for a specific grammar. One of their drawbacks,
however, is that they frequently produce unreadable code,
since it was assumed that humans will rarely need to alter
the generated code, and only modify the template through
which the code was generated. However, neither the gen-
erator nor the templates used to generate the code were
delivered.
A final problem that was uncovered was that it was not
clear what constituted ‘‘source code’’. The contractor only
formally submitted the JEE back end and the Javascript
front end. The bulk of the business logic, written in PL/

SQL, was never submitted as a separate deliverable.
Instead, it was assumed that since one could access the
code in the production servers, no separate deliverable,
containing it, needed to be submitted. However, the code
there was mixed with other PL/SQL code used by different
back ends from previous versions of the system. Extraction
of the source code was then not a straightforward
operation.
Discipline 4: deployment
The purpose in this discipline was to be able to deploy the
system in a QA environment and be able to exercise it in a
realistic environment. Deployment procedures are
increasingly complex these days. It is a matter of setting up
load balancers, caches, clusters, a number of linked data-
bases, configuring parameters, and so on. Even the process
of setting up the environment for development purposes
might be daunting, especially if one needs to set up the
necessary initial data to fill into a number of different

schemas, fix the parameters on the application servers, and
locate the correct version of libraries. Thus, knowing how
to deploy the product is a mini-project by itself, one that is
frequently left out in outsourcing contracts. In this partic-
ular case, it also turned out that there was no clause that
required the delivery of any sort of documentation or
scripts from the contractor that would ease deployment
procedures. Access to the actual production system was
possible and shed some light but it was extremely time
consuming to isolate the exact environment needed. After
all, production systems were configured to support a mul-
titude of products and not only this particular one. In fact,
the difficulties faced in this stage were the reason for the
decision to abandon the project; the timeframe required to
find out all the necessary parameters was prohibitive.
Discipline 5: configuration and change control
management
The purpose in this discipline was to gather all of the

system’s versions and associated issues and try to match
94 N. Petalidis
the code changes with any change requests. In this case, as
in many others, there was no obligation by the contractor to
deliver the full history of the source code, but only its final
version. This was true, even though the system was in
operation before the final version was delivered, and there
was no way to check the source code used to implement
these operations.
Similarly, an issue-tracking mechanism was in place,
but not all change requests went through it.
Discipline 6: project management
Backsourcing a project is related to a lot more than just
transferring it in-house. It actually means that the project
also needs to be managed in-house; it has been frequently
noted that project management practices are key to a
software project’s success; see for example Kwak and

Stoddard (2004) and Art Gowan Jr and Mathieu (2005). In
the particular case presented here, it was expected that the
project will be managed and supervised by in-house
personnel.
For this reason, historical project data had to be gathered
and estimates had to be made regarding costs and activity
durations. Unfortunately, though such data were not part of
any project deliverables. Of course, it was possible to get
an idea of the total cost and duration based on the costs of
the outsourced project. However, these were too coarse-
grained. There were no estimation records for particular
subsystems, e.g. ‘‘how long it will take to implement sub-
system X’’. Similarly, it was not possible to have an idea of
the risks associated with a particular functionality or sub-
system. In general, the organisation was lacking one of its
most important assets for project management: lessons
learned and historical data.
Aftermath

Given the difficulties faced, the backsourcing attempt had
to be abandoned because it could not be realised in the
required timeframe. At that point, the amount of work
completed for each of these disciplines is presented in
Fig. 2. Note that the two disciplines (Configuration and
Change control management and Project Management) that
cut across all disciplines are not shown since the work there
is included in the work completed in the other four
disciplines.
The total cost of the backsourcing attempt was at that
point at the 4.5% of the cost of the latest outsourcing
contract. The effort distribution across the disciplines is
presented in Fig. 3.
Thus, our experience agrees with Samsudin et al. (2012)
that backsourcing should start at least a year earlier. Since
the main problem was that not enough care was put into
drafting the initial contract and laying out the contractor’s
requirement, it is of crucial importance that these should

not be overlooked by anyone planning to backsource at
some point his/her information systems.
Conclusions
Backsourcing an IT system requires that knowledge needs
to be transferred back from the contractor in-house. Even
though a lot of tenders and contracts theoretically take
measures for ensuring that such an information transfer is
possible, we found out that indeed this is extremely
difficult.
The most important of the delivered artefacts, aside
from the actual product itself, is the source code, but the
code that you do not comprehend is the code that you do
not really own. Developers need to understand the code, or
at least some part of it, before they can extend its func-
tionality or fix its errors. They need to be able to recognise
modules that can be reused, or modules that need to be
updated. If they cannot do these things, code ownership is
just an issue relevant to lawyers that might want to argue

over copyright, but of little practical value otherwise. We
believe that one of the reasons that government agencies
Fig. 2 Work completion on each of the disciplines
Fig. 3 Effort distribution across the different disciplines
find it easier to request the development of information
systems from scratch, even when they could have reused
existing software is exactly because code comprehension is
quite low in many projects.
We concluded that in order for backsourcing to be
possible steps should be taken, early on when tenders are
drafted, to ensure that any information produced during the
project is correctly registered and communicated to the
agency.
Questions
• Since it was the agency’s departments that drafted the
requirements, why there was such a problem in

transferring this knowledge back to the organisation?
• Why having all subsystems communicating through the
database is a problem? How one would tackle the
problems uncovered during the review of the system
design and architecture?
• Why were ER diagrams considered inadequate? Dis-
cuss on the perceived usefulness of diagrams in design
documents.
• Think about how do software engineers understand
code. What kinds of artefacts and which practices
would have helped the engineers better comprehend the
code?
• How important, do you think, is the presence of source
code history in comprehending source code? How this
should affect …

TEACHING CASETargeting Target with a 100 million dollar da.docx

Recommended

Recommended

More Related Content

Similar to TEACHING CASETargeting Target with a 100 million dollar da.docx

Similar to TEACHING CASETargeting Target with a 100 million dollar da.docx (20)

More from erlindaw

More from erlindaw (20)

Recently uploaded

Recently uploaded (20)

TEACHING CASETargeting Target with a 100 million dollar da.docx