Thursday, September 09, 2010

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.

No comments: