The Impact of Outsourcing: Ups, Downs and the Future
From 1990 to 1997, I led a U.S. group that supported global merge/purge-related programs and systems for a Fortune 100 company. We supported 21 countries. India was one of them. In 1995, I traveled to India and other Asian countries to teach software use.
Infosys, Wipro and Tata were companies hardly known in the United States then. The company office I arrived at in Delhi seemed little more than a tenement building. The offices themselves were small, the carpeting old. Traffic in Delhi was dense, competitive, and there were few -- if any -- traffic lights. During this visit the air was always thick with fumes from buses and cars.
While outside on break, I'd sometimes hear a mechanical ratcheting sound that would go on for hours. I was told this was the sound of the local gasoline generators that would kick in whenever electrical power in the area failed. Considering that my software ran on computers that depended on a reliable source of AC power, this state of affairs was more than a little discomforting. Telephone service was often hit and miss.
On the whole, I found my Indian colleagues hardworking, capable and with no evidence of pretentiousness, very serious workers who persisted and succeeded despite the many hardships and difficulties surrounding them.
I left India thinking it unlikely I would have much contact again. About six months later the director I reported to, who was Indian, decided we could cut our software support costs in half by outsourcing to Tata Consultancy Services.
At first I was doubtful. We maintained a BAL mainframe system that consisted of more than 300,000 lines of very difficult code, but Pradeep and Vishnu proved themselves time and again. By referencing documentation that our group had created and examining the programs themselves, the Tata consultants learned the entire system. For nearly two years, even though Vishnu was in Madras (Chennai) and Pradeep was in Arizona, both were able to come up with technically sound, innovative solutions to very difficult business problems.
The keys to the success were the intelligence and competence of these two consultants, their abilities to speak and understand English and also in maintaining strong, visual communication documents among us. As long as these basic elements were in place, we succeeded.
But BAL was an aging skill, and young Indian people like to keep pace with new jobs and new technologies. Hence, after Pradeep and Vishnu moved on to other jobs, I discovered that one of my new replacement consultants had little or no BAL skills. Upon questioning his management I was told that it was now very hard to find strong BAL skills in India. This was a lesson learned. Sometimes, folks would not want to tell me bad news.
Without penalty to either side, we mutually ended our relationship, and I found other support within the United States.
About four years later, the DM software provider/service bureau for which I was now working wanted to market a client/server, expanded change-of-address product, but its programming resources were at capacity. Through contacts, I was able to engage a consultancy firm in Delhi at 40 percent of the programming cost in the United States.
This was the first time I was to work quite so blindly without any face-to-face contact at all, but again, if the skill and intelligence were present in India, if I could capture the requirements clearly in both text and in diagrams, I felt the project would succeed.
I find that there can be no compromise in projects of this sort; if both the requirements' text and the diagrams are not sufficient and balanced to the task, the project is likely to fail. Projects that are text-heavy or that use vastly complicated diagrams present tremendous difficulties for development groups onshore. When the development is offshore, the complications can become painful.
We worked extensively to provide the right balance of text and diagrams for our change-of-address product. Logical flow diagrams in particular described the essential structure and approach the program would probably take. After the requirements document was shipped over, we needed only a few international calls to put everything on track, and on the whole, the project succeeded.
The initial project delivery took longer than anticipated by three weeks. Again, I found the same reluctance to convey bad news. Another downside was that prior testing was far from adequate. All the basic code was in place, and each problem found would just need a few hours or a day to be put right; nonetheless, judging by the initial results it was almost as if driven by the deadline, the work had not undergone any unit testing at all. This put an additional burden on us, the product owners, to ensure we were releasing valid results. This burden is perhaps as it should be, but somehow not having any unit testing at all removed another line of defense that most development companies would want.
The year was now 2001, and by now the computer/programming world had become aware of India. Many major U.S. and European companies had some sort of business relationship there. I was familiar with India, but not as familiar as I was about to become. In 2002, a former Indian colleague asked me to join him at a technology startup company; the development of client/server, global merge/purge-related software would be done in Calcutta.
In the next 2 1/2 years, I would make three extended trips to India, one lasting almost a month. This time I didn't stay in palatial hotels, but rather in Indian-owned hotels and old British clubs. With my colleagues I traveled to Calcutta (Kolkata), Bangalore, Bombay (Mumbai) and Delhi. In the seven years since I had been there last, India had changed.
Whereas the other cities still suffered from choking air pollution, Delhi had switched all taxis and buses to run on compressed natural gas. The difference was remarkable. The air was breathable now, and it was a pleasure to be in Delhi once again.
Western companies were everywhere: IBM, Intel, Dell, Citibank, Microsoft, Oracle, Prudential and more. Other Indian startups we met with were enthusiastic, eager to do business and grasp opportunity. Industrial/corporate parks were springing up. Small offices and old carpeting for major corporations were gone. Large structures with beautiful grounds and fine wood paneling were more the order of the day.
Using the same text and diagramming techniques I had used in the past, I worked with our development group in Calcutta to create formidable data quality, merge/purge-related software. The communication techniques worked, and the same strengths and lingering problems seen in the past again emerged.
Our guys were smart, technically well trained and hardworking. Clearly, they had a gift for technical, logical development.
Still, there was a tendency to avoid relating bad news. Also a tendency give short shrift to unit testing in favor of making deadlines. On the whole, I found key staff tended to focus more on programs rather than on understanding business needs, more on single custom program solutions rather than on utility-driven systems. Client-suggested designs were often regarded more as solutions themselves rather than attempts by the client to express business needs. In short, strong business systems analytical strengths were in short supply.
As far as the direct marketing world in the United States is concerned, what, if anything, does or will all this mean?
Clearly now, the main differentiator in the choice between outsourcing and insourcing is cost. For companies that want to develop software products, if able to deal directly with reputable groups in India, costs can be 25 percent to 40 percent of those in the United States. How or if DM software development companies choose to approach India remains to be seen, but it is conceivable that some companies may develop alliances with established Indian development companies or even try to open branch offices in India.
This difference in labor costs is not even remotely a case of U.S. software programmers not being sufficiently competitive. Economically, the playing field simply isn't equal. The cost of living in India is so much less than that in the United States, programming salaries in some Indian cities can be as little as 1/6th to 1/8th of those here.
Obstacles to offshore software development are communication and the complications that can arise from impeded communication. Even when working through very strong business/technical communicators in the United States, where screens and ease of use issues exist, product development of this sort can be very difficult. Capabilities such as Webex can help overcome these situations, but perhaps not completely.
Then again, ultimately companies here will have to weigh other factors mentioned: the tendency to avoid delivering bad news, the tendency to go light on unit testing, resistance to ideas outside of immediate experience, some weakness in business requirements analysis and the tendency toward custom program rather than utility/system solutions.
Where I think the effect is likely to be greatest is in the area of service. As direct marketing knowledge and capability migrate out to India, Indian service bureaus will arise. In fact, the DM world is in its infancy in India now and is just starting to grow. Strong modeling and statistical skills already exist there. Schools like the Indian Statistical Institute turn out fine talent yearly. It is conceivable that companies like Infosys, Wipro and Tata may develop service bureaus in their organizations. With globalization in everyone's sights and direct marketing software developed to meet global needs, service bureaus can be set up in India to take in and process data from all over the world.
Or using a different configuration, for those companies that cannot let data off-premise, with the "client" capability of software in India and the server capability on a customer/company's site, Indian personnel can run jobs on the customer's site remotely. Whatever service scenario might be chosen, working through India can dramatically lower a large company's costs.
Major Western companies that currently execute direct market technical services from a division within their organizations in the United States or Europe are very likely to consider executing these same services through a similar division in India in the future.
No matter what the impact, it is more than likely that outsourcing is going to grow over the coming years, and leading contenders such as India soon will play greater roles in direct marketing.