So 'off-shoring' work to the United States (I'm in Australia, by the way) sounds a little counter-intuitive, but after trialling and studying the behaviour of other off-shoring solutions and comparing to our own requirements, we found it was actually a good fit. But first, some disclaimers:

• This is not an advertisement and I have deliberately omitted the names of the remote people involved. If you think your situation matches mine and you'd like some details, feel free to contact me and I'll pass them on, but I found them first.
• This is not intended to be negative towards off-shoring work to other location or criticise any of part of this practice. It is, however, critical of one-size-fits-all off-shoring and the decision process often used to move work to another country. In this way I believe it is pro-off-shoring as it advocates doing it right. Yes, this off-shoring was to India. No, I'm not against off-shoring work to India when it is done for the right reasons.
• If you have an alternate solution that works for you, I'm happy for you!

Now I can go into the details that makes this possible and worthwhile for us...

Stability

To be honest well had a hell of a time attracting and retaining quality people in India. When you're offering comparable rates and attractive work opportunities, you expect some sort of success but our catches were almost universally disappointing. We had people that didn't bother turning up to interviews, so it's hard to evaluate them realistically, others that job-hopped into another role almost immediately, others that had unrealistic aims, and finally several that were not found to be as skilled as advertised. Hiring over long distance is bound to be difficult, but we found significant problems with 100% of the applicants. We also hoped this would be eased by partnering with a remote recruiter, but unfortunately this didn't help either.

Preferably we would not have been managing these people individually. What would have been nice was to treat the external unit as a black box which accepted tasks and returned solutions. Being unable to create skilled teams or find competent team leaders made this impossible.

Ability

In many of the cases that lead to our decision to approach the USA, the level of ability became a larger than we anticipated. These arguments are covered in more detail below, but we required the ability to pick up tasks quickly and hit the ground running. We also needed this coupled with cost-effective development, and it was important to distinguish between cost and cost-effective.

Cost

Contentious issue. Try as you might, the same managers that agree to pay more for the best contractors can't grasp that cheaper doesn't always mean better. My initial investigations on the 'real cost of employment' of an Indian developer against a local Australian one showed that while off shoring to India is still cheaper, it is easy to find ways in which these numbers become meaningless.

One of the easiest, as we are in the process of tracking, is using Agile sprints to get an average of development velocity. So we are still in the process and don't have the numbers, but I believe measure of cost per story point is more useful to a project than cost per hour. With respect to previous off shore attempt, the average cost per story point was infinite as nothing tangible was produced. It's a hard result, but the numbers were easy to calculate.

Additionally, all locally managed off-shoring incurs a management overhead, remote development leads to code versioning issues... There are a list of issues that cause direct costs to be misleading.

Trust

Another point that was decided before it went out for tender, I already had an existing relationship with the devs in the USA. You can't buy these contacts, you can't fake them, and you can't just make them up. Trust has been important in many of my recent projects since small companies are very protective of their place in the market and are wary of losing code, IP, ideas, whatever.

Flexibility

It is well known that you cannot just add people to a project to make it get built faster. In the same vein you cannot expect to add people to a failing project and expect to bring it back into the black. Within reason.

What we have been experimenting with is the ability to take 'offline' tasks and get them completed by remote developers. Again it was a nature of our environment that while large feature enhancements had used all of our development team, clients still expected to see results on bug fixes and smaller items. These were the perfect pieces to ship off to someone else without impacting the main development effort. The ability to pick up work and run with it unattended was a strong requirement here, but I'd be prepared to pay for this, wouldn't you?

Fire Fighting

I could call this 'Flexibility' as well, but I like the term 'Fire Fighting'. When you have a pool of talented resources, you can point them at any problem and make the problem go away. The difference between this and regular flexibility is that skill needs to be high, which you don't get from cheap resources, and you also need to be able to rely on things like best practices, patterns, avoiding gotchas and the rest of the things that make the difference between graduate and experienced developers.

Since the pieces of work we shipped out of the office included anything we didn't have time to do in-house, we also had to send out some high priority work, and we didn't just want it done, we wanted it done well.

Summary

I guess it is necessary to summarise, even though this extended thought is already laid out above. Again I would like to say: If you found other development solutions a good fit for your needs, then I can be happy for you. We found that an extended commitment to 'common off-shoring solutions' was completely unproductive and did not match our requirements.

• When you count development velocity, management overheads and time spent in communication a 'dollar per hour' figure is less important than what is produced for that dollar.
• Given the right match of needs versus abilities, it is possible to investigate and find that non-standard solutions become feasible
• Packaging work and posting it off-shore relies on more intangibles than a low cost.

Finally and most importantly, it helped that I already had the 'best fit' situation in front of me just waiting for me to realise that, although completely bizarre, off-shoring work to a more expensive market can work. Maybe not for everyone, but not everyone gets the same results from India either.

Epilogue

People will want to know about the realities of the work done in the USA - that is, did it work, was it a success, was it worth while?

To be honest the answer is yes and no, the higher cost means you are less likely to write off unproductive time or anything past the original estimate but I'm realistic enough to know that this is the nature of business. Given the nature of our needs and the skills available it makes sense to adopt Agile practices, concentrate on communication, and manage issues as best as possible.

We're continuing to send work to the USA, the bosses keep agreeing to send work to the USA, we get work back and the remote developers get paid. In this sense the experiment can be considered an ongoing success.