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

The beginning of the end. 
In mid-2013, ComTech contractors began the process of 
knowledge transfer by reviewing formal process documentation, application specifications, and 
computer code. Additionally, they spent considerable time meeting and interviewing impacted 
Icarus employees to get up to speed on the work they needed to perform. In addition to taking 
over the Supply Chain software engineering, which many Icarus executives by then considered 

---

187 
critical and differentiated, ComTech started their formal work with Icarus amidst a political 
spectacle that stemmed from Richard’s and Brenda’s differences. The demotion of SSP within 
the IT organization created an anomaly (Kuhn, 2012) that disrupted established taxonomic power 
structures (Lincoln, 1989) and led to Brenda’s failed attempts to intervene via backstage 
(Goffman, 1959) escalations to Jack. Individuals either supported or resisted SSP depending 
upon if they were members of Richard’s or Brenda’s team. This context would prove to be an 
additive challenge for ComTech during the early implementation phase given vendors’ general 
role in the overall Icarus IT taxonomy and habitus (Bourdieu, 1972/1977), first discussed in 
Chapter Five. 
By the time Richard signed the SSP contract with ComTech in mid-2013, the program 
was in its third year and had yet to deliver any evident benefits. Although ComTech had little 
prior experience with Icarus, Richard pressed to transition work as quickly as possible. For their 
part, ComTech possessed limited access to social or cultural capital (Bourdieu, 1983/1986) 
beyond support from Richard, which was on uncertain footing given the anomalies to SSP and 
persistent resistance from Brenda and much of her Business Strategy Team. 
As Brown and Duguid (2000) suggested is the case with knowledge workers, Icarus 
employees learned both the processes for working in the IT environment and appropriate day-to-
day cultural practices to perform their jobs through years of hands on experience in quasi-
apprenticeships with tenured IT workers. In most cases, this knowledge was undocumented and 
not formally codified, making it difficult for both Icarus and ComTech to know with any 
certainty that comprehensive knowledge transition had actually taken place. Furthermore, 
ComTech employees recognized the risks of assuming the finality of transitioning years of 
undocumented knowledge in a matter of weeks and months. Despite access to substantial 

---

188 
information on the Supply Chain applications, ComTech’s employees lacked the needed time 
and “on the ground” experiences to transform that “know of” into practical “know how” (in 
Brown and Duguid’s terms) during their early onboarding. One Icarus engineer discussed 
ComTech contractors’ obstacles: 
The biggest immediate term challenge I think is just transitioning all of that knowledge 
on those legacy applications, because what I’m finding with all of the multi-channel stuff 
[i.e. digital retailing] is I’m having some pretty complex questions about specific legacy 
applications. One dumb little thing in a legacy application could drive the whole direction 
of where a project or idea is going. So sometimes it takes a bit to tease that out of a BA 
[Business Analyst] or an engineer. 
Here’s really what I’m getting at. I can’t imagine being able to tease that kind of 
information out of someone who just started learning [legacy Supply Chain applications] 
two months ago. There are going to be moments when questions will need to be answered 
about applications and the [ComTech] resources aren’t going to be the one to ask. It’s 
going to be an Icarus resource, and those people, after October, November, December of 
this year, are going to be located potentially even in other pyramids [Icarus departments], 
and so how do you easily get on their radar screen? (Employee, personal communication, 
August 30, 2013) 
Prior to and during the Phoenix Era, Icarus and TechStaff employees had built and learned the 
informal and tacit knowledge of how these applications worked. They made sense of and used 
that knowledge over a number of years by working in quasi-apprenticeships with more 
experienced engineers. The legacy Supply Chain applications were built or implemented five, 
ten, or even fifteen years or more in the past. Many of these applications were still in use and had 

---

189 
undergone significant incremental change and customization following their initial creation. 
Even one member of the SSP Working Team in charge of implementing the new interaction 
model (first mentioned in Chapter Six) noted that Richard’s expectation for ComTech engineers 
to become as effective as existing Icarus and TechStaff engineers over a few months was 
untenable: “Would you expect a team member to come in and in three weeks and understand 
everything about your portfolio, tell you how they were going to run it, when they would do it, 
and how fast they would do it?” (Working Team Member, personal communication, August 19, 
2013).
Although Richard’s performance expectations of vendors may seem unrealistic, they 
were culturally acceptable at Icarus. One executive alluded to these expectations in Chapter 
Seven, noting, “You manage these vendors harder than you could possibly believe, and the 
results, if it’s set up right, are phenomenal” (Executive, personal communication, July 23, 2013). 
This reflected executives’ commonly transactional view toward vendor relationships as opposed 
to the accountability they demonstrated toward their employees. Within the Icarus habitus, 
employees and executives viewed vendors as a form of economic capital (Bourdieu, 1983/1986). 
However, by the time ComTech’s contractors were starting to work on the SSP contract, many 
employees and executives had built up defensive views against any vendor taking over the 
Supply Chain development work. There was a general tendency among Icarus employees and 
executives who did not support SSP to try to catch ComTech doing something wrong almost 
immediately. Another Working Team member observed how some Icarus executives and 
employees were holding ComTech’s engineers to a higher standard than would be expected of 
new employees who had just joined the IT team: 

---

190 
It’s [ComTech’s onboarding is] going probably as well as it should be going at this point, 
to be completely honest. However, because we already have resistance and we are 
looking for things that are going wrong, we are picking out individual knowledge 
acquisition sessions that aren’t going well and calling that SSP [related]. I think the 
reality is, is that we’re having a really hard time letting go of the fact that someone is 
going to come in and they’re going to do it different than us...Even up to a VP [vice 
president] perspective, we’re giving feedback on the [PowerPoint] template pictures, the 
way in which they’re putting words on a paper even though the words themselves are the 
message. 
On one hand, we’re saying, “They’re going to do things differently. We need to 
do things differently. We need to be more agile. We need to do all these different things. 
We hired them because we believe that they can do this as well, if not better than what 
we’re doing.” But then when you translate that . . . at a senior manager level, it means, 
“You just hired someone to replace me that you think can do better than me. If you think 
they can do better than me then I’m going to tell you every nook and cranny on what 
they’re not doing that’s as good as me.” Those are the dynamics. They’re there every day. 
They’re the everyday dynamics. (Working Team Member, personal communication, 
September 3, 2013) 
Icarus IT employees’ penchant for “laying in the brush” to ambush ComTech on seemingly 
trivial matters was tied to the Icarus habitus as it related to the role of contractors established 
during the Phoenix Era. This Working Team member noted the overly critical manner in which 
some impacted employee managers provided feedback to ComTech. Some employees even 
complained about the style of PowerPoint presentations used in different meetings as a way to 

---

191 
resist the transition to ComTech and retain some sense of control over their work. Rather than 
having the opportunity to apprentice with tenured Icarus engineers to develop “know how” of the 
Supply Chain systems, ComTech’s engineers were excluded from the collaborative problem 
solving, storytelling, and improvisation settings that Brown and Duguid suggested is needed to 
close the gap between the routines of “process” and the reality of “practice” (2000). 
ComTech faced the paradox of being hired under a managed services agreement but not 
being granted the initial autonomy or access to operate under this type of contract. Despite the 
infocentric flaws of the interaction model (discussed in Chapter Six), ComTech’s (and SSP’s) 
success still required willingness from Icarus employees and executives to allow ComTech to 
implement these new processes as per the new paradigmatic staffing model under which it had 
been hired. However, in spite of the effort the Working Team put into developing the interaction 
model, it was largely ignored by other IT teams: 
In the Icarus culture, it’s very important not to share your opinion, unless you’re 
absolutely sure that everyone’s going to agree with you. So it comes back to SSP, 
because the [ComTech] guys really don’t know what to do with this, because they’re 
looking to us for opinions, and they’re getting them. But the assumption that the Icarus 
folks are making is that [ComTech] will not disagree with this opinion, because this 
opinion is something that everyone at Icarus agrees with. Specifically with respect to the 
intake process and the portfolio planning process, and all of this [interaction model 
between Icarus and ComTech], that we’re trying to document. It’s like Icarus has come in 
with a process that is frankly broken, or never worked that well in the first place. 
[ComTech] just came in originally, I think, with the idea that, “Yeah, it’s one of the 

---

192 
reasons why [Icarus] bought us, because they want us to come in and make this whole 
thing more efficient.” 
It was absolutely clear in the room from the get go, “No, [ComTech], you will 
adopt the ‘as is’ [Icarus] process. [You] will do that. [You] will get that right for at least a 
year or two, and then we can start talking about how to improve that process.” They’re 
very diplomatic. They’re very, very diplomatic, and so they would say, “Well, Icarus’s 
culture obviously works. We understand the benefit of just adopting it hook, line, and 
sinker, at least in this initial phase.” (Employee, personal communication, August 30, 
2013) 
Understandably, but to its eventual detriment, ComTech acquiesced to Icarus’s feedback in these 
early situations. Unfortunately for ComTech executives, their consent to these pressures 
reinforced the beliefs of SSP’s non-supporters that ComTech would be unsuccessful under a 
managed services agreement at Icarus. In addition to their aforementioned submission to the 
“Icarus way,” ComTech executives admitted some missteps of their own during their first 
months at Icarus. Although they were not directly interviewed for this study, my personal 
observations of their most damaging setbacks included the protracted replacement of contractors 
where there appeared to be legitimate performance concerns, and considerable turnover among 
the top ComTech executives who needed to forge strong relationships with Richard and his 
peers. The “revolving door” of ComTech contractors and executives combined with the 
accelerated technical knowledge transition and growing cultural resistance across the Icarus IT 
department marked the “beginning of the end” of SSP’s chances for success.