Looking Ahead

What can we learn from past experiences? What does the future hold? How can we build on what we are doing now to ensure we do even better in the future? Part of the answers to these questions lies in the written word and our blogs, articles and White Papers are all created with this in mind. Find a little time, perhaps when travelling, to read more deeply and, if you have a moment to spare, let us know what you think.

Blogs/Articles

White Papers

• Starting a Virtual Team: In this White Paper we share our experience and give some advice on what to think of when using a dedicated virtual team in India.  We focus on how to define roles and communication processes and cover some of the cultural differences and give examples as well as some explanations.  The report also covers why it is hard to understand and communicate concepts over cultural borders.

• Cultural Challenges:  This paper describes some of the cultural challenges to consider when outsourcing software development to another country.  The report also covers some of the methods which can be used to reduce the risks and create better opportunities for long term success.  The report gives references to research in the area and we draw from our experience of running a successful outsourcing company for 20 years.

Starting a Virtual Team

To get started quickly with a remote virtual dedicated development team, it is important to define effective communication processes and take cultural differences on-board. In this report we discuss best practices for working with a remote virtual team, based on more than 18 years’ experience in India.

Introduction

Some companies have an in-house software development team but need to strengthen this with additional development or test resources. This may be on a temporary or permanent basis. Other companies have no software development resources of their own and let a subcontractor manage their entire development. A third case is when a company asks a vendor to develop a full project, either by writing the requirements themselves or letting the vendor do it. If consultants from the vendor prepare the requirements using expert input from the client’s country, or have extensive experience of international projects, this may not significantly deviate from outsourcing the work to a local company hence we will not cover that case in this report.

It is common to hear of failed outsourcing and, although we have more than 18 years’ experience of working in India for clients in Europe, we aren’t familiar with this outcome.  That said, of course there are challenges to be aware of but, according to our experience, it is possible to be successful in global software development by applying relatively simple and logical principles and methods.

This report covers the factors to consider in order to succeed with outsourcing to a development team in India.

How to start?

Our suggestion as to how to start is based on solid, practical experience, from working with many clients.  Rather than suggesting a specific process, we will suggest what kind of framework is required to succeed.  The initial and most important step is to create a strong relationship with the virtual team, and to establish early on exactly what expectations the client has.

“Rather than suggesting a specific process, we will suggest what kind of framework that is required to succeed.”

Even though we always suggest that it is best to meet face-to-face when starting any business relationship, we know this is not always practical or possible.  In those cases, we suggest using Skype or another video conferencing tool and share screens [1].

We suggest starting with an introduction of all team members on both sides (ideally over video).  After this, the client can show a presentation of their company, with focus on describing the context of the tasks to be developed.  The importance of need for the development team to understand the context for the project cannot be exaggerated.  It is obviously difficult to try and understand things which are taken for granted in the customers’ society sitting on the other side of the globe with a different world view.

The next meeting could be a demonstration of the product, or an overview of the different aspects of the product to be developed.  Screens and graphics are preferred to text or bullet points.

A third online meeting could be an open discussion to clarify input from the earlier meetings and to start to frame the task.  It is also important at this stage to define the project and decide different roles and processes to be used – from communication processes to how to check in source code.  We suggest two or three working sessions for this to avoid, overload information.

We normally record these meetings to be able to use them later if other employees would later be added to the team and circulate the working notes for client agreement and approval.

If a product already exists, it is advisable to let the team install this locally or, if it is a web-based solution, to get access and play around with the environment.  Also, the developers may need to install the relevant development tools, get VPN licenses, decide which communication tools and which version control tools will be used.  We have found Skype to be one of the best universal solutions since it works with text, voice and video and allows screen sharing.  But it is also essential to use some kind of Issue or Bug Tracker [2] to get a better structure on which tasks should be used or which bugs should be resolved.

If the developers have never worked with people from another culture before, it is essential to give them cultural training and frameworks to help them understand the cultural differences between them and the client.  We also describe specific challenges which may occur.  Ideally, we want to discuss these challenges openly with the team so that the best result is achieved when both parties meet halfway.  It is also good when the different participants have an open relationship, so they can discuss and work on resolving cultural challenges as and when they occur.

Roles

Indian society is more hierarchical than most Western

Follow up

Regular communication and follow up is essential.  This is required due to cultural differences, geographical distance and the limitations of electronic communication channels.  It is much easier to misunderstand things when communicating over these distances.  Follow up can be done in different ways.  It can be daily SCRUM-meetings over Skype and Indian staff can, at regular intervals, show their work via sharing screens.  It is also essential with high level follow up at management level to ensure that expectations are fulfilled.  Also, the management will have an overview of the special skills available with the company; they can support the virtual team with additional specialists, if and when required.

Challenges

We believe it is dangerous to generalise too much, as there are always differences between people from the same country or group of people.  Sometimes such internal variations can be much larger than the differences between people from different countries.  Having said that we still want to mention some theories and frameworks, which are useful to an understanding of some key differentiators.  The reader should however avoid stereotyping people from different countries.

Cultural differences

Leaders of global organisations must take cultural differences into consideration.  Culture is hard to understand since it includes language, traditions, values, humour and much more [3, 4].  Geert Hofstede is one of the main authorities on cultural differences in particular within IT.  He defined five cultural dimensions: Power Distance (PDI), Collectivism/Individualism (IND), Femininity/masculinity (MAS), Uncertainty avoidance (UAI) and Long/Short time orientation (LTO) [5].

• Hofstede used statistics from more than 60 countries [6].  He built his conclusions on some of the largest surveys ever done within this area.  They have since been repeated by others.
• Hofstede’s conclusions have been criticised. Some of this criticism is based on differing views of knowledge and have only academic value. The following concerns are however good to be aware of
  • The respondents were all employees of IBM which, according to Hofstede, reduced the risk of peripheral factors to affect the results. The critics have the opposite opinion. We tend to agree with the critics, since we think that in some countries these were not necessarily representative.

• “Hofstede’s framework can according to our experience be used to create awareness of cultural differences.”
  • The number of respondents per country varied a lot and while there were thousands of respondents from some countries, in others less than 50 respondents were interviewed.
  • Hofstede did not take regional differences into consideration (with the exception of Canada and Belgium, where he separated people with different mother tongues).
  • When Hofstede’s indices are presented, standard deviations are normally never mentioned, which means that it is hard to understand how typical the behaviour is in a certain country. An average where the standard deviation is huge can hardly be considered typical while if it is low it would likely be.
  • The surveys were made during the 60’s and 70’s. Even if Hofstede shows a relatively significant stability backward, the socio-economic changes in many countries (such as India) since then have been enormous [6, 7].

We are aware of and agree with some of the criticism above, but as per our understanding the framework itself can still be used to create awareness.  We strongly advise against using it to create blunt generalisations or expectations that a particular Indian will behave in any particular way, but when, the framework is used to increase understanding when certain phenomena are observed it can be helpful.  A word of warning is however required; we believe that South India of today, where most of the IT companies are located, deviates from the national Indices Hofstede presents on his web page [8].

In the survey we made, the respondents were decision-makers from our Western clients and Indian vendors, we found that power distance, uncertainty avoidance and time orientation were the most important challenges when working together [3].  Here is a concrete example which shows how complex a certain phenomenon can be, such as when an Indian has a hard time to say ‘No’, this can be explained by the following 3 dimensions:

• • Power distance: it is not acceptable to say no to someone with more power
  • Long Term orientation: it is important not to lose face now, tomorrow is another thing
  • Uncertainty Avoidance: if I say no, the customer may get angry.

Just to illustrate that westerners can also act cryptically from an Indian perspective, I will give an example of how a Swede may act.  We would often avoid criticism the first few times something happens, but when the same thing happens over and over again, we may either lose our temper or, to avoid a conflict, just request to terminate the collaboration without giving reasons.  The Indian staff, being used to more direct reaction, may never even understand that we reacted to the issue.

This reaction can be understood with extremely low uncertainty avoidance in Sweden.  In India with higher uncertainty avoidance, it is more acceptable to show reaction early, even with emotions.  Indians want feedback positive or negative as often as possible, since it reduces uncertainty, while Swedes have a tendency to give neither negative nor positive feedback.

While Swedes need to give more critical and positive feedback, Indians need to learn to say no.  But to learn to work together it is essential to be aware, meet halfway and understand the other party.  A westerner can help an Indian by asking open questions, avoiding ‘Yes’ and ‘No’ answers, or ask the Indian staff to get back with his or her answer after proper analysis.  When both parties are fully aware of the cultural differences it is much easier to overcome them.

“Meet cultural differences without a judgemental attitude, but don’t accept unprofessional behaviour.”

Apart from Hofstede we would like to mention Hall, who also defined a number of cultural differences.  One we have found very useful is High/Low Context dimension.  We find this dimension useful since the Indian culture is very high context, which means that a lot is read between the lines, context is important, body language is more important.  Since electronic media is bad for high context communication, this becomes a big issue.  In face-to-face meetings and when video conferencing is used, it is normally easier to see when the other party misunderstands something.  On the other hand, emails and specifications are often very low context in nature and the risk of misunderstanding is higher.  In a table later in this paper we will give some examples of differences we have experienced which may have relevance for global development teams.

It is essential to meet cultural differences without a judgemental attitude, however this does not mean that unprofessional behaviour should be accepted.  We recommend walking the extra mile to create such awareness with all participants involved in the outsourcing process that problems and challenges are always communicated as early as possible and that hurdles are resolved.  This is not a one-sided process; there is something here for everyone to learn.

Everyone involved can be trained in cultural understanding and by reading suitable books and articles dealing with this subject.  Since aspects of cultural differences may be sensitive, it may be good to start slowly and coach and train all participants over time.

To meet and get to know each other creates a good foundation for avoiding cultural misunderstandings.  In our experience, social interaction helps to improve the professional relationship.  We have also found it very fruitful when differences in culture and understanding are discussed openly.

Regular follow up using daily reports, and/or SCRUM meetings over Skype can help the client to better understand what is happening and avoid unexpected surprises.

When using video or telephone conferences, it’s recommended that one of the team takes notes and writes the minutes.  This gives the western customer a chance to read and assess if the team has understood the context right.

Examples of cultural differences

The following list is written as a guideline on what to be careful with.  It is of course a generalisation and should only be understood as that.

• Inability to say no: Indians often say ‘Yes’ when westerners would say ‘I am not sure’ or even ‘No’. An Indian developer would, for example, often answer ‘Yes’ on the question if a delivery can be made at a certain date, even when he/she is not certain if it is possible to deliver on that date.  Asians in general avoid negative answers for cultural reasons.  This is also the reason why an Indian may avoid asking a question when he or she does not understand.  This behaviour is based on the cultural dimension Power Distance, uncertainty avoidance and long-term orientation.
• Leadership style: Western Managers would in general not ask every day how an employee is managing a task, since this can be understood as if he or she does not trust the employee. However, if the manager does not follow up frequently, an Indian employee may get the impression that the work she or he is doing is unimportant.  Western managers as a rule focus more on result than behaviour, ie that the work is done, while Indian managers focus more on the behaviour, ie how the work is done.
• Risk taking: Westerners on average take larger risks based on relevant assessment of what can go wrong, before starting a task. They generally understand it as more important to deliver on time even with some misunderstandings, rather than waiting for a delayed answer from the customer before starting [9].  Indians on the other side tend to wait to start work until they have got answers on critical questions even if this may lead to a delayed delivery, thinking that the customer must understand that they could not start because they did not have the answers.
• Conflicts: Swedes are often scared of conflict [9] and could therefore avoid communicating their dissatisfaction. Indian staff can easily understand this lack of negative feedback as a sign of satisfaction.  In addition, since Indian companies often have experience working with American customers, who tend to show their dissatisfaction in a more direct way, makes it even harder for them to understand subtle comments which may indicate dissatisfaction.
• Appreciation: According to our experience, working with customers from different countries, we would like to generalise saying that Indians and Americans would say ‘great’ for an average performance, while Swedes would often not give any feedback unless the task is done way above their expectations. This may make Indians think that Swedes never get satisfied.
• Private Life: In many Western cultures private life and work are held apart, while in many other cultures, work life is more integrated with private life. In the former case, work time is more or less completely used for work, while in the latter non-work-related activities may also be done during work time.  This does not necessarily lead to lower productivity, since people in general are at their work place more hours to compensate for this and since the culture encourages people to use more simultaneous capacity.
  
• Time perspective: In a British study it was found that Indians have a much more flexible experience of time and dates, than the British [10]. This was due to a difference in how time was understood culturally.  It is clear that certain types of delays must be accepted, e.g. power failures, traffic jams, flooded streets due to monsoon, rains which lead to a stand-still in public transportation and hospitals which demand that a relative must be with the patient at all times.  But this does not mean that it is ok not to communicate to a customer about the delay.  In addition, processes and frameworks must be constructed to manage such delays.  Other types of delays due to cultural differences should not be accepted, and any professional organisation anywhere in the world working with another culture must ensure that quality and delivery can be maintained with a minimum of disturbance.  We believe that communication processes should always include early warnings and that customers should clearly inform the Indian vendor early when this is not working.  Having said this it is also important to understand that delays due to cultural differences are not necessarily a sign of dishonesty or carelessness.

Tacit Knowledge

“Tacit knowledge can never be transferred via text or through simple explanations. It always includes an element of experience.”

Even though cultural differences are one of the main reasons for problems with IT outsourcing, there are others.  One is linked to what is called ’tacit knowledge’ (silent knowledge, the knowledge that we cannot document, communicate or transfer in any simple way) [11].

This can be a problem even when outsourcing to people from the same country and culture.  The opposite of tacit knowledge is explicit knowledge.  But since all explicit knowledge requires some amount of tacit knowledge to be meaningful, this distinction is problematic.  Even if it cannot be directly transferred it can be experienced.  Pictures, diagrams, photos, examples can be used to communicate tacit knowledge.  Tacit knowledge includes things like context, experience and assumptions.  Surprisingly often when we say, everyone would know, this includes tacit knowledge and may not be obvious at all to someone who does not have the same context in mind.

Mostly people are not aware of the tacit knowledge they possess and how it can be valuable to others.  Knowledge which is taken for granted is often very valuable, if it can be made concrete.  Effective transfer normally requires a long personal relationship and trust [12].  Tacit knowledge can, in principle, never be transferred via text or through simple explanations in the way we can transfer explicit knowledge.  It always includes an element of experience [12].

Tacit knowledge is a generic problem and in no way specific to cross-cultural communication.  But the transfer of tacit knowledge can get more complex, when the parties are from different cultures and in different locations and, since most communication is done via electronic media, it is essential that all participants avoid any assumptions about the other participants’ situation and limitations.  Instead it is essential to ask for clarifications and give fast feedback to avoid any form of misunderstanding [13].

To map and document tacit knowledge is essential in every kind of successful IT project implementation.  But there are no standard methods to transfer this knowledge.  It is possible by using concrete methods based on the situation.  We have had onsite monthly meetings, where key personal have met and gone through last months delivery and discussed what is to be included in the next months.  Other examples include photographing the environment the system will be used in, visits to the venue, video, prototypes, mock-ups etc. [13].

Conclusions

In this report we have discussed challenges and solutions as to how to be able to work together effectively.  It is essential from the beginning that the Indian team gets a good overview and that roles and processes are well defined.  Continued follow up and on-line meetings are also essential.  Finally, we would like to refer to a study [15], which shows the most common reasons why outsourcing projects fail.  Note that these are in no way specific to outsourcing across cultures and are valid for more or less any long-term relationship between parties

• Unclear expectations from the customer
• Unclear requirements
• The needs and interests of the parties change over time
• Poor governance in handling the relationship.