olly - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Mistakes CIOs make on IT outsourcing deals -- and how to fix them

CIOs don't sign on to large IT outsourcing deals expecting them to go bad, so what accounts for the high failure rates? Andy Sealock offers a game plan for de-risking your deal.

Andy Sealock, managing director at outsourcing advisory firm Pace Harmon, specializes in planning, fixing and terminating large, complex IT outsourcing (ITO) transactions. Like snowflakes, no two IT outsourcing deals are the same, he said, but when they unravel, reasons for failure invariably fall into three buckets: errors in outsourcing strategy, errors in the contracts and errors in post-deal governance.

In part one of this three-part SearchCIO tip, Sealock takes CIOs through the first of the three ITO failure points -- IT outsourcing strategy -- and offers advice on how to mitigate risk by knowing what to outsource and what to keep in-house.

Retain architecture, technical expertise

Andy Sealock, managing director, Pace HarmonAndy Sealock

Large IT outsourcing deals go awry when companies lose control of their IT service providers. Over the years, Pace Harmon has found that -- regardless of the deal -- ITO engagements generally work better when clients retain two key functions: architecture and IT Service Management (ITSM).

"In many of these outsourcing deals, the thinking is: 'The service provider has made all these investments in understanding technology and understanding architecture -- we'll let them drive innovation for us,'" Sealock said. That ITO strategy may sound good on paper, but financial realities often intrude; innovation is the first thing to go when providers are under pressure to maintain margins, Sealock said. There is another danger in ceding your enterprise architecture responsibilities to the service provider.

"You experience a brain drain. Your good technical people don't really want to sit around just being contract administrators; they want to be architects," Sealock said. Good technical architects are hard to come by and highly paid. "They have plenty of choices and plenty of places to go." Indeed, losing top-notch architects is one reason companies turn to an outsourcing relationship, but not having technical in-house expertise is a "trap," according to Sealock.

"Once you really lose the understanding of your technical architecture, it becomes too easy, quite frankly, for the service provider to pull the wool over your eyes," he said.

Keeping control of your architecture function doesn't mean CIOs shouldn't tap their providers for good ideas, Sealock said, but CIOs must own their technology choices. "The service provider is playing more of a tactical role, engineering and operating the architecture you design and which you understand better than anyone else in the world," he said.

Retain ITSM, operational expertise

Keeping ITSM in-house is about retaining operational expertise: specifically, how your organization handles all the ITIL functions (e.g. incident management, problem management, change management, configuration management, among others).

Once you really lose the understanding of your technical architecture, it becomes too easy, quite frankly, for the service provider to pull the wool over your eyes.
Andy SealockPace Harmon

"If you are controlling the ITSM-ware, you are closer to the operational data, you have more understanding of what is going on and you can manage your service provider tighter," Sealock said. Ignorance equals risk in large outsourcing deals. That said, CIOs must tread carefully on ITSM, as all IT service providers have their own ITSM processes and certain ways they like to work.

"The more you force them to deviate from those processes, the more you will drive up their costs, because they are doing a one-off for you," Sealock said.

Still, he advises clients to either provide the ITSM tool or insist on being given the hooks into the provider's ITSM tool, so they can audit performance on key metrics.

"For example, [IT needs to know] if the mean time to resolve is four hours, or really eight hours because a provider has manipulated the time that individual incident reports are opened and closed," Sealock explained. "If you understand the process of when people are allowed to open a ticket and close a ticket and how that is coded in the system, you can't get faked out by a service provider trying to make that SLA [service-level agreement] look better than it really is."

Go to part two of this 3-part tip to read Sealock's advice for improving the second big area where CIOs commonly add risk to their IT outsourcing deals: the contract.

Email Linda Tucci, executive editor, or find her on Twitter @ltucci.

Next Steps

Getting started on IT outsourcing deals

Is the mega-deal a dead-end IT outsourcing strategy?

Agile principles reinvent IT outsourcing deals

Dig Deeper on Enterprise ITIL and ITSM

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What is the most common reason IT outsourcing deals fail?
Our good technical people have absolutely been reduced to sitting around being contract administrators. In fact, it had become a significant portion of every full-time employee's job to guide, manage, and check the work of contractors. We were something like 80% contractors. This didn't work out, which came as a big surprise to no one (except maybe the CIO)
Generally speaking, it's the level of indirection and the number of deals that have to be manage and micromanaged. I think overall it takes a lot of time and oversight to keep an outsourced project on the rails, and when all is said and done, it ends up being more expensive, perhaps not in pure dollars, but in time and attention applied.
It can destroy the morale of workers who watch the ranks of their coworkers dwindle. And workers with bad morale can destroy a company. While generally cost effective, it's a counter-productive, counter-intuitive way to grow a company.
It can't be fun to babysit providers. Are you folks seeing a shift to "insourcing" work in order to retain in-house talent and drive innovation? 
Sometimes you get what you pay for. Outsourcing may not be as concerned about security as you. How do you hold someone accountable that is not an employee. I have worked for companies that outsourced some code with disastrous results. For my last company when it came time for the Y2K fix that everyone panicked about we looked into it. The software vendor want a ridiculous amount, got sticker shock from outsource quotes. What we ended up doing was the work ourselves. The company basically hired us as contractors to work nights from home to do the mods. We came in at about 1/3 the price and faster that the quotes we got. Partially because we had our nose in the code daily.  Because we did so well we got a little bonus on top of the contractor fee. 
The large outsourcing deals done by a VMO focused on low rate cards and volumes with a small number of general vendors are destined to be problematic.  Even the term outsourcing seems to  abdicate any responsibility for talent management.   

Most IT shops need innovation, differentiation, and long term commitment from their employees (internal or external). Contracting for services is not the problem, but prioritizing volume rate discounts over skills and contribution is.   

When I worked in IT, I would not hire anyone that didn't want to be connected to the business we were in.  They had to know who they worked for, how they created value, and they had to prove their value and make a strong individual contribution.  

Great IT leaders will always be great talent managers and expect as much from their partners as their employees.   

There are good partners out there who will make it worth it. 
Linda, I'd want to add a few more basic pointers - https://www.linkedin.com/pulse/why-outsource-management-service-pratheek-malleshappa
I haven’t seen a shift to “insourcing” so much as I have seen a more collaborative arrangement between in house and outsourced resources. It was driven by the need to keep some level of knowledge within the company, as well as the idea that collaboration could produce better, more innovative results than dumping a project on an outsourced team.
The common reason of failures is an expectation of immediate gain without investments. If the existing teams, process, and communication were disrupted, then the first objective should be rebuilding the organization.
Really, anything new have high failure rate. This is the price of learning. What is unfortunate though: it seems that too many companies learn in isolation, repeating the same outsourcing mistakes again and again.