Think you are saving big money by offshoring? Think again. You always get what you pay for.

Yes, in the short run, paying offshore developers 25$/hr may seem like a great deal.  However, companies must be aware that there are a number of hidden costs.  Some are avoidable if you know the cause.  For example, you might have an on-shore person spending a lot more time managing the engagement, taking more time to detail requirements - as much time as they may have previously spent on building the application in-house.   There could be costly errors if the offshore developers do not understand the business needs and requirements; this can be corrected if you have an on-site business analyst and/or if you can connect your off-shore team with your stakeholders.  However, the problem that many US managers complain about  is Quality - whether the off-shore developed code is maintainable and working - or is it spaghetti code and full of bugs?

If there are any quality issues, your on-shore resources will be discovering them, spending their much more expensive time debugging, reporting issues, and so forth. 

I'm currently managing a project where a vendor is developing customizations off-shore.  I'm not sure what kind of testing they are doing, if any.  I do know that we get their code deliveries, myself and a number of other highly paid business people are spending many cycles testing and reporting issues.  I know the vendor was selected because of their low prices.  But if I had it to do again, I wouldn't.  In fact, I'm incredibly overjoyed that by a stroke of good luck, my other current project has gone from off-shore resources to - not only on-shore but on-SITE resources.  The progress that can be made when the developer can show his prototypes and talk directly with the stakeholders is well-worth the cost.  It all comes down to - you get what you pay for.

I don't have a problem with non-American developers, as some do.  I'm not xenophobic and I'd be happy if other countries reached our same standard of living.  But over the years I have been a consultant or have been  managing projects, I have seen that on-site, co-located development teams are far more effective.  It doesn't matter what their background, race, or ethnicity is - it's all about whether you can talk face-to-face, be on the same timezone, and - in the case of quality issues - can make them accountable for their work. 

If you really want offshoring to work, there are a few things you might want to pay attention to:

• Make sure your offshore team has really good phone connections.  Even with the best English, if the phone connection is poor, communication will suffer. [Insert your language where I used English, which is the language I use to communicate.]
• Invest in good online meeting technology, such as WebEx.  The ability to share screens and voice conference is so important, whether you're sharing your requirements, or seeing a demo of something they have built for you.
• See if you can establish at least some shared hours, if your on-site and off-shore resources will be working together.  It can be so frustrating waiting 12 hours for an answer, or if you can never talk real-time at all.
• Try to have someone from the offshore facility come to your site, meet the people s/he will be working with, and learn about the business.  It will personalize the people that are working together, increasing cooperation and communication. And obviously if your off-shore people are working on or supporting business applications, it helps if they have some context.

And remember - contrary to what I recently read in a business textbook - programming is not like digging ditches.  One programmer cannot simply hand off his train of thought, creative process, and so forth to another programmer at the strike of the clock.  You are not going to have a magical 24 hour development cycle.  Instead, you will have various 8 hour development cycles going around the clock.  Now, if you have a service desk, you might get this.  But not with software development.

why won't you do what I ask?

Today I was so frustrated with my offshore development team that I had to google "Offshore team doesn't listen to me." Yes. I googled a full sentence. Not surprisingly, I got a few results.

My specific problem is that I request repeatedly for them to do something. For example, tell them that the app must use a web service rather than handle some integration internally, so that we can use that web service for multiple applications. Or perhaps as simple as telling them that the system must point to a particular Dev server, not to QA or Prod at this time. And no response. They dont' say they're not doing it, but they don't confirm they're doing it either. Meanwhile, the latest version I received is still not doing what I asked. At the same time, I get long emails from them describing bizarre situations they've thought about and want to know the answer to. "If a pink elephant logged in and pressed this button, what would be the expected result?" ARGH! I end up having to chase these strange requirements questions down, despite the fact that I've written clear requirements. These fools' errands distract me from the fact that they are not doing what I've asked them to do. But, it would appear, I am not alone. Witness the following entries of my fellow blogger (paragraph 2 or 3):

http://tarkatronic.blogspot.com/2007/08/management-frustration.html

At any rate, I think this is the hardest thing about managing any project where the worker(s) are anyone but yourself. You have to ask other people to do things. And they might not do them. They may not do them correctly, on time, and they may not respond to you at all. And how do you deal with that? Are you a rant & rave kind of person? Don't think so quickly that you're not because I've found you don't know how you're going to react until you face this situation. I find myself completely at a loss. I would certainly like to yell about it right now, but wisdom tells me that it wouldn't get me anywhere.

I know blogs are supposed to come to a pithy conclusion, but I'm sorry - no Jerry Springer message on this one.