How to Be Introspective

The first step to componentizing your IT department is to stop thinking of the various jobs IT does as functions, and start thinking of them as services. It sounds like semantics, but there is an important distinction: Functions describe something from the perspective of the person or group performing it, while services describe it from the perspective of the person or group who benefits. "What is a help desk after all?" asks Gartner's Anderson. "It provides a service to internal users of IT." Look across the rest of the department, he says. "Everything can be considered a service. You just have to figure out who the customer is."

Once you adopt that mind-set, you are in a position to think about your IT department like a discerning shopper and not get distracted because something has always been done a particular way. That's critical, because componentizing your IT department will require you to challenge assumptions and the status quo. CIOs need to break each of these services into discrete processes, and each process into tasks. (In outsourcing lingo, tasks are a subset of processes. For example, requirements gathering might be a process; talking to users would be a task.) In some cases processes and tasks will overlap. In others, you will find ­extraneous or poorly performed steps. That's one of the benefits of the exercise, says Louis Rosenthal, executive vice president of ABN Amro Services. "I don't think that a company can be rigid with its own processes and expect to get maximum value from a strategic sourcing partner," he says. CIOs need to do more than merely evaluate the processes they have; they must think about the processes they want to have in the future.

It's not enough just to identify these processes, however. They need to be broken down into specific tasks. For example, a company may have a group of programmers who understand every aspect of the business and turn out amazing applications that give the company a competitive advantage. Outsourcing the entire application development process in this case would be a non-starter. But if you break down the application development process, you end up with a list that looks something like: requirements gathering, functional design, physical design, building, testing and deploying. Maybe the team isn't great at testing. Or maybe there is a testing group somewhere in the world that can perform that task cheaper and more efficiently. Breaking processes into tasks gives you the opportunity to make these kinds of decisions.