In the United States, you'll hear an array of responses when you mention the word offshoring.
Offshoring is hiring less expensive resources from a different geography. It's not a new concept. The industry has seen both successes and failures in the implementations of outsourcing. For some it creates solutions, and for others it creates headaches.
There is no formula for success. However, you can improve your odds for successful outsourcing.
Whenever you hire a developer for a permanent position, hire a contract developer, or hire a consulting firm, expect that they know nothing. I know - you've worked hard to select the best possible person or firm and you feel like you should expect excellence from them. Perhaps you will receive excellence from them, however, expecting it is a recipe for disaster. Not expecting it means a little more communications, perhaps awkward communications, but not a substantial time investment.
Fundamentals of instructional design and teaching say that we don't learn evenly. (For instance, Piaget's Developmental Theory exposes this through the concept of "equilibrium," whereby repeated experiences are easier to learn, and loss of equilibrium where uncommon experiences require changes in cognitive structure to accommodate them.) We all have gaps, holes, and craters in our knowledge. While we may be substantially intelligent and experienced, there will be something that we don't know that another practitioner might believe is obvious. We must challenge our beliefs that our teammates are aware of something just because we are.
Consider a CFO at a large multi-national organization. He might be clearly intelligent and thoughtful. However, he may be equally incapable of performing even the simplest repair such at installing a new keyset in a door. He's not dumb by any stretch; he might just have a small gap in his knowledge when it comes to some mechanical activities.
When selecting an outsourced partner, look for assurance that the partner knows how to develop software. Look for organizations with a high number of certified developers. Seek out Software Engineering Institute CMM Level 5 organizations. (www.sei.cmu.edu) Check references and perhaps run trial projects.
The problem with this has two parts. The first is that little or no independent research indicates a correlation between IT certification and on-the-job performance. Most of the studies that are used to show correlation have been commissioned by the organizations that are the purveyors of the certifications.
Most certifications today rely upon multiple choice standardized testing to certify candidates. This simply isn't a foolproof indicator of on-the-job performance. The Cisco CCIE exams are rumored to have a pass rate of approximately 2/3 of the candidates, and the lab portion (read: "Real World") is estimated to have 1/3 of the candidates pass.
It's little wonder that there may be little correlation between certifications and job performance. Someone who is a certified developer may or may not do better than his uncertified peer. I'll qualify this to my experiences and say I've not personally observed a high correlation between job performance and having a certification. I still look for it as an indicator, but it can't be treated as an assurance that the performance will be better.
The CMM certification process stratifies organizations based on their perceived level of software development competency. Organizations at Level 1 are perceived to have a low probability of reliably producing quality software. Level 5, the highest level, is reserved for organizations that are perceived to be operating at an optimal level. However, even organizations that are certified CMM Level 5 may or may not be operating at this level on every project. They may have a core team, perhaps one that makes frameworks for the rest of the organization that has been certified CMM Level 5. However, how do you know if any of the people that you'll be assigned follow this process or have experience with it?
The second part is that the people you get for a pilot project are likely not the same people that will perform the real project. I'm not suggesting any lack of integrity or slight-of-hand here. I'm simply stating that resources that tend to get scheduled for pilot projects are not those that are likely to be on long-term projects. The folks assigned to short-term pilot projects move from one pilot project to the next. Since you're creating an outsource partnership, it's likely that you'll be looking for folks to work on long-term projects.
However, not knowing whether you have a good developer, an average developer, or a poor developer is the same challenge you face as you hire folks locally. Similarly you don't know if they have experience with web applications, logging, batch queues, or any of the other technologies that you need.
It is your responsibility to ask what experience they have with something, to expose areas you need to train them in before they start coding. And it is your responsibility to promptly (read daily) review their code and make sure that it's meeting your objectives.
If you expect that no developers have all of the knowledge that they need and that it's your responsibility to train them, you'll find that things just work out better.
Pick up any book on Agile in any form. Pick up a book on Lean development. Pick up any book at all on traditional software development in the last 20 years, and you're likely to find a major focus on communications as a key ingredient to a successful software development project. Even if the book doesn't explicitly call out communications as a key ingredient to software development, you'll likely find undertones that lead you to the same conclusion.
In these same books, particularly those that advocate agile development practices, you'll likely find a discussion on the warmth of the communications options that you have. Face-to-face open dialog on a whiteboard type discussions are perhaps the richest, and written languages are the least rich. This means that an hour of time spent in a face-to-face meeting may be several times more effective than writing the same thing down. This is not to suggest that writing isn't important or required--simply that this is a framework on which direct face-to-face communications should be hung like a skeleton. It isn't the complete solution.
However, when communicate with offshore partners, we are limited to video meetings at best and written communications at worst. Is it any wonder that communications is a challenge?
Working with an offshored solution requires a substantially greater focus on communications when you have two people in the same room. The sort of random, informal, ad-hoc meetings that happen daily and accidentally when people are in the same room must be replaced with some sort of a communications infrastructure. Without this infrastructure, the project is necessarily doomed to fail. Of course, at any time, whether in the same room or across the globe, people can choose to stop communicating. That is the project creating its own demise.
Creating the infrastructure can vary by organization and by partner, but I suggest a minimal set of documents to get you started. First, have a set of overall approach documents for different parts of the system. They are descriptive rather than prescriptive (for the most part). They describe the design patterns that are preferred, allowed, discouraged, and disallowed. They describe the architectural approach that is being used--for instance in bridge-building it would specify whether the bridge should be an arch bridge, a suspension bridge, or some other sort of bridge. These documents don't necessarily explain all of the details; their objective is simply to provide a foundation.
The second deliverable is a program specification. The specification should include what requirements and design feature points are associated with the program in question, as well as a more detailed--but not necessarily explicit--account of what the program should do. If possible it should refer to the test scripts and cases that the program will need to pass.
The one important part of the program specification is the encouragement (or requirement) of questions. You'll never write a program specification that answers all of the questions that a developer might or should have--if you do, you're spending too much time on them. You have to expect questions. You should encourage them and document the answers with the program specification. For this reason you should consider sending documents a few days ahead of when you actually want work to begin.
So if I didn't scare you with the understanding that writing is not the best means of communication and that writing is hopelessly inferior to face-to-face communication at a whiteboard, let me warn you off of another impact. One very dangerous thing is assuming that the person you're communicating with actually understand what you mean--particularly when you're working with someone for whom your primary language (mine is English) is a secondary language. When I first started my career, I was working with a company that imported some products from the Far East. One of the very sage words of advice from someone who traveled a lot was to always ask a question where the correct answer was "No."
Several important factors make this an important question to ask. First, asking the question is the necessary step in verifying understanding. It is fundamental in all relationships, whether in the same room or across the globe.
Second, when faced with partial understanding, people in most cultures--particularly in business relationships--tend to respond in the affirmative. They want to make the business partner happy, so they say, "Yes," rather than,"No." For most folks, saying, "No," is more emotionally strenuous than saying, "Yes." By asking a question that requires a negative response, you force the person to be sufficiently confident in their understanding that they're willing to tell you, "No."
I'm not saying that the offshored team members that you'll be working with won't understand what you say. Nor am I saying that they will intentionally mislead you into believing that they understand something that they don't.
What I am saying is that natural barriers may exist, and it takes extraordinary people to get past them. I know and respect several folks who have gotten past them, and I am enriched by their friendship. However, I am simultaneously aware that I have many more relationships that I personally have to work for understanding and trust.
No free rides
I have no particular predisposition to believe that people from any country should be granted a free ride when it comes to jobs. Not being a politician by nature, I believe those that are the smartest--who solve problems best and have the best education and experience--should receive the work.
That being said, many developers in the U.S.--and I suspect the rest of the world--are sleeping. They believe that because of where they live and how they were brought up, they deserve a job. I disagree. Work hard to be the best developer you can be, and you'll find work. Don't try to learn, grow, and think, and you'll have trouble no matter where you live.
I don't advocate outsourcing as a strategy except in very specific circumstances where communications is easy, the problem is well known, and the outcome is straightforward to see. That does not mean I have the correct view of the opportunity that outsourced development brings. It means that I am biased towards applying it in the situations where it has demonstrated to me that it works best--not in ways that have questionable results.
Offshoring does make sense in some circumstances, and it's a valuable business tool. However, go into the experience with your eyes open.