Rise and Fall of an Information Technology Outsourcing Program: a qualitative Analysis of a Troubled Corporate Initiative

Supply chain software development. 
What would eventually become known as the 
Strategic Staffing Program (SSP) was the transition of all business analysis, project management, 
and engineering work performed by ninety-three employees and two hundred (mostly TechStaff) 
staff augmentation contractors for Supply Chain software development to a single vendor. The 
vendor’s name, as used here, would become ComTech, and the intention was that it would 
operate under a managed services agreement. As discussed in Chapter One, firms enter into 
managed services agreements to fully outsource a section or sections of their organizations. The 

---

119 
vendor essentially owns these capabilities rather than simply augmenting the client’s staff, and is 
given a higher degree of autonomy to manage its staff accordingly. 
The Supply Chain systems were used to manage and automate product movement and 
storage in warehouses, keep track of inventory, and manage order fulfillment to customers 
ordering from Icarus’s website. One executive recalled the apparent “correctness” of the decision 
to outsource this work: 
[Supply Chain software development has] been an area where we haven’t had the IP 
[intellectual property] in-house. It’s a niche technology, complex, [and it is] hard-to-find 
talent that knows this stuff well. Also, [it is] something that our vendor partners [primarily 
TechStaff] had been managing for us for a while [under Project Phoenix]... yet our 
[systems’] performance had not been good. We were having just too many issues with the 
systems. Because of distributed ownership of the various systems, some of it’s owned by 
one-by-one vendors, [and] some of it was done by team members. There wasn’t...enough 
IP in [Icarus]. It became a classic candidate where we said, “Hey, if we were to give this 
out to somebody it would run [better] for us [and] help manage our total [number of system 
outages] down. Also, [it could] free up resources who were tied into this but were not 
necessarily experts in that space.” It just made a lot of sense. (Executive, personal 
communication, June 27, 2013) 
To executives besides Richard and Donald, the evidence supporting Supply Chain software 
development as the area to outsource was convincing. These factors included a lack of a 
substantial employee knowledge base of the systems and the difficulty to find talent to support 
the systems’ “niche technology.” Interestingly, Icarus already used TechStaff (albeit in a staff 
augmentation model under Project Phoenix) who apparently struggled to perform up to 

---

120 
executives’ expectations. It is somewhat surprising, then, that executives agreed that another 
vendor could perform better than TechStaff under an even more complicated and risky managed 
services construct. Note that this executive also suggested that Icarus could bring in a vendor 
that “run it better than us,” despite the deep, contradictory belief within the Icarus habitus that 
“nobody does it better than us.” Another executive added: 
We came up with a notion of piloting a managed-service partnership...the space that we 
suggested and offered was [Supply Chain software development]. The reason we picked 
that space was because the [primary software] asset that we have in that space is a 
homegrown application that struggles with its stability and needs to be managed and 
eventually rewritten... [Supply Chain software development] was essentially in the 
background. There was not a lot of work we did for it. The work that we were doing was 
core maintenance and small enhancements. It was not big profound work, and it felt like an 
easy test of a managed [services] partnership because there wasn’t any major critical work 
happening in that space and was planning to happen in that space. (Executive, personal 
communication, August 29, 2013) 
The last comment is the key qualifier for the executives quasi-groupthink belief supporting 
Supply Chain software development as “non-differentiating,” “It was not big profound 
work…there wasn’t any major critical work happening in that space and was planning to happen 
in that space.” Although executives acknowledged that the Supply Chain systems were critical to 
Icarus’s operations, they did not view the Supply Chain as something driving competitive 
advantage for Icarus. As this executive noted, there were no major, highly visible, projects tied to 
Supply Chain at the time. 

---

121 
The major issue executives were focused on solving was their assumed capacity problem 
within the constraints of not being able to increase the number of IT employees. They had 
constructed the GSM as a staffing guide and their hubris seems to have convinced them that 
(despite Project Phoenix’s shortcomings) they could implement an even more complicated 
managed services agreement and redeploy Supply Chain employees to other “differentiated” 
assignments. 
Through the lens of the GSM—which considered “differentiation” rather than the 
criticality of the work—most executives were not hard to convince that Supply Chain software 
development was the right place to try SSP. Nevertheless, the ultimate designation of Supply 
Chain as non-differentiating points to a major blind spot among both Icarus IT and business 
leaders to the importance of their Supply Chain systems to remain competitive in the twenty-first 
century retail field. Furthermore, the decision to outsource Supply Chain development, at a time 
that this business capability was actually becoming central to Icarus's digital retailing strategy, 
would prove to be a slow-festering mortal wound to Richard and other IT executive’s careers.