Thinking About Offshoring
We enable YOU to run YOUR business smarter
By Piyush Rakhecha

Thinking About Offshoring– Questions to think about

The history of offshoring is filled with horror stories of how difficult it was and failures. It is easy to offshore but difficult to make it work. It doesn’t have to be so. What is required to go into offshoring with eyes open and to be prepared. It also involved asking the hard questions. Here we tell you what questions to ask yourself and the offshore service provider.

Questions to ask

  1. What is the type and size of service?
    • While most services can be delivered from offshore, the percentage that can be offshored varies by the type of service and the delivery phase – for example most of the solution design work has to be done on-site working with various teams while most of detailed design can be offshored, even though an on-site touch-point is required.

  2. What is the existing delivery model?
    • a. This is critical. If the end-customer is used to the developer sitting across the table all the time, it is difficult if suddenly the developer is a few thousand miles away and in a different time zone. Also when work is done across multiple sites, configuration management moves to another plane. Having multiple locations is another thing that needs to be thought through and factored in. There are a few other considerations that have not been mentioned here
  3. What is the delivery model – Waterfall, agile, etc.?
    • This is one of the more important discussion items. Everybody should be clear about the model, how it will work across the multiple locations, what are the enablers, what to look out for, how verification – quality control and testing would work. Also the offshore percentage varies by the model used, the phase within the model and the tools. Expectations have to be clear upfront.
  4. What is the end-client’s confidence level in delivery?
    • If the end-client has confidence in the current delivery team, it becomes easier to convince them about the change where some or most of the work moves to offshore. It is also important that they see and hear people they have confidence in during the initial period. This hand-holding makes the move easier and reduces the friction that would other-wise develop.
  5. Are there any specific security requirements that would need to be fulfilled?
    • You wouldn’t think so but it happens a lot, specially the first time around (although I have seen it happen even after a couple of years when a new business unit, with different requirements, offshores). Focus is put on team composition, tools and even on methodology (although not as much as I would like to see). Security is something that is not on the top of people’s mind. Only at the last minute this raises its head and suddenly it becomes a crisis.
  6. Will connectivity be required and if yes, how will it work?
    • a. This is another thing that I have seen being missed out even by experienced people. The work is discussed and agreed by delivery teams on both sides and managers forget to pull in the infrastructure teams into the discussion. Unless it is a standalone new development, connectivity is important for various reasons – single repository, 20-24 hour working, effective project management, quality control among others.
    • A long time ago, I was based in Memphis, USA managing an offshore managing an offshore team based out of Chennai, India. The connectivity was there and we though everything was sorted. We missed out on the fact that we had one mainframe and the end-of-day operations took most of the CPU cycles. So, even though the connectivity was there, the offshore team had a hard time working. A developer sitting in India could press “enter” and go have a glass of water at the water cooler and come back and might still have to wait to see the next screen. The work that could be done in 1 day took 2or 3 days – the very reason of offshoring was lost. Once we sorted it out – productivity shot up and customer satisfaction levels also shot up. The point is, if these sort of things are thought through and sorted out in the beginning life for everyone is a lot easier.
    • If the toolset is required in India, how easily will it be available?
    • Do I need to say anything on this? Everybody who offshores comes against this. This can manifest in a few ways. Addition cost of licenses built into the price even though there are existing licenses that the vendor can use or wrong versions between the two sites or security restrictions or using incompatible tools across the two locations. These are some examples
  7. How will the communication and Governance work
    • Communication is the lynch-pin of success in the case of offshoring. Clear defined formal communication methodology and channels are imperative. The communication has to be clear, concise and bereft of any cultural insinuations.
    • Part of this is also having some over-lap between the two teams to allow for telephone and virtual face-to-face communications. Also everyone involved should understand the time difference, especially if the company is in the US and the offshore location is India or Philippines. Setting up a meeting at 2PM Pacific Time doesn’t help anybody.
    • Governance is easy when everybody is on-site and a lot of the time informal. When work moves offshore, this needs to become very formal and defined. The purpose of Governance has to be clear and everyone needs to line up behind it. This cannot be a witch-hunt. The purpose has to be to ensure success for everyone or as some say – create a win-win for all.
  8. Is there any knowledge transfer required?
    • This is something to think about when offshoring for the first time. Typically in the US and in Europe an application is managed by one or more persons who have been managing it for many years and huge amount of knowledge is built into the team. When work moves offshore, this needs to be undertaken as a separate activity with defined inputs and expected output and outcome. The purpose has to be to institutionalize the knowledge.
  9. Is the BCP/ DR plan in place to ensure seamless and efficient delivery?
    • A lot of things can go wrong – connectivity can be lost (example - undersea cables being cut), people falling sick, site becoming un-reachable are some of the reasons. BCP/DR planning is always important but it becomes even more important when work moves to offshore. Having a tested plan helps in mitigating the risks.
  10. What are the spoken / written language requirements?
    • a. While this is important for countries that do not speak English, it is also important for English speaking countries. People joke about it but the same thing can be said in multiple ways depending on the version of English used. US English is different than the UK which is different than Singapore – you get the gist. This links to the communications point earlier.
    • In case of non-English speaking countries these requirements have to be clear right in the beginning and appropriate language skills need to be built into the teams. Typically this is done through employing dual-language developers at on-site and translator at offshore.

There are other things that can be added to the above. I would like to hear from others on this. I can be reached at