Key Questions When Considering Outsourcing

Are you outsourcing yet? If you’re not, then you’re in the minority. Most everyone outsources some part of their technology operation for all sorts of good — and occasionally bad — reasons.

There’s no mystery as to why the IT services industry is clipping along at more than $1 billion per day in the U.S. alone: More and more companies have discovered the benefits of outsourcing relative to the recruitment and maintenance of large internal IT staffs.

In the early years, we all thought outsourcing was about saving money, but then we discovered the truth: Outsourcing it not only about saving money, it’s about re-routing money from non-core to core activities.

One of the best arguments for buying a product or service is its alignment quotient: the extent to which the infrastructure or applications investment aligns with business strategy. This of course assumes that a business strategy exists and that the fundamental infrastructure and IT investment recommendations have been made. It’s now time to decide how to source them.

Assessment of Core Competencies

This step is — when all’s said and done — about whether or not you should build and maintain a large internal IT staff.

The core competencies drill is critically important to acquisition alignment. As your business evolves, you need to ask tough questions about maintaining the in-house activities you’ve supported for all these years. Remember that the assessment is not just about cost. Here are some questions for deciding what’s core and what’s not:

Does the activity support your “bottom line,” defined in terms of profitability and
growth?

Can the activity be replaced with little or no threat to the bottom line?

Can the activity be replaced with little or no additional cost, but with some measurable
improvement in quality?

Are the second-order costs to maintaining the activities measurable, growing or
shrinking (for example, the costs to maintain in-house IT personnel should include
recruiting costs, retention bonuses, and training and education costs, among others)?

Does the re-assignment of the activity dramatically reduce “distraction” costs, that is,
permit your organization to focus on other, more valuable activities?

Is the outsourcing of certain activities consistent with your vertical industry’s
perspective on core and non-core competencies?

You get the idea. The key questions have to do with finding your core business purpose and then matching all of the activities to in-house versus outsourced alternatives.

Once you’ve determined what makes sense it’s possible to step back and assess the kinds of IT products and services that might be outsourced. But just in case you think that all roads lead to outsourcing, make sure that you objectively assess the impact outsourcing will have on specific business models and processes.

Products & Services Acquisition Options

The discussion here is about structure and form, not about whether outsourcing will play some role in your IT acquisition strategy. We’re assuming that you don’t have all of the talent you need in-house and that your appetite to continuously recruit, satisfy and (re-train staff is shrinking (at least a little!).

You have a number of outsourcing options:

Combine outside vendors with your own. Sometimes call in-sourcing or co-sourcing, this model can be very effective if structured and managed properly.

Completely outsource segments of your IT mission, such as data center or call center management, but keep others in-house. This option can also be effective, especially when there are clearly defined areas that you do well and those they you do poorly — and when there’s no ambiguity about what’s core and what’s not.

Completely outsource everything to vendors who come on-site and manage your IT resources (including machines, networks, and people).

Completely outsource everything to vendors who “rent” hardware and software back to you.

Of course there are variations on all of these but the four identify the primary outsourcing models you might consider.

All of these variations require that you:

Systematically identify requirements

Compare current (so-called baseline) costs with what outsourcers bid

Negotiate with the vendors on price and services

Develop clear and unambiguous service level agreements

Make sure that management is in place to monitor the results of the work

I strongly suggest that you seek outside help to develop your outsourcing strategy. I realize that this may sound absurd: The recommendation is that you outsource the work necessary to outsource the work! But the fact is that outsourcing has become very complicated and there are now consulting organizations that specialize in this kind of work. These consultants have experience writing requests for proposals (RFPs), screening the proposals and the bids, negotiating contracts, and then managing at least the initial implementation phases.

There are also some rules of thumb you might want to consider:

1. Above all else, your outsourcing process should be driven by the results of your core competency assessment and you skills gap analysis. If you find that you really don’t need to be in the data migration business and that you have no data migration talent in your shop, but that data migration is an important (though non-core) component of what you need to do, then obviously you need to outsource data migration (probably as part of some large applications modernization process).

2. Make sure you know what you’re doing. While evolutionary experimentation is often a good way to learn about some new process (like outsourcing) it may not be prudent. Breaking off pieces of your internal IT shop to give to outsourcers to try them out may make abstract sense but in practice may be doomed to failure. Why? Because you’re likely to outsource the pieces that are the most politically correct while avoiding the really hard decisions about what’s core and what’s not.

3. Be careful with outsourcing deals intended to transfer knowledge from the outsourcer to in-house professionals. We learned in the late 1980s and early 1990s that knowledge transfer-based outsourcing deals were difficult to make work. Why? Because the outsourcer had no incentive to transfer knowledge and the in-house professionals resented the “training” forced down their throats.

4. If you want to try outsourcing on for size, then partition a big piece of your IT infrastructure — like your data centers — and outsource them. Completely. Develop some clear service-level agreements and then monitor the hell out of the performance to see if (a) the outsourcer can do it more cheaply and (b) better.

The implied suggestion here is to outsource what you already know how to do and fully understand, not what you don’t understand. And remember that just because you understand how to, for example, run a data center, it doesn’t mean that it’s core to your business.

5. Really think long and hard about using professionals to architect your outsourcing deals. If you’re a medium-sized organization or one that has had some extraordinary IT infrastructure or applications problems over the years, you might want to take a look at using an applications service provider (ASP) who will “rent” applications to your users (who can access the applications over the Internet or through a [much more expensive] virtual private network). This kind of outsourcing is relatively new but already the major systems integrators have begun to partner with enterprise software vendors like SAP to provide access to major applications. It’s something to consider.

6. The age of non-shared contracting is over. Any outsourcing deal you sign should have some shared risk built into it. If the outsourcer is unwilling to put any skin in the game then there may be a problem with the whole deal. A confident outsourcer should welcome the opportunity to jointly develop some performance metrics and then hit the metrics to get paid.

These deals can take all kinds of forms. For example, expenses can get paid but a percentage of profit may go into an escrow account to be paid as milestones and metrics are achieved. Regardless of the form, the principle is to share the best and worst aspects of outsourcing by aligning all of the incentives.

7. Strongly consider owning requirements, specifications and designs, but not implementation or support. This rule of thumb is not inviolate but will serve you well. In a sense, owning requirements, specification & designs keeps you in control of the business/IT alignment process while freeing you from (probably) non-core implementation and support tasks.

8. Make sure that metrics are in place long before you sign any outsourcing deals (see below).

9. Do not sign any long-term outsourcing deals unless the deals have huge shared risk features.

Steve Andriole is the Thomas G. Labrecque Professor of Business at Villanova University, where he conducts applied research in business/technology alignment. He is also the founder & CTO of TechVestCo, a new economy consortium that focuses on optimizing investments in information technology. He can be reached at steve@techvestco.com.