Then there is the question of quality. In my experience, with only a few exceptions, the quality of code developed offshore has been good.
Matt's experiences have been different to mine (however, he has had more experience in this area than I) - for me, on the whole, the code developed offshore has been very poor. However, the code did work and therefore it got released; which is different from being good - but from a managers perspective this could been seen as good and that could also lead a manager to believe that the quality was also good because it was released. This is not the definition of good code, more on why this poor code gets released follows later.
Matt goes on to say:
However, this requires vigilance and extra time from your key, local staff to review, comment and guide the offshore team.
It is advised to have your coding standards ready and validated and make sure code is reviewed regularly to check for compliance and clarity.
Entirely agree and here's some additional advice in this area specifically: Do use automated test suites, do use static code analysis, do have standards AND enforce them; do not assume that the code will be OK or "good enough" and do not accept the code if you are not happy. If it is not the code you would have written yourself then it's not the code for you. How will you ever maintain or grow the code if you do not love it as your own? Code is read many more times that it is written so it is vitally important that the code does more for you than "just work".
There is a common issue I have seen in business time and time again with projects that use outsourcing: the project plan does not allow for the code to be reworked.
This is like having only one test cycle in the plan: there will be no time to put anything right. Without this being factored into the plan all you will get is an issues list but you'll have zero time to do anything about it. The fact that you'll have a "statement of work" and contracts that state what you and they must do will make little or no difference in the end - because if time has run out and the code works you'll be under pressure to release it, regardless of the quality.
If you're seriously considering outsourcing here's something that I have found extremely useful, Steve McConnell's insightful article on the topic: Managing Outsourced Projects.