Secrets of Offshoring Success

Mary C. Lacity probably knows as much about IT outsourcing as anyone in the industry. Currently professor of information systems at the University of Missouri-St. Louis, Lacity has studied the industry since its genesis nearly 20 years ago. And you’d be hard pressed to find someone who’s talked to more CIOs about their outsourcing coups and catastrophes.Yet just a few years ago when CIOs would call Lacity up and ask her if she could send them any good offshoring research, even she had to say, “No.”

Sure, there’s anecdotal evidence of what’s worked for some and what hasn’t for others when sourcing IT work overseas. But definitive best practices have been hard to come by.

So three years ago, Lacity and Joseph W. Rottman, assistant professor of information systems at the University of Missouri-St. Louis, set out to rectify that by conducting interviews with offshore outsourcing practitioners and their suppliers. Using that research, they’ve developed what they believe to be one of the first rigorous, peer reviewed examinations of offshoring best practices.

To date, they’ve interviewed more than 165 individuals from 40 companies—and not just the usual suspects. Certainly, they’ve talked to IT executives and project managers at client organizations. But Rottman also spent three weeks in Bangalore, Mumbai and Hyderabad interviewing members of offshore development teams from managing directors down to programmers. Cumulatively, these one-on-one talks have provided a gold mine of data. The duo has produced no less than eight published articles and reports from their research, gobbled up by information hungry offshoring customers and suppliers. And they plan a book to be published by early 2008.

Lacity and Rottman’s early examinations focused on the offshore outsourcing learning curve and best practices for accelerating it while maintaining quality and cost savings. Now they’re focused on the delicate process of transferring knowledge offshore while still protecting intellectual property.

The basic thrust of their findings—that offshore outsourcing takes a lot more work than its domestic counterpart—comes as no surprise. But their research crystallizes just where that micromanagement proves most effective and sheds light on some novel tricks of the trade. Although most advice about how to do offshore outsourcing right focuses on processes, requirements, and the like, Lacity puts forth an interesting thesis. Successful offshore outsourcing ultimately is not about processes or requirements. Rather, it is the result of a continuous build up of “social capital” between customer and supplier. Recently, Lacity and Rottman sat down with Senior Editor Stephanie Overby to discuss some of the best—and worst—ways to do just that.

CIO: So, the bottom line appears to be that a relationship with an offshore outsourcer requires a lot of hands-on involvement.

MARY LACITY: More, more, more.

JOSEPH ROTTMAN: Better, better, better. Yet the level of management required still catches offshore customers by surprise.

LACITY: It really does seem like each company starts afresh. Even though we have some research out there and consultants, so many companies make the same stumbles in their initial efforts to go offshore.

ROTTMAN: I got a call this week from a consultant for a very large company. They’ve got an operation with about 100 headcount in Hyderabad, and they’re getting ready to shut it all down. They’re really stumbling because they underestimated the knowledge transfer issues, the cultural differences, even the time zone issues. And this is a very large company that you would think would have done the due diligence and put some governance into the engagement before ramping up. Now it’s spinning out of control.

LACITY: It’s like every new sourcing market that I have seen. The initial push is for cost savings. Senior management tends to look at IT as a commodity. People go into it with that cost focus. But by the time you get to studying the companies that are pleased with their global sourcing model, their first sound bites are always about quality, agility and flexibility.

How long does it take to move up the learning curve with offshore outsourcing?

LACITY: It depends. Sometimes it’s six months. Sometimes it’s two years. Sometimes you just abandon offshore and never go back again.

You say the management costs associated with a successful offshore outsourcing arrangement can run upwards of 50 percent of the total contract value, versus 5 percent to 10 percent for a typical domestic outsourcing relationship.

LACITY: When I was looking at domestic outsourcing 17 years ago, the transaction costs were tremendously high too. And that’s what we see now for offshoring—up to 69 percent of the value of the contract. But those costs will drop over time. They’re bigger during the learning curve when you have to do all the training, developing these deep relationships with suppliers. Eventually you start to institutionalize it and you start reaping the rewards of that initial investment.

You say one investment worth making is bringing an engagement manager over from the vendor.

ROTTMAN: For many engagements it’s a necessity. [The engagement manager] is the primary point of contact for the client’s project managers. That person will work with both the onshore and offshore development teams. They can help mitigate some of the time zone risks, the knowledge transfer risks, the cultural risks. That person is a key piece to all of this.

But an engagement manager is an expensive employee to have onsite. It’s usually a person with four to six years of experience managing projects and a lot of customer-facing duties. When managers are looking only at labor arbitrage and the delta between onshore and offshore rates, they don’t want to throw in that onsite engagement manager.

Just the physical act of bringing the offshore suppliers’ employees on board and working can be difficult.

ROTTMAN: One Fortune 100 biotech firm we looked at kept tripping over onboarding. The Indian resources do not have Social Security numbers, yet all the systems are keyed on that figure. They underestimated the effect of having to modify those systems to use passport numbers instead.

We had one case where the offshore suppliers were forced to re-create the development environment in India, because throughput through the Citrix servers was always an issue. But when they duplicated the offshore environment, they couldn’t do it exactly right. So, code that would run in Bangalore wouldn’t run in the United States. I’m still seeing infrastructure and onboarding and security issues.

What about knowledge transfer?

ROTTMAN: Knowledge transfer is a fairly significant stumbling block. To move out of the initial phases of offshoring to focus on value-add and quality, you need to manage the knowledge transfer effort with greater rigor than if you’re just focusing on cost.

LACITY: When you’re in the early stages of a learning curve, you tend to do more pilot projects. You pick things for which you already know your requirements. But as you try to use suppliers more strategically and do more value-added kinds of work, the issue of customer-specific knowledge—what is idiosyncratic about their business processes—becomes more critical. We’re looking at practices for how the client can explain and transfer knowledge about their idiosyncratic needs to a supplier. How do you do that cost effectively and not give away all your intellectual property? It’s a very delicate balance. Sounds like quite a trick.

ROTTMAN: Let me give you an example. There was a Fortune 100 industrial manufacturing firm that had significant knowledge transfer issues. They were offshoring the development of embedded GPS software—software that controls the operation of a piece of industrial equipment. It has greater memory constraints, speed concerns, et cetera, than software written in C++, or Java, or anything like that. Their first attempt at offshoring followed a throw-it-over-the-ocean model because they really thought they had their requirements down and could do it with very little onshore presence. That resulted in zero deliverables. Projects were just shelved or brought back in house.

We talked to the director of the offshore development center and the customer’s Six Sigma black belt. They realized that the supplier didn’t even know what the machinery looked like for which they were writing the code. They didn’t comprehend the concept of embedded software. And they didn’t understand the company’s business.

So they took that learning and developed extensive training and job shadowing and integration practices to make sure that the development teams were integrated as tightly into the U.S. teams as their internal employees.

How did they transfer that knowledge while protecting their intellectual property?

ROTTMAN: They broke up the projects into three- or five-day tasks that could be wrapped up and sent to an offshore development team. Then they separated those tasks among various vendors with the idea that one vendor wouldn’t have enough pieces of the IP puzzle to put it all back together. Even with the increased transaction costs, they were able to obtain between 10 percent and 15 percent cost savings on the offshored projects.

You talked to offshore customers and vendors. Did you notice a big difference in how they viewed the relationships?

ROTTMAN: There were considerable differences. A good example of the difference is that you’d hear a U.S. manager complain, “You really have to give the offshore development teams very specific instructions. They really don’t show much initiative in going out and investigating a new solution to a problem.” And when you talk to someone on the supplier side, they would say, “The U.S. managers don’t give us all the information that we need. They don’t direct us. We’re kind of left on our own.” What’s the biggest mistake customers make when selecting an offshore location?

LACITY:

If you’re setting up a captive center offshore, then we would suggest you pick a location because you’re in that country for another reason. You’re in that country because you’re going to sell products there. You’re in that country because you already have R&D facilities there, and you can use that as a launch pad. Don’t select a country just because they have the lowest costs or something else that’s going to change. You’ll have to move every couple of years. Is it best to use at least two offshore providers rather than putting all your eggs in one basket?

LACITY: It is a risk mitigation strategy that some client companies we talked to are happy with. I certainly wouldn’t prescribe it for everybody. It depends on the kind of work you’re doing, the volume of work and how happy you are with your initial selection of the supplier.

ROTTMAN: It also has to do with the business that you’re in and whether or not the top three or four Indian suppliers have a specialized vertical within your domain. You could add multiple suppliers, as long as they had the domain expertise.

We’ve seen some U.S. clients that can’t find their niche vertical within the larger firms, and so they go with much smaller firms because of their domain expertise. And then they have those two competing against each other for contracts and for projects. So, we have seen multiple supplier models work well for some.

LACITY: We’ve also seen single supplier models work well, too. There’s a couple of customers that are more mature that had started with a single supplier way back in the Y2K days and have continued to transfer more work, more headcount, to their sole supplier. And that supplier continues to give the customer very good attention because of the volume of the account. Does the same hold true for pricing models—fixed price contracts work well for some clients while others do better with a time-and-materials (T&M) arrangement?

ROTTMAN: It depends. We’ve seen T&M contracts work well. We’ve seen fixed price contracts work well. And we’ve seen both of those work very poorly.

Are there rules for when one pricing model works better than the other?

ROTTMAN: Fixed price carries with it considerable risk for both the client and supplier. You really have to nail down your requirements. On the other side, with time and materials, you have real issues there with scope and budget creep. And the only people talking to each other are accounts payable and accounts receivable. And the project just goes on and on and on.

LACITY: It all depends on the type of work you’re doing. If you’re doing call center work, you can do fixed price. You know exactly how much it’s going to cost per call.

ROTTMAN: And on the development side, if you’re doing something like re-platforming without increasing the requirements or capabilities of the system, both the client and the supplier are able to nail those requirements down fairly well. That might work well for a fixed price. But ongoing development with considerable analysis would really be risky.

Does owning your own offshore supplier help to mitigate risk?

LACITY: Anyone who sets up a captive center wants control. In many ways, it’s easier. In other ways, it’s more difficult. The problem they’re having is, you might be able to understand a government, the Indian federal government, for example. But when you’re trying to actually buy a building, wire a building, get fire permits, hire people, it’s a considerable challenge.

And they’re trying from the get-go to set up a captive center? They didn’t opt for the build-operate-transfer model with a third party?

LACITY: Yes. And what’s interesting is that they think they’re able to get better talent in India because it’s prestigious for [the Indian applicants] to come work for this large, well-known U.K.-based company. Still, the HR issues in India are quite challenging.

Having traveled to India, did you see any evidence of the increased turnover problems we’ve been hearing about?

ROTTMAN: Absolutely. I spent a couple hours with the gentleman who runs the technology park in Hyderabad. He predicted that the demand for freshman college graduates out of the Indian schools would exceed the supply by 2008. And with the demand increasing, you’re going to see a lot of turnover, just as it happened during our own dotcom boom with people jumping jobs.

Turnover affects the knowledge transfer. It affects the protection of the capital expenditure for training. Turnover continues to be mentioned over and over again by the clients we talk to.

Were you able to tease out any best practices for dealing with the turnover issue specifically?

ROTTMAN: The industrial manufacturing firm, in order to mitigate some of that risk, required the supplier to shadow employees, so that knowledge transfer actually was overlapping between two people. The clients would have a key training session over a few months to transfer knowledge from its architects and the lead project managers to the supplier’s project manager. Once that project manager was up to speed, he was shadowed by another colleague on the supplier side. So there were two people essentially doing the same job for an overlap period of three to six months. After that happened, then the initially trained employee went offshore and transferred the knowledge to the offshore development team, while the shadowing employee stayed. They would do this over and over again with a three- to six-month overlap to ensure that if one of those people did leave then the knowledge was contained in another person.

LACITY: And the other thing is, these Indian employees wanted to go home. They don’t want to stay in America for five years. Indian software development companies value the software quality processes and procedures as laid out by the Software Engineering Institute’s Capability Maturity Model (CMM). The leading Indian vendors are usually assessed at CMM Level-5 status, yet their customers may not understand it all. Can that create problems?

LACITY: Yes. We found a lot of that. CMM is what this offshore supplier delivery team is trained in. They are expecting requirements to come over in that form. That’s the start of their work processes. We talked to one Indian CEO who found an interesting solution. You bring over to the U.S. a CMM expert from the vendor who doesn’t know anything about the specifics of your business. Then that person can flesh out all the ambiguities and ask all those questions here when they’re sitting right next to the client, rather than throwing it offshore and waiting for a whole team to ask the same set of questions. [See “Bridging the CMM Gap”]

All those CMM processes can frustrate clients who are used to walking down the hall to ask a developer to make a change. You say there might be some middle ground between the rigid processes of the offshore developer and the way a client is used to working, called “flexible CMM.”

ROTTMAN: There was a retailer who had an engagement with a supplier that was robust enough that they could say, “You do whatever you have to do to maintain your CMM processes, but I’m not going to pay for all of that. If I just need a button moved, I want the button moved. I’m not going to pay for a 20-page impact analysis of the movement of the button.” That customer had enough clout and a strong enough relationship with the vendor to impose a flexibility on them.

Are most offshore providers willing to be that flexible with their CMM processes?

ROTTMAN: It depends on the relationship and the vendor’s size. If those processes are not billable, then the engagement has to be large enough that the vendor can absorb those costs.

LACITY: If you look at some of the key process indicators and CMM, they’re really geared towards the benefit of the supplier organization. For example, there’s all kinds of processes that deal with tracking defects. Well, those reports aren’t going over to the customer. The supplier is using them internally to fix the software as best they can before it goes over to the client. So, CMM is really about the internal processes primarily used within the organization that’s adopted it. That’s why I think some of the customers say, “I’m paying for all your processes, and I really only want the ones that are customer-facing and adding value to me.” Is it still important for the client to improve its own CMM capabilities if it wants to source work offshore?

ROTTMAN: CMM capability is necessary but not sufficient for knowledge transfer. You have to have that framework in which to work. But that structure by itself is no substitute for experience. It does help in requirements definition and process mapping. But it’s no substitute for knowing the people offshore and how they work. It’s no substitute for real experience or social capital.

What do you mean by social capital?

LACITY: Work gets done by people. It doesn’t get done by processes. It doesn’t get done by documentation. If you want to put an umbrella over all the things that we’ve talked about—an onsite engagement manager, job shadowing, bringing over a CMM expert from overseas—it’s really about building the social capital between the customer and the supplier.

It’s not only about knowing the business. It’s knowing who in the business does things. How do they do it? And once that social capital is developed, then knowledge transfer occurs. You develop better relationships with your supplier. Your quality goes up. And you have more satisfied supplier employees who want to stay on the account, so turnover goes down.

It’s so simple. Of course, everybody needs to meet face to face. Of course, everybody needs to develop a personal relationship. But it’s expensive to bring people over from India here. It’s expensive to send people here over to India. And so customers don’t start doing it until they let up on costs and say, “I’ve got to make an investment in this social capital that’s going to let me finally achieve what I’m expecting to get from offshoring.”

Has anyone figured out the best metrics for measuring the success of an offshore relationship?

LACITY: I think the best you’re going to get is if you try to do some kind of Balanced Scorecard—a bunch of measures that will help you capture the big picture.

The biggest problem practitioners have is trying to figure out at a fundamental level how much money they’re saving. And it’s very difficult to know, because you’re not doing this in a lab. You don’t say, “OK, you go develop this software onsite, you go develop it offshore, and we’ll compare the cost.”

So, they try to guess: how many hours would this have taken me onshore versus doing it offshore? Or they go ask their internal staff, “If you were to do it, how many hours would it take?” Well, is that number valid? It’s very difficult to know how much you’re really saving.

Despite all the work, you talked to some offshore outsourcing customers that were at a point where they were happy with the arrangement.

LACITY: Those are some of our companies that have been doing it the longest, have conquered the learning curve, and have a significant global presence and substantial supplier relationships. But that’s like the prize after the end of a very, very long marathon.

ROTTMAN: A good example is the industrial manufacturer who failed at first. When you talk to them now, they can’t find enough projects to send offshore. Their internal staff is happy. They’re back to working 50-hour weeks instead of 70-hour weeks. Their project backlog is down. Their costs are down. Their quality is up.

LACITY: We work in a global economy, and IT work needs to be done globally. Even if you’re talking about domestic outsourcing, most of that IT work is sourced globally. So I think eventually we’re going to stop talking about domestic outsourcing versus offshore outsourcing and just talk about global sourcing.

Senior Editor Stephanie Overby can be reached at soverby@cio.com.