The spec is the contract. They do the work. If they fail, you go out and hire someone who can do the work. No communications is required. If you have to talk to them while they work, then outsourcing by definition is not working, and they are not applying their brains to the effort.

It’s like your auto mechanic and his warranty. If he didn’t do the job right the first time, why do you think he will do the rework any differently.

And I especially like the question – we’re building up to an article on exactly that. So far, we’ve covered sending low-level implementation work offshore, and sending technical design work. Next up – complete technical outsourcing, and then product management.

I do think you’ve inspired another topic – low-level business analysis offshoring.

Thanks again, and stick around – we’ll get to it eventually.

Chunk your effort and follow a daily plan so you minimize your risk and catch any problems quickly.

I wrote a really good response, I promise. Had some issues with the site, had to upgrade (which is why it was down for a little bit), and apparently lost my comment.

I’ll sum-up:

1. Yes. Absolutely agree.
2. I will write an article (or 2, or 20) about this in specific.
3. The secret is to minimize the amount of “highly chatty” communication across the high-latency channels, to have any hope of efficiency.
4. It can be done.

Communication is the key, especially relating to time and space. I’d like to hear more about offshore + agile. This seems like a concept that is still propagating.

I agree with you that good process is critical, and domain knowledge can be an important factor to the success of any given project. I left both of those out of my analysis, because those factors have just as much influence when teams are co-located.