Working with Offshore Partners: Opportunities, Challenges, Cultural Issues

By Thomas Eklund

I wrote this article in 2007. Time has not decreased its relevance.

Opportunities

Here in the US, where competition for IT projects is intense, most customers expect and want high quality results on time, for a predictable cost that, preferably, is as low as possible.

At the same time there is a shortage of good quality, highly skilled programmers in the US.

One way to handle these issues is to combine locally based and remotely located project developers work.

The customer company can hire one or more project developers who focus locally, on site, on tasks where direct interactions with the application's future users contribute the most to the application's quality. The rest of the tasks can be handled by remotely located development team members. Such teams can be set up so, that together the developers cover all the necessary aspects and stages of computer application development.

For complex projects that require different types of skills and knowledge, it would be pretty difficult to find application developers locally who are absolute masters in all the needed areas. Working with remotely located developers allows to combine skills on as needed bases, hire the right people for all the needed tasks and deliver the results for a very competitive price.

This work structure can lower the total cost of the projects 3 to 5 times, while allowing to produce high quality end results that meet the users needs and wants.

There's another benefit to this arrangement. Working with remotely located developers can make the development team a more stable and reliable service provider than it would be if the team members would be hired only locally. The work structure that is described here creates a much bigger and diverse pool of talent to choose from. In many instances customer can select between hiring a single contractor, a small team of developers, or an entire company to work on specific tasks. This makes replacing contractors also a much easier task.

So, this approach makes it easier to ensure that all the tasks are completed as needed.

Further, the more companies work this way, the fewer foreign worker visas are needed and the fewer programmers need to move to the US. The more programmers can stay in their home country and make a good living without having to move to the US.

In addition, such an arrangement is a step closer to meritocracy, where people who work together do so because their skills are well suited for handling the necessary tasks. This means higher participant satisfaction, which in turn results in better quality work results.

Challenges

Working with remotely located developers with whom you do not meet on regular bases poses special challenges no matter how near or far the developers are. Without thoroughly understanding the relevant challenges and mastering the solutions it's easy to incur more losses than gains.

Choose the Contractors for the Right Tasks

Project developers who work locally with the customers and are responsible for the quality of the outcome must be good at selecting suitable team members with whom they work remotely.

The best quality results are achieve if the relevant parties handle the tasks that they are good at. Application development requires different type of input and a particular developer, development team or even an entire company may be truly good at handling only selected tasks.

It is less likely, that customer needs and wants analysis can be done successfully remotely. Similarly, it is less likely, that conversion of these needs and wants into customized computer application functionality parts will produce satisfactory results, when all of the needed work is handled by remotely located developers.

However, remotely located developers can very effectively handle specific development tasks, when they receive clearly stated requests and the collaboration and communication processes are set up effectively.

Understand the Nature of the Communication Process

Communication with remotely located application developers becomes challenging when complex requirements need to be implemented programmatically. How do you make sure that people in another culture, far away, understand something that you wrote the same way you understand it, when what you describe is rather complex?

The answer is in the combination of dividing the functionality descriptions into small functionality pieces, having the application developers communicate their understanding of the functionality back to you, and using both functionality descriptions that assess the application from the users side and from technical specifications side, in addition to also using a prototype.

The more complexity, functionality and user interfaces the planned application involves, the more important role does a prototype have in the development process.

Prototype allows the application's future users to see what the application will look and feel like before the development process enters the heavy duty programming and development stage. So, the necessary changes can be made well before the users start testing the actual application.

The developer, who works directly with the application's future users, should drive the prototype development process and usability engineering. Using the prototype, the developer can handle the user interface design and other usability-related tasks and find suitable solutions, working directly with the users.

Further, prototype is a communication vehicle that helps to convey the requirements to the application developers, and, as a result, can considerably shorten various application development steps.

Understand the Nature of the Challenges the Overseas Application Developers Have to Face

Many remotely located application developers whose work can be obtained for a relatively low cost are very highly skilled professionals. However, when people churn out relatively simple applications for most of the time, they may have difficulties with implementing more complex requirements that need more thorough analysis to begin with.

To put it differently, people who are expected to produce results inexpensively, usually have to produce them under considerably time pressure. Working this way can become a habit that gets in the way, when more complex requirements need to be implemented.

The less time the developers and their project manager have for becoming familiar with the requirements, the more likely it is that they will not implement the requirements correctly.

This time crunch issue often seems to go together with the cultural issues that are addressed below.

Unwillingness to clarify assumptions, infrequent communication and less than sufficient feedback can also cause substantial problems. These problems seem to be related to both lack of time, cultural issues and willingness and ability to communicate in writing.

Address Quality Control on Continuous Bases

No matter what development methodology is used, bug fixing is an inevitable part of the development process.

When working with the overseas application developers, the more complex the application, the more likely it is that quality control can create problems if not addressed methodologically.

People who are expected to produce results inexpensively can allocate less time for quality control and, it seems, may be also less used to doing thorough quality control.

Thus, the developers who are responsible for the application's quality have to work out and rigorously enforce quality control and standards. The more complex the functionality part is, the more minute parts of the functionality should the quality control processes assess from all the different angles. This is a continuous process that has to be repeated for these functionality parts where bugs are found.

Cultural Issues

This article addresses two geographic areas of well-qualified and affordable outsourcing contractors: India and Eastern Europe. China, the rising "super power of outsourcing," is not part of this article's focus.

Speed, Communication and Customer Service

There's a pretty big difference between working with Indian and Eastern European contractors.

Indian contractors generate the solutions to your specifications. They do the work quickly and in many instances they do it very well, if you ask them to perform tasks that are within their area of expertise.

Of course, communication issues apply. So, unless the specifications are communicated well, misunderstandings can easily happen. However, if you work with a reputable contractor or company, then any problems resulting from minor misunderstandings are usually corrected quickly.

Indian contractors may do the job to your specifications - or the way they understand the specifications - even if they know that what you want to be implemented is not a very good idea, and better options exist. Further, if they have better ideas, they may not tell them to you, unless you explicitly encourage them to do so - and some Indian people seem to have difficulties with expressing consenting views even when they are encouraged to do so.

However, if you know precisely what you want, and you need it to be done quickly and as cost effectively as possible, it's likely that Indian contractors are very well suited for the job.

Generally speaking, Indian contractors tend to provide better customer service than Eastern Europeans do. That, and reduced stress levels that are associated with good quality customer service, make a big difference in many instances.

On an average, Eastern Europeans tend to work at a slower pace, and are much more opinionated. The latter may be a good thing: if you need feedback on your ideas or development approach, it may be hard to get that from the Indian contractors. In some instances the latter may be a real problem.

However, Eastern European contractors are more likely to provide their opinions, whether you ask them for that or not.

Further, Eastern European contractors are more likely to act on their convictions and ignore your input. In such instances, when the contractor is convinced that he or she knows better how to accomplish something, and is wrong about it, it is likely that he or she will attempt to take the project development in the wrong direction. If you react to it too late or less than firmly, you can assess and try to deal with the damage only after it has been done.

Language abilities can also create obstacles.

It seems that the overall ability to communicate in English is better in India than it is in Eastern Europe.

Working virtually, so that technology connects dispersed participants, requires in many instances written communication, which requires good typing and language skills and aptitude for written communication. That seems to be a problem for a lot of people in any part of the world.

To overcome this issue, the party that drives the project's development has to know what information and when needs to be exchanged. If the outsourcing partner is sufficiently service-oriented and continuously provides the needed information on time, things can work out well. Otherwise, virtual working arrangement may not be a good solution.

Design

Eastern European application developers tend to produce better quality and more original web and user interface design. Indian developers generate "mass produced" solutions very efficiently which, of course, are not particularly original and do not reflect the true nature of the customer and the product very well, and do not help to differentiate the website owner company or the product offering positively. Of course, there are exceptions to this and good design solutions can be created when working with Indian designers as well, especially when the solutions are generated collaboratively.

Information design and application navigation structure design tend to be poor in both regions.

If truly good, original design, information architecture and application navigation structure are important, it's more likely that a suitable solution provider can be found among the best US or Western European companies. The best of these companies do charge considerably higher fees, but in many instances the higher fee is a worthwhile investment.

Location, Cost and Attitude

In many instances Indian contractors with comparable skill sets are less expensive than Eastern Europeans are, and there are somewhere 4 to 10 times more of them (depending on the exact area of expertise in question).

Both Indian and Eastern European developers favor open source solutions, especially PHP and MySQL. However, if you need to work with Microsoft's technologies, it's easier to find good quality solution providers in India than in Eastern Europe.

Good quality programmers can be found for good prices in relatively "far East" in Eastern Europe, like Ukraine or Belarus, for example. However, it's difficult to hire people or companies from there or from other parts of Eastern and Central Europe. Fewer contractors from these parts of the world use online marketplaces, where many highly qualified Indian contractors and companies can be found. However, if you happen to know or can find people who are familiar with the specific Eastern European country's culture and act as facilitators, your chances of finding the right professionals from specific countries in that part of the world are much better.

Briefly, things in Eastern and even Central Europe get done largely by "knowing the right people," while Indian companies operate more following Western style open market principles.

The more west you go in Europe, the more expensive the European contractors tend to get. For example, good quality Central European contractors (from Poland and Rumania, for example) are no longer in the affordable price range. Similarly, in the Baltic States (Estonia, Latvia, Lithuania) you can find mediocre developers relatively inexpensively, but good ones tend to cost considerably more than equally good Indian contracting work does. Further, often enough the contractors in Central European countries tend to set their prices by Western European standards, while producing results whose quality is measured by their local standards.

In addition, if you hire really good programmers or designers in the Baltic States or in Central Europe, it is likely that you will have to deal with the persons egos quite a bit along the way. This can get annoying and in some instances can make working together prohibitively difficult.

There's one more factor to consider: time difference, which in the US East Coast favors Eastern European contractors and in the US West Coast favors Indian contractors. Workday starts in most Indian companies around the time it's very late at night in the US East Coast. The time difference between Eastern and Central Europe and the US East Coast is smaller.

However, in many instances the communication process can be set up with 1 day delay without problems, especially when issues, code and other development work needs to be reviewed anyway before response is sent out.

Summary

An ideal solution in many ways is to have a mix of good quality, dependable solution providers-partners in different places. This allows tapping into each contractors strengths and allows to reach different projects objectives so that high quality software solutions can be delivered for very competitive prices.