IT Performance Improvement
Networking and Telecommunications
Share This Article
What's Your Core IT Competency? Really?
Most everyone outsources some part of their technology operation for all sorts of good-and occasionally bad-reasons. There's a reason why the IT services industry is clipping along at well over $1B per day in the United States 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, but it's about rerouting money from non-core to core activities.
The elements of acquisition alignment appear in Figure 1. We'll look at the major issues in order.
Figure 1 The elements of applications alignment.
Business Strategy Linkages
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. All of the books, articles, and seminars about core competencies are-in the final analysis-about shedding processes. We used to call it reengineering. Now we think in terms of optimization, efficiencies, and other terms that refer to doing what we should do right and avoiding what we should not do.
The core competencies drill is critically important to acquisition alignment. As your business evolves, you need to ask tough questions about maintaining the inhouse 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: e.g., the costs to maintain in-house IT personnel should include recruiting costs, retention bonuses, and training and education costs, among others?
- Does the reassignment 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?
- If you anticipate your primary business model and supporting processes five years out, will current in-house-supported activities still be as important to the core model and processes?
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. It may be that certain IT activities should well stay in-house.
The Range of Acquisition Alternatives
There are all kinds of activities you can outsource. Figure 2 presents the range of IT services you either do in-house or might outsource. Which ones do you do in-house and which ones do you outsource? Why?
Figure 2 Outsourcing candidates.
Products and 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 retrain staff is shrinking (at least a little!). If these assumptions are correct, then you have to decide how you want to outsource (of course, you may also decide that you want no part of outsourcing and decide to stay the course with your internal IT staff).
You have a number of outsourcing options:
- Combine outside vendors with your own. Sometimes called 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 that 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
It's strongly suggested 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 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:
- Above all else, your outsourcing process should be driven by the results of your core competency assessment and your 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).
- Make sure you know what you're doing. Although 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.
- 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.
- 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 SLAs and then monitor the heck 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.
- 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.
- 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 the incentives.
- 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, and designs keeps you in control of the business/IT alignment process while freeing you from (probably) non-core implementation and support tasks.
- Make sure that metrics are in place long before you sign any outsourcing deals (see below).
- Do not sign any long-term outsourcing deals unless the deals have huge shared risk features.
Acquisition Effectiveness Metrics
It's critical that all of the analyses, assessments, requirements, baseline costs, new costs, shared risk assumptions-and especially performance metrics-get quantified.
Depending on what you've chosen to outsource, you should develop a set of metrics that will permit you to (a) compare what you've got now to what was the case before outsourcing and (b) determine if the outsourcer's performance is up to snuff. There should also be metrics to determine if in-house professionals are performing adequately, should you decide not to outsource.
The metrics should be rolled into formal SLAs that should form the basis for the outsourcing contracts you sign. Again, SLAs should be used to track in-house or outsourced performance.
The SLAs should also anchor your shared risk arrangements. So long as performance metrics have been quantified, the shared risk deals can be assessed. If you haven't quantified expectations, then you'll have problems with your provider. Finally, while I've talked most about shared risk deals with outsourcers, there's no reason why they can't be applied to in-house deals as well.
All this needs to be monitored closely because dramatic change is inevitable. As suggested above, one that should be especially tracked is the new movement toward applications hosting by third-party vendors. Other trends such as shared risk, premium pricing, and related incentive structures also bear close scrutiny. Eventually, we'll all have accounts with IT utilities from which we'll buy all of our IT products and services. But until that day arrives, we'll have to struggle to objectively assess our core competencies and realistic sourcing options.