Offshore development

2007-01-12

Thinking about moving software development abroad?

You have heard of other companies employing offshore software development firms to achieve significant cost savings with their IT projects. You may have heard of some of the issues they confront in realising offshore projects. You want the cost advantage but aren’t ready for the risks involved and you don’t want to trade off quality for price. Here are some questions you should ask yourself (and your offshore partner) before you begin:

hong kong peak

What are the risks involved in offshore development?

The risks are basically the same for offshore and onsite development. The major issues are always (a) time-to-market, (b) cost, and (c) quality. The questions are: When is my project completed, how much will it cost, and will it comply with my quality standards?

However, there is one big difference in offshore outsourcing: the way you control these issues. The challenge added by taking a project offshore is therefore a management challenge. Due to the geographical distance, you cannot simply look a programmer over the shoulder or call spontaneous meetings.

If this challenge is ignored, the business risk of software development becomes unmanageable. Hence, suitable methods of communication and control must be in place to manage offshore projects.

How can offshore projects be managed efficiently?

The key to successful project management across continents lies in effective communication. Your offshore team must be able to connect to you and vice versa. You probably need to deploy special technologies that allow you to monitor ongoing projects at all times. Besides phone and email, these technologies might include VoIP/online conferencing, instant messaging, online collaboration software, and probably a project management system. A professional offshore contractor has respective procedures and technologies in place.

The three aspects of communication that need to be observed are (a) transparency, (b) availability, and (c) response time. Communication partners should be appointed, communication channels must be chosen, and the forms of communication must be defined at an early stage. Clearly structured specifications and instructions are just as essential as regular front line feedback and quality control.

Isn’t there a big overhead involved?

The criterion that defines overhead is the quotient of time used for project management and the time used for implementation. The overall goal is to keep this quotient as low as possible. This ratio increases when either the implementation task is small in terms of man-hours, or the management portion of a particular project is large.

Experience shows that certain projects are suitable for offshore execution, while others are not. Very small projects and projects where the desired outcome is not well defined, such as research projects, are less suitable while projects with a well defined output are suited best. Of course, overhead can also be cut by outsourcing project management along with the implementation.

How big are the cost savings?

The cost savings can be substantial. How big are the they? - Of course, it depends on the project. Example: Let’s assume that your offshore contractor’s rates are 40% lower than those of your local onshore vendor (which is conservative!) and that management overhead increases from 10% onshore to 20% offshore, meaning that productivity decreases from 90% to 80% by taking the project offshore. The latter results in a cost increase of factor 1.125 to achieve the same output. Let’s further assume that the project’s volume is 40,000 USD and that you finance a 3,000 USD business trip for a meeting out of this budget. The cost for achieving the same results offshore are thus (40,000 USD 0.6) 1.125 + 3,000 USD = 30,000 USD. Your cost savings are 10,000 USD, or 25% of the original volume.

Is offshore always better than onsite?

Certainly not. Not every work can be outsourced profitably. Some types of work involve a large portion of communication and management. These can only be outsourced if management is outsourced as well. Furthermore, economy of scales defines a minimum project size. Since management overhead tends to increase logarithmically rather than linear, the management / production cost ratio is high for small projects and it may thus eat up cost savings. On the other hand, this means that your savings are even bigger if the outsourced volume is large. It is difficult to pinpoint an exact threshold value for project size. As a ballpark figure, you should look at outsourcing when the project size exceeds 1,000 man hours. But even smaller projects can be outsourced successfully if the team members play well together.

When is it worthwhile to outsource IT services?

The key criteria:

  • Is the project rather large in terms of man-hours?
  • Are the expectations well defined?
  • Are there written specifications, instructions, rules and other guidelines?
  • Are these in English or in a language that the contractor understands?
  • Does production involve a large portion of labor-intensive work, such as coding, debugging, data entry, etc.?
  • Is overall complexity manageable?
  • Are you using industry standard technologies?
  • Can output and productivity be measured?
  • Do all involved parties communicate comfortably in English?

If you can answer most of these questions with ‘Yes’, you should think about outsourcing. If you answer some of the questions with ‘No’, outsourcing may still be an option, but you should look carefully at the project parameters. Types of work that are well suited for outsourcing are:

  • Software adaptations and maintenance
  • Porting existing applications to new platforms
  • Development of software components and plug-ins
  • Traditional application development
  • Web development, web design, and graphics development
  • Multimedia development and CD-ROM productions
  • Data entry, archiving, and image processing

What about the language barrier?

Language is an important issue. You should make sure that you can communicate comfortably with all team members, especially with the responsible project manager. Programmers mostly speak some English, because computer books and technical documentation are often in English. Make sure the level of fluency of your partner is adequate, especially if you outsource to a location where English isn’t widely spoken. It is important that your team understands the requirements and functional specifications exactly. You don’t want to spend time and money on correcting human communication errors. If the developers are fluent in English or in your native language, then the language barrier really does evaporate.

What about cultural differences?

From the management perspective, some cultural issues are important. Cultural differences can mean increased difficulty in communication and work process organisation. Keep in mind that different cultures have different ways to get things done. You should be at least somewhat familiar with the culture of the country you are outsourcing to.

Let’s assume you are outsourcing to Asia. Asia is both geographically and culturally farther from Western cultures than, for example, Eastern Europe. The Asian business culture is very service-oriented and pragmatic. However, you might find that your Asian partner appears to be less frank about problems and difficulties. Although Europeans and Americans often perceive this as a lack of transparency, from the Asian perspective this is actually a matter of courtesy. It would be impolite to confront the customer with too many problems and questions, since it is the contractor’s job to resolve these in the first place.

Probably the most important thing is to keep the team focus positive and to make sure that your team understands your requirements. In doing this, you need to take the cultural peculiarities into account. This may sound more difficult than it actually is. People usually enjoy working in an international team. Once the initial barriers are overcome, it may be just as easy and pleasant as working with your home team.

What about the time difference?

You need to look at the office hours overlap of your and your partner’s location. If you are in Boston and your partner is in Beijing, there may be zero overlap. This means you won’t be able to do online meetings, phone conferences, or instant messaging during your usual office hours. If you are in Germany and your partner is in India, you will have 3 to 4 hours overlap. On the other hand, the time difference might work to your advantage. When you begin your work day in the morning, it’s already afternoon in Asia if you are in Europe, or evening if you are in the US. Most of the day’s work is done at this point, perhaps already waiting in your mailbox for you to review.

The legal framework is normally provided by a consulting agreement (or a development contract) that governs the cooperation and defines all its details. Such an agreement is often accompanied by functional specifications which describe the technical aspects of a project. It may be supplemented by additional agreements, such as non-disclosure agreements.

One important question in international contracts is jurisdiction. If the place of jurisdiction is not agreed upon in the contract, it will either be the country where the agreement is executed, or where it was signed. If you want the contract to be governed by the jurisdiction of your country, you must state this in the contract. Whether this makes sense is another question. If a dispute should ever goe to court, it is unlikely that your contract partner will show up, unless he has a representation in your country.

The terms that govern compensation are probably the most sensitive part of the agreement. You should strive to build some risk protection into the payment terms. At the same time, you need to find terms that are acceptable to the offshore developer. This is not always easy. There are a number of models to choose from, including lump sum agreements, fixed cost and date, time and material, limited time and material, and other options. Which one you finally choose depends on the nature of your cooperation.

Risk reduction is in the interest of both parties. You should avoid large upfront, interim or final payments, and choose smaller more frequent payments instead. It is also wise to define milestones and agree to make payments dependent upon the fulfilment of these milestones. Some customers may feel the need to build penalty clauses into the contract for additional protection. This is not always a good idea. Penalty clauses offer little protection if you are not sure whether they can be enforced.

It is probably better to prepare for success than for disaster. This means you should invest more time into defining the technical aspects, responsibilities, deliverables than into defining the subtleties of legal protection. A qualified lawyer may be able to help you with this.

IT Management