Different Worlds, Different Ways (Part 1)
It is autumn 2013; we are in the Indian city of Pune. Twenty Indian project managers, business analysts and software engineers have gathered in a training room. They want to learn how they can successfully bring the cooperation with a customer whose team is distributed across Germany and the United States back on track. At the moment, however, every single one of them is frustrated. The global programme, in which they work, is destined for disaster.
Collaboration with that client began last spring with such vigour and enthusiasm. But now everything is just sluggish. The programme manager has already been replaced, and the projects associated with the programme are being rescheduled. Uncertainty adds to frustration. The overall mood is strained, emails are responded to in monosyllables and conference calls are cancelled at short notice. The Indian team members ask: how can the transfer of know-how take place under such conditions? How are we to work cooperatively with the customer at all?
For their company, a world-renowned Indian IT service provider, a lot is at stake. The programme has a volume worth of almost twenty million dollars. An early stop would not only mean a financial loss. It would also damage the reputation of the company, which, of course, would be expensive to repair.
After lengthy evaluations, considerations and due diligence, the client, a multinational pharmaceutical company, has decided to finally outsource its core applications to the Indian company. Up to now, the pharma company has been buying software development services from another vendor in India. These included a few non-critical applications and databases in a pure offshoring model. But this new, comprehensive programme involves the heart of the company’s IT.
For many of the pharma company’s IT staff the core applications are “their babies”. The company’s executive board, above all the CIO and the CFO, have decided that it is time to entrust this now-grown-up child into foreign hands. Their objective is to save costs and, at the same time, take a technological leap forward. This can be achieved by not only transferring know-how to the new Indian partner, but also by systematically organising a reverse transfer of technology, processes, best practices and skills.
At the training in Pune, I ask the Indian team to form small working groups and ask them to write down, in an unadorned fashion, where the shoe pinches. Here are the results:
- “We get the feeling that the client teams in Germany and the USA are not treating us at peer level.”
- “Our client does not share the big picture with us. But we need to know it in order to deliver the work we committed to.”
- “We are never clear about their expectations.”
- “We’ve been told several times to be more creative and self-driven. But when we become proactive, our colleagues in Germany and the USA do not welcome it.”
- “They don’t have confidence in our capabilities.”
- “It is difficult for us to understand their accent in the English language.”
- “They seem to value time and deadlines above everything else!”
Ten days later I meet the customer team in Frankfurt (Germany) and a week later the one in Cambridge, Massachusetts, United States. These teams participate in the same training, but with a reverse angle. How do the customer teams experience the cooperation with their new Indian colleagues? What do they find difficult? Where do they need help?
Their answers are as sobering as those the Indian team gave:
- “Our Indian colleagues seek approval from their management for everything we ask of them.”
- “Since we started working with the Indian service provider, micro management at our end has grown considerably!”
- “The Indian team only delivers what was specified as a requirement. There is no thinking beyond that boundary.”
- “It’s bizarre: when we meet with the Indian team to discuss progress, only one of them talks to us. The other members of the Indian team sit, listen and nod approvingly.”
- “We have different expectations of when a piece of work is considered finished.”
- “I guess their English grammar is impeccable. But it is really difficult to understand spoken Indian English.”
- “Our Indian colleagues usually meet deadlines but the quality is often poor.”
When reading these quotes, one might conclude that outsourcing to India was generally not a good idea. In those twenty years since I have been involved with outsourcing and offshoring projects to India, I have come to realise that there are three dominant, recurring patterns.
In the first pattern, a package of activities is curated to prepare both employees and the organisation for the upcoming changes. Employees are carefully brought up to par for collaborating with colleagues in India. Such preparation has to address the operational model as well as the intercultural dimension of the partnership.
In the second pattern, the outsourcing company organises merely a handful of informational sessions concerning how outsourcing should ideally be approached, who is responsible for what, and who the outsourcing partner is. What I also see quite often is that presentations are made about where the outsourcing partner is located (e.g. India), that country’s political and economic environment (e.g. democracy, free market) as well as key features pertaining to culture and traditions (e.g. importance of family, national festivities like Holi and Diwali, spicy curries, etc.). Such presentations are often made by staff members from the outsourcing partner company. It is, of course, true that Indians know their own country the best. But, do they have the acquired skills to view the implications of their native culture on professional life through the eyes of a foreigner specifically based on focussed research, deep realisation and extensive experience?
In the third pattern, I’m called in when the roof is already on fire. Outsourcing projects are often approached as a purely technical, organisational and financial undertaking. The underlying assumption is that planning, processes, technology and lower costs will inevitably lead to success. While decision makers involved in this pattern do hear and read that there are also “soft factors”, they decide to address these if and when they become wildly disruptive. In reality, however, inefficiency and dissatisfaction fester for quite some time until they suddenly erupt.
To read the concluding part of this article, click here.
This article was first published in Outsource #36 (Summer 2014).
About the Author