Here is a list of he lessons that I learned:
1) Know the software. In many cases, offshore teams are hired to build custom solutions. This means that they get to design using their standards. With existing software, many times you are limited or should follow the packaged solution's standards. What can be done and what should be done (while still be economical) was a issue for the team. To mitigate this risk, we spent about two weeks just learning the basics of the software, where to find resources, looking at code before we started the design.
2) Centralize the repository. This is a techical issue that we had where the code repository was hosted in India. This was great for the team their but made it really hard for other global team member to get anything done. When it takes 20 minutes to commit a change to a 5KB file....you know that there is a problem.
3)Daily Meetings. Although we where running a waterfall model project, I still wanted to introduce the idea a stand-up meetings. With the time difference, it was at the end of the day but it accomplished the same goals. Discuses the issues of the day and plan for tomorrow. When managing a remote team, you have to get them a chance to bring forth an issue in a timely manner.
4) Clients are King. Not a lesson isolated to offshore teams but one that needs to be addressed harder when remote. The client doesn't know what is happening and doesn't feel like progress is always happening....out of sight...might was well not be happening. Regular status meetings are good...but too formulaic or procedural. Many times, a simple status of a task in progress is enough to make them feel like they are a part of the process and
