How expensive is offshore? Some things are better done than described....

Do companies out there go offshore for cost reasons or because they want to improve their time-to-market? Are they aware of if reducing costs it will take longer in time and when optimizing for time that it will be more expensive?
I just pasted interesting questions from Michaels comment to my last entry about offshore activities.
It is not possible to practice offshoring without have an answer to these questions. Before the project actually starts these questions should be answered in "vision" or "mission" document. It seems like, some big companies (almost institutions :-)) do not have a dedicated strategy. They only want to offshore some amount or percentage of projects. The obvious reason is saving money (but the real reason is often the reaction of the stock market to offshore intention).
But this reason is too general. From my point of view development is LESS expensive, than maintenance. So it is not very smart to save money in the development, and ignore the maintenance. The general requirement "Saving money" has to be refined in the vision or mission document (but no more than one page :-)). I suppose, companies would like to save money in general, and not only in the development phase. In this case the maintenance and not development becomes important. But this changes the requirements for the development phase and especially the non-functional requirements. To save money with offshore in the maintenance phase the following points have to be considered:

1. The architecture of the system has to be defined by internal/corporate developers/architects.
   
2. Naming conventions, patterns, approches, documentation style has to be defined and are essential.
   
3. The offshore environment (IDEs, servers, software, os, load tests) should be identical to the corporate environment.
4. The continuous integration server should run onsite, not in the offshore companies. Especiallly the fraction during deployment can be so minimized.
   
5. Internal developers should review the code AND have the power to refuse the results of some iterations because of violation of the defined rules and specification. The amount of automation depends on the fomalisation of the archtecture.Tools like: pmd,checkstyle,findbugs, jdepend can help to track the quality but cannot replace human reviews.
   
6. Errorhandling and logging strategies should have "bullet-proof" quality.
7. Monitoring, management and deployment strategies should be defined and reviewed.
8. A blueprint should define the amount of allowed frameworks.