An outsourcing strategy rarely follows a single template. What is a core function for one company is a commodity...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
service for another. The legacy application that is efficiently handled in-house by one IT department might for another be a nightmare worth unloading. Experts caution, however, that the old wishful thinking about "outsourcing our mess for less" usually is still wishful thinking.
One thing holds true for most CIOs: It's prudent to get your outsourcing strategy as right as possible, given that research shows you are unlikely to reverse a decision to outsource. In fact, when an outsourcing contract is up for renegotiation, companies end up staying with their current provider upwards of 70% of the time, according to Gartner Inc. -- including when performance or cost has been a problem. "The bias is to the incumbent," said Allie Young, research vice president and distinguished analyst in Gartner's technology and service provider group.
Here are six key questions that will help you build an effective outsourcing strategy. They are based on expert advice from Gartner's Young; Steve Martin, partner at Vienna, Va.-based outsourcing advisory firm Pace Harmon LLC; and Thomas Young, partner and managing director in the CIO Services-Infrastructure group of TPI Inc., an IT consulting firm in The Woodlands, Texas.
1. Can the IT function be performed according to a set of rules and procedures?
This facet of an outsourcing strategy is the "bright line" between IT functions that should be outsourced and those which are best kept in-house, TPI's Young said. The demarcation can be murky, however. TPI helps clients find the line by drawing charts for each domain that's a candidate for outsourcing, and organizing its functions, from the transactional and simple at one end of the spectrum to the conceptual and complex at the other. "I think of it in terms of left-brain and right-brain functions," he said.
Routine functions that can be performed by a set of rules and procedures, or what TPI's Young calls left-brain functions, lend themselves well to third-party contracts. Conceptual, ambiguous processes don't lend themselves as well. For example, security functions can be administered effectively by a third party, but the company should retain responsibility for security policy. Likewise, policies about the enterprise's technology architecture should be set in-house. Otherwise, you invite the sort of conflict of interest where a third-party provider tells you an application needs 20 more servers because he has redefined your architecture, Young said. "You don't want to give the person providing the service the keys to the kingdom," he said.
Even sophisticated clients sometimes draw the lines incorrectly, Gartner's Young said. "Our bigger concern is usually that people have let go functions that they should have retained," she said -- architecture definitely being one. "Yet another area where we see a real challenge is how organizations stipulate innovation in their outsourcing deals," she said. Clients who write contracts demanding aggressive cost reductions every year often wind up complaining that their vendor is not meeting business needs. "It is totally fallacious that you can take out 5% to 10% of costs every year and do it without investing in technology innovation -- the company couldn't do that," she said.
2. Is the application pegged for retirement or being moved to a Software-as-a-Service provider?
Managed service providers make money by optimizing, or getting up to speed on, the application up front and reaping the benefit of that work over the length of the contract. For legacy applications nearing retirement, CIOs should expect to pay premium prices because vendors will not be able to capitalize on their up-front work over time. "The business case for the shorter legacy application is not strong," Martin said. The exception is when companies want to "make a clean break of it," and move their internal legacy application resources to another area or out the door.
It's not often the case that companies insource an application that has been outsourced. The exception is when an application supported by a traditional managed hosting provider is going to be retired and replaced by a Software-as-a-Service application: For example, a company moves from Oracle Corp.'s Siebel customer-relationship management software to Salesforce.com Inc.'s. In cases like that, organizations might choose to bring the hosted application back in-house as they "zero it out," because bringing it back in-house gives the CIO more control over the costs of winding it down, TPI's Young said. The other option is to leave the application where it is, and let the outsourcing provider scale back the infrastructure as the app is phased out, he said.
Don't outsource an operation that is hugely sub-optimized. While you are getting the benefit of wage arbitrage, you are not getting the benefit of the optimization, which will inure to the outsourcer.
Steve Martin, partner, Pace Harmon LLC
3. Is the application or IT infrastructure unstable?
Often, organizations whose applications or infrastructure are unstable are tempted to outsource their environment to the experts to get it right, Martin has found. He advises to hold back: "If it is something that can be fixed internally, you should do that first. The reason is that you don't want to outsource an operation that is hugely sub-optimized. While you are getting the benefit of wage arbitrage, you are not getting the benefit of the optimization, which will inure to the outsourcer," he said. (The exception is when you simply don't have the horsepower to make the fix. "But you're not going to save a lot of money," he warned.)
In fact, it is not all that uncommon for companies that have outsourced a mess to not only pay a premium for getting it fixed but also wind up taking it back, Martin said. That was the case with a large wireless carrier that outsourced virtually everything to a top-tier provider with the aim of moving the applications offshore once they were stabilized. "The application never became stabilized and ended up being taken back in-house," he recounted.
4. Is the application's history of change control and change management documented?
This is a variation on Question 3. When an application's processes are not documented, and you basically are turning over just the code to an outsourcer, the provider will have to reverse-engineer the application to figure out how to manage it, Martin said. The application might be stable, but it still presents a challenge that will cost you. "The outsourcing provider is flying blind, and has to figure out quickly how to get their arms around the code, so they can do maintenance and future development," he said.
5. Is the team assessing the application going to be affected if the decision is to outsource it?
Martin often comes across situations in which either the team assessing the application or function will lose their jobs if it is outsourced, or the manager will lose control of employees. In some cases, this is unavoidable. "There is a lot of due diligence you have to do on that application before moving it out" that requires information from the people who have a vested interest in keeping it in-house, he said. If that is the case, CIOs "have to cut through that," he added.
CIOs should be as up-front with employees as possible, TPI's Young recommended. He has seen his share of hatchet jobs over the years, but he also has found that IT staffers typically find more opportunities for advancement working for an IT outsourcing provider than in a corporate environment.
6. Does your organization have strong vendor management skills?
Managing an outsourcing provider as a vendor is one function of an outsourcing strategy that should not be farmed out, Gartner's Young said. For companies with meager experience in managing an outsourcing vendor, moving to a managed services model is fundamentally different from managing the day-to-day lifecycle of an application -- and more challenging, Martin cautioned: "You either will have to quickly learn those skills -- managing to service-level agreements and performance -- or hire that capability," he said.
Let us know what you think about the story; email Linda Tucci, Senior News Writer.