The Real Niel: Rules of outsourcing

Niel Nickolaisen

The number of variables on which "it depends" can be daunting: Cost versus quality. Cost versus time. Opportunity costs versus direct costs. Time to market versus time to develop internal capability. Cost versus management focus. And so on. To make my (hopefully) rational decisions about outsourcing and to better understand the "it depends" dependencies, I use the following guidelines:

Never outsource IT activities that support "differentiating" business processes (for an explanation of such processes, please refer to my January column). One of the ways I ensure that IT is a strategic asset is to build and deliver the internal capability to support the organization's sustainable competitive advantage. If I outsource these activities, I have no chance of building such capabilities and will relegate myself and IT to a tactical role.

More from The Real Niel The Real Niel: Intelligent business intelligence? The Real Niel: Poking holes (and fun) in BPM

Do not make outsourcing decisions on cost alone. My rule of thumb is that I might outsource how I support "parity" activities (again, please refer to my January column), but only to someone who can promise me process excellence. These processes need to perform at levels on par with the marketplace and the competition. If I outsource such activities to someone who cannot deliver, I have created a gap that will cause harm to the business (and to my career). Such an outsourcing arrangement is not an out-of-sight, out-of-mind relationship. When I outsource all or part of a parity activity, I require that the provider participate in my IT processes (including staff meetings, planning meetings, project reviews, program change reviews, etc.).

Using these guidelines, I tend to outsource to fill a capability gap in a parity activity faster than I can fill the gap myself or to take a management load off me or my staff. For example, I currently outsource portions of network management to a provider I trust. Doing this solved some network performance problems for me without my having to get personally involved in troubleshooting and managing the network improvements. I have also outsourced the development of some nondifferentiating applications. This was primarily to unload my internal development staff to work on the differentiating applications.

I have found that there is no single, one-size-fits-all approach to outsourcing.

One thing I have learned from outsourcing certain IT activities is to consider, as part of my decision, the costs of context. These are the costs required to get the provider up to speed on what we are trying to accomplish. I once burned through scores of hours trying to help an offshore development company understand the nuances of a retail loyalty program. Neither the offshore developers nor managers had ever been enrolled in or used a retail loyalty program. They simply did not understand the intent or meaning of our requirements. Without this context, we wasted their low hourly rate on trying to get them to remotely (12 time zones away) think like American shoppers.

Using these guidelines helps me sort out the "it depends" of each unique outsourcing decision. These guidelines also help me better explain the what and why of my outsourcing decisions to my boss, peers and organization.