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.
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:
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.
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:
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:
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.
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 email@example.com.