For the past few weeks, I have been working on a project that engages a team consisting of both onshore resources and offshore resources. The scope for the offshore team is to execute test cases that are created by the onshore team and report the results to the onshore team. Initially, I thought it would be a very simple project that can be delivered smoothly. However, it turned out that both the onshore team and the offshore team were tortured by this project. In a word, the project was not ready for multi-shoring.
I’d like to share some basic points that may help get the project ready for multi-shoring:
- Think globally – As the team is distributed globally, I am always careful when scheduling a meeting. One time, an on-shore resource scheduled a meeting on a Friday evening, which is Saturday morning for the China team. Another example is when we reboot a server or deploy a new build. It’s common to do these kinds of things after office hours in the US, however, it might be a blocking issue for the offshore team.
- Manage RID (risk, issue and dependency) properly – As the offshore team lives in a different time zone which is much earlier than the onshore team, it is critical to ensure there won’t be any RID that leads to a productivity loss during the day for the offshore team. A specific example I experienced was that the US test lead assigned a test package to the China GDC (Global Delivery Center) team for execution but didn’t check to see if the test package had the testability. It turned out all the test cases in the package were blocked as some components were not ready for testing. As a result, the GDC team lost a whole day and had nothing to work on.
- Communication style – Admittedly, a lot of people prefer communicating in person instead of composing emails. However, it is often difficult for a multi-shoring team to find the proper time to do the conference call. As a result, e-mail communication is more efficient most of the time.
Good points Diego. In addition to those, I will also be aware of cultural distance (besides physical and language barriers.
Also keeping the parallel leadership will help too, for assignment and monitoring the things.