A Passage to India

February 16, 2005
Volume 3, issue 1

Download PDF version of this article PDF

A passage to India

Pitfalls that the outsourcing vendor forgot to mention

MARK KOBAYASHI-HILLARY, OFFSHORE ADVISORY SERVICES

Most American IT employees take a dim view of offshore outsourcing. It’s considered unpatriotic and it drains valuable intellectual capital and jobs from the United States to destinations such as India or China. Online discussion forums on sites such as isyourjobgoingoffshore.com are headlined with titles such as “How will you cope?” and “Is your career in danger?” A cover story in BusinessWeek magazine a couple of years ago summed up the angst most people suffer when faced with offshoring: “Is your job next?”

This article, however, is not designed to make the economic case for or against offshore outsourcing. Economists across the world are debating this issue and producing evidence on both sides of the macro-economic fence. What cannot be disputed is that the American IT industry is changing. According to the U.S. Bureau of Labor Statistics, in 1983, computer programmers accounted for 62 percent of all IT jobs in the U.S. with the remainder being computer engineers, analysts, and scientists. By 2002 this ratio had almost reversed, with programmers accounting for just 26 percent of IT jobs.

While this article focuses on software development and maintenance, offshore suppliers now offer every imaginable service—from equity research to jet engine design to architectural planning. If your skills are intellectual and most of what you produce can be transferred via computer networks, then it is possible that your job could be outsourced to an offshore location.

This is not the image of doom you may imagine, as an offshore provider cannot offer local knowledge or a blend of specific skills that appeals to the requirements of your onshore location. Some skills are less in demand than before, however, and some are more likely to be used through an offshore arrangement. Through 2004 I have been analyzing these industry changes in the United Kingdom as part of a British Computer Society project. The aim is to advise the U.K. government on the career skills IT industry employees need to equip themselves with to cope with a world where outsourcing is a common business strategy. The project integrates lifelong learning, computer science degree syllabi, and the knowledge and experience of outsourcing that employers will start to demand of new hires.

This article looks at the practical experience of outsourcing to India and the pitfalls it holds for those who have to make the strategy work. Sometimes those PowerPoint presentations to the board just don’t function the way the management team expected, once a new culture and 20-hour journeys enter into the equation. The following sections summarize the four major areas where you need to be vigilant during a transition to an offshore outsourcing relationship. Many of these comments are also relevant to the post-transition management.

SEARCH COSTS AND OUTSOURCING STYLE

I use the term search costs, but the concept could just as well be termed hidden costs. Many countries offer very good offshore facilities and different ways of structuring a relationship. Consultants may take a year or more helping your company to decide on which country to use, which processes to outsource, and how to phase the transition. (Elizabeth Sparrow does a good job of comparing the relative merits of 18 different countries for offshore outsourcing in A Guide to Global Sourcing—Offshore Outsourcing and Other Global Delivery Models, British Computer Society, 2004.)

They may also then consider all the different options for using resources offshore, such as creating a new subsidiary company (“going captive”), partnering with a vendor, or creating a joint venture. The options are endless—and expensive. (The terms outsourcing and offshoring are often confused, and the scope can vary from augmenting your internal team with a few additional contract staff right up to the contracting out of an entire technology or business division to a service provider, such as EDS or Accenture. Offshoring usually implies that you have outsourced internally by creating an offshore subsidiary company and then contracting to that company as if it were a supplier.)

It is worth being aware of the differences between doing this yourself by setting up a captive unit that is a subsidiary of your own company and just outsourcing to an IT vendor. A direct investment in creating your own captive facility is often the preferred route for foreign companies with little experience in outsourcing and a desire to maintain strong control over the operation. Going captive gives you the following advantages:

Perceived better control. Everyone works together under one roof toward the same goal.
Management style and culture. The culture of the organization and its management expertise can be exported to the offshore location.
Security. It is your company, so sensitive data can be handled whether the office is in Bangalore or Baltimore.
Flexibility. Resources can be redirected to new tasks without the requirement of working through a vendor SLA (service level agreement).
Cost control. All efficiencies and savings from the lower-cost environment are passed on directly.

Although some of the cost advantage will be lost, partnering with a third party in a regular outsourcing arrangement has its own benefits:

Product/Service improvement. Processes can be improved and reengineered using the benefit of the supplier’s experience.
Flexibility. True flexibility can be attained by using a supplier instead of internal employees. If you need 1,000 call-center agents or 200 Microsoft .NET experts, then the outsourcing supplier can immediately arrange the service, even if it needs to ramp up by hiring.
Cost. The vendor should be able to profit from efficiency gains and economies of scale and still charge you less than the present cost.

Usually, the team that has to make all this work has not really had any influence in the decision-making process. This can cause a problem with the transition right from the start—the executive-level strategy sees outsourcing some technology functions as a panacea for all the company’s supposed troubles, yet placing the same problems in India may only make matters worse. It is important to be aware of this process and to influence it if possible, not as a valiant protest against the process, but to ensure that the detail—not just the strategy—is going to work.

When selecting India as a destination for outsourcing, most companies see two major areas of benefit over other destinations: first, the attractiveness of the local people; and second, the country itself.

India has a stable democracy, as demonstrated to the world by the 2004 general election where the incumbent BJP party was ousted to the surprise of most commentators. Telecom and power availability is improving, and India leads the world in the use of technology standards, such as the Capability Maturity Model devised at Carnegie Mellon University. Transportation infrastructure is also improving, with three major domestic airlines and new airlines entering the market quickly. It has never been easier to get around this large country.

English is used in India as the language of business and academia because it provides a common standard in a country with dozens of regional languages and thousands of sub-dialects. India has more than 250 universities and 900 colleges creating almost 2.5 million English-speaking graduates and postgraduates each year. It is obvious why India has attracted attention with a talented resource pool growing at this rate.

Any outsourcing supplier should be able to offer the best people on the market with the latest skills and with experience managing offshore projects. In most cases, they will have a local office in the U.S., so you rarely need to visit the offshore location.

There is no simple way of describing the right blend of project size, offshore country, complexity of operations, outsource or captive—the answer is a function of the inputs from each company and depends on its particular appetite for risk and potential savings. This analysis is the hidden cost of outsourcing because its cost is often missing from the business plan.

These are the strategic issues that should be debated before the project begins. Having a good understanding of this process and the reasons why India is chosen so often for offshoring will help you to deliver the project once the transition commences.

METRICS AND KEY PERFORMANCE INDICATORS

If you are using a third party in India, then it is likely that you will set up a bulletproof SLA where you nail the vendor to the floor with penalties for missed delivery. If it is a subsidiary of your own company, then you may be more relaxed about delivery control—you could create penalties, but that level of control is only robbing one department to pay another.

Either way, metrics and KPIs (key performance indicators) create a number of problems once a project moves offshore to India. When you are seated in New York and the development work is taking place in India, creating some form of tracking structure on an IT project is essential. You can no longer walk down the hall to kick the tires and see how the team is doing.

Unfortunately, many service providers do not help you a great deal when planning which KPIs to use. This can lead to one of two problems: either the KPIs are the wrong indicators of good performance, so they are of no genuine use in monitoring the relationship, or there is a KPI overload as you attempt to monitor too much.

In some outsourcing contracts, the SLA is viewed as a tool for defining the level at which penalties apply—and not much more. Clients trawl through the small print of the SLA at review meetings to see how many penalties could be enforced. This is hardly a good use of time and does not reflect the spirit of partnership in which you should be trying to manage the project.

The best way to consider the SLA is as a car dashboard (this metaphor was coined by Rob Aalders, author of the excellent and very practical book, The IT Outsourcing Guide, Wiley, 2001). Use just a select few key indicators—that’s what the acronym stands for, after all. When you drive your SUV to your kid’s soccer game, you don’t monitor the performance of individual spark plugs and the fuel/air mixture; you just look at basic key indicators such as engine temperature and the amount of gas left in the tank. If you have complex metrics that require constant monitoring, then it will require a full-time team to watch over the relationship, and even then they may not be able to detect certain problems until disaster strikes.

The goal of a penalty scheme should never be to obtain the penalties, but rather to ensure that minimum expectations are met. In this spirit, some organizations elect to allow the supplier to “clawback” penalties if subsequent performance is better than expected.

Providing a supplier with service “debits” because it offers a better-than-documented service may not be a good way to structure and measure a relationship. Good service is an expectation of giving your processes to the vendor. You set the required performance for the supplier, and that’s what you pay for. We have all over-tipped a good waiter at the end of a great meal, but have you ever decided that the food was so good you wanted to pay the restaurant more than the menu price?

Accepting a service credit is the action of penalizing the vendor, so it will provide additional service at no charge. Service debits are effectively a bonus for the supplier, whether by allowing it to clawback credits or by paying an additional cash bonus over and above the normal fees. Service levels are based upon the business requirement—the call center must answer the telephone within three rings, the PC must be fixed in four hours, the number of checks processed must be more than 10,000 per hour. Over-performance has no business benefit for the client. Otherwise, it would have set the threshold higher in the first place.

Be sure the penalty clauses are specified. The SLA needs to define where the minimum required level of service is going to be and the consequences of failing to deliver, but try to think beyond penalties, fines, and overly complex metrics. Crafting the SLA and KPIs should be about thinking of what is going to be mutually beneficial as the relationship grows. Above all, it should be a working document.

DEALING WITH CHANGE

Change in the strategy of a company is really one of the hardest problems to deal with. It is not so much that you have decided to go to India, but the way you deliver IT services internally has to change. At a practical level there are a number of issues to contend with:

The Indian team will be working in a very different time zone. India is Greenwich Mean Time + 5.5, meaning it is 10.5 hours ahead of Eastern Standard Time. If you start work at 9:00 a.m. on the East Coast, then it will already be 7:30 p.m. for your Indian team, thus making it difficult to schedule joint conference calls and meetings. Some teams, however, learn to exploit the time difference. Where you are sharing technical tasks between a U.S. team and an Indian team, you can hand off tasks to be performed in India during the U.S. night and passed back ready for you in the morning. Even where tasks are not shared, it can be an efficient use of time to stack up your requests for the Indian team and find them all completed by the next morning.

Transferring tasks and code from country to country means that you need to strictly define your source code or document control system. Using tools to check in and out the different versions of work in progress becomes more essential when the teams cannot physically see each other or view who is working on what.

Indian English sometimes uses unusual terminology that can be confusing for an English speaker from another country. Indian English is a fascinating blend of perfect English peppered with the occasional Hindi phrase or archaic expression long forgotten in the U.S. You may be baffled as dacoits rob wallahs of lakhs and crores in this strange pidgin “Hinglish.” Engineers tell their perplexed manager they are working late because of the software “upgradation” or system “updation” and may shake their heads to indicate interest in a manner that is similar to the Western shake of disagreement—if you can see them, that is.

Once you have decided to run with outsourcing, then everyone needs to run together, because many of your informal procedures will need to change. Managing a team locally and managing a shared team with onshore/offshore resources are two very different tasks. I have seen situations where Indian developers were sent on-site for one year to work on a project. With on-site resources from India, there were no issues at all. As soon as the same people tried doing the same job from India, however, it fell apart, with team members from both sides criticizing each other.

Why did this happen? Because whether the developers were on-site or offshore in India, the project manager behaved in the same way with no attempt to take into account the distance and greater opportunity for misunderstanding. This project was saved by adapting the management and working style to better suit an offshore project. Informal meetings called at the last minute were replaced by regular meetings with approved minutes. Follow-up actions for all parties were always agreed upon and documented, and every time project requirements were discussed, they had to be documented and approved.

There is a danger in removing all technical skills from the onshore location. Even though the new primary skill may be managing the supplier relationship, some technical knowledge must remain to guide the offshore resource in much the same way as a project manager with technical knowledge will lead a software development team. It is not enough to rely on the SLA alone.

Career management for the offshore team is also important. They may be the employees of the supplier, but you need to be concerned about their bench strength, continuity of service, and cross-training. Avoid the single-person-dependency syndrome where the supplier always sends in its “guru” to firefight the most complex problems. Although the offshore team should really be the responsibility of the supplier, it would be your service that fails if the supplier starts experiencing a wave of attrition. Thus, you should take an interest in the welfare and training of your new partners.

When a team is offshore and you can rarely communicate directly, then everything has to be documented and agreed upon for it to work. This may seem stifling, but some Indian development teams are making great strides in using low-documentation methodologies such as XP (extreme programming) or Agile.

CULTURAL DIFFERENCES

An appreciation of different cultural values is essential, because you want your offshore team to feel included in the service you are delivering; yet they may not respond to the same drivers as your American team.

For the on-site team, some basic information and training on Indian culture and ideas about what to do and what not to do can be useful. An inexpensive training program for members of your Indian team could help to meet you halfway on cultural understanding. With the huge population and melting pot of religions, caste, and languages in India, it can often feel as if there is a festival of some sort every other day. All this new information on culture will be impossible to understand, but an attempt is worth the effort.

Most cultural training is related to communication and relationships. Because of the distance and cultural differences, you can never communicate too much when a part of your team is offshore. Differences in attitude or style can affect your project delivery. As far as is practical and affordable, you should encourage travel in both directions so both sides can interact. This can be managed by allowing a variety of developers to participate in project planning in the U.S., rather than always using a single representative.

Ensuring that some members of your Indian project team spend time working in the U.S. will help you to sail through most of the cultural problems. It can also address some differences in technical styles. The Indian contingent may have a very different idea about coding style and revision tracking that is meaningless to the local team, so this is a specific area on which to focus time and effort.

Exposure to the culture of the other team in this way will encourage an improved working relationship. Efficiency often improves dramatically when you work with someone you have met in person, even if there is no specific reason to meet. Having a point-person charged with communication management in both the onshore and offshore locations can also help to reduce confusion. This is reinforced if the onshore team member is employed by the supplier and the position is rotated through the offshore team.

For an American IT manager tasked with managing technical resources in India, one of the most important differences is the strict hierarchy. The Princeton psychoanalyst Alan Roland commented on this in his book, In Search of Self in India and Japan (Princeton University Press, 1988): “In contrast to Western hierarchical relationships—which tend to be based on a fixed status and power relationship, governed by contractual agreements and an ideology of essential equality—Indian hierarchical relationships are oriented toward firmly internalized expectations in both superior and subordinate for reciprocity and mutual obligations in a more closely emotionally connected relationship.”

This can be a shock to American managers brought up with flat team structures and blue-sky thinking. I fell afoul of this cultural difference when I first started managing teams in India. I gave them complete freedom to work toward targets in much the same way I would do in London or Paris. They felt I was neglecting my duty by not guiding them.

This attitude to management has some practical considerations. In the U.S., the individual player is often rewarded for an ability to work without “disturbing” the manager. Indian subordinates often require more guidance than American managers are comfortable with. The American managers may expect the workers to “get on with the job” rather than frequently asking for advice, but this state of dependency on the manager is normal. G.D. Sharma, an emeritus fellow of the All India Council for Technical Education (AICTE), explains in Management and the Indian Ethos (Rupa, 2001): “Dependence-proneness is a tendency of the subordinates to seek support, advice and help from superiors even in situations which do not warrant such dependence. Dependence-prone persons tend to avoid responsibility and do not show initiative. But in a nurturing climate of warmth and emotional support, dependence-prone persons are likely to perform better than others.”

The emphasis on that last statement was added by Sharma. In a Western context, this means that there will be many situations where a person can be a valuable member of the team, but needs to be taken “under your wing” to perform. Just think of all those Hollywood movies with a rookie cop or cub reporter and you should have a good appreciation of how to help these people perform.

If you employ a supplier in an offshore location, then at least make sure you are actively engaged in hiring for the team. The supplier may find the right technical skills without considering who can work best with your team, because only you know whom you can work best with.

THE PRESSURE TO DELIVER LIES WITH YOU

Some problems with offshore outsourcing have declined dramatically in the past few years. The lack of good data protection legislation and basic Indian infrastructure are areas where I had run into problems a few years back. It was sometimes hard to get through to the office on the telephone. The Internet connectivity and leased lines for the WAN (wide area network) would sometimes be down several times a day. The lights would go out in the office at least once a day. All of these problems made it hard to deliver an IT service from India.

Privatization of utilities is leading to a more reliable power supply, however, and all modern offices feature UPS (uninterruptible power supply) systems. I visited one vendor in Chennai recently where the UPS can power the entire office for more than a week if needed. Growth in the Indian cell phone market is above 100 percent.

As the infrastructure has improved in countries like India, the pressure to deliver resides with you and your team. Whether they are good or bad technologists is as important as it used to be when everything was local. Whether you can manage a project that allows for on-site and offshore resources is a key difference, but the basic reliance on communication and relationships remains the same whether you are delivering code from New York or Noida.

MARK KOBAYASHI-HILLARY is a director of Offshore Advisory Services Ltd., based in London. He has worked at a senior level for several leading banking and technology groups in Asia, Europe, and the United States, where he has been involved in managing outsourced relationships in the U.K., Singapore, and India. Kobayashi-Hillary is the author of Outsourcing to India: The Offshore Advantage (Springer 2004) and with Mahesh Ramachandran, IT strategy manager at Ford Europe, is writing a new book, Beyond BPO, about the future of global business process outsourcing. He is a founding member of the British Computer Society working party on offshore outsourcing. He is a chartered information technology professional (CITP) and has an M.B.A. from the University of Liverpool.

Originally published in Queue vol. 3, no. 1—
Comment on this article in the ACM Digital Library