Recently, I have been having various conversations with people about Offshore Development Centres (ODCs). Offshoring was quite popular some years ago, and it has become a standard practice by many development shops these days to be able to leverage a (diminishing) development budget.
I have worked with various development teams, many of which have been offshored, and last year, whilst CTO of Aegeon Corp, I was responsible for moving much of the development of Aegeon’s products to an ODC. In the selection process, I screened dozens of companies and ultimately travelled to China to make a final selection.
In recent discussions with people, I realised that many people (developers and managers) are quite uninformed about the issues of outsourcing. They tend to get quite hung up on items that have become redundant, or at the very least, are issues that are quite common that many ODCs have more than adequate mitigation in place, and overlook some of the more important issues.
In this blog posting, I intend to uncover some of the myths that are being spread around when managers plan to set up an ODC.
1. You must stick with the Major Tier 1 Cities
When sourcing offshore providers, we tend to go to the major technology hubs in popular offshoring countries such as India and China. And although there is a certain advantage working with companies in these countries (since they have now reached a certain level of maturity and experience in the industry), you do not necessarily need to put your teams together in cities such as Beijing, Mumbai, Shanghai or Pune. In fact, doing so means that you are likely to be paying a premium rate for little business benefit.
When travelling to these countries, you soon realise that many of the resources that are working in the capital cities are actually sourced from many of the Tier 2 cities. Since cost of living in the tier one cities is higher, rates for resources are higher. For example, in China, you will pay 10-25% more for resources in Beijing and Shanghai, than you would for the same calibre of talent in Dalian, Chengdu or even Guangzhou.
Remember the talent pool to choose from in these countries is greater than the entire population of some countries.
2. Beware – any IP developed offshore is going to be pirated!
This is always an issue regardless if you offshore, but there is a certain amount of uncertainty knowing that it may be difficult to prosecute any pirates in foreign countries. But in reality, there is a lot going on both abroad and locally to combat this.
For example, any technology parks, and any half decent companies are very stringent and provide a high level of control an police this quite effectively. For example, when in China, I discovered that technology parks in Beijing and Dalian had their own prosecutors and courts to administer fines and even jail terms for any individuals that are accused and convicted of piracy (particularly in ODCs).
Additionally, you have to consider what the real risk is. In some instance, if you are developing an autonomous desktop application, you may want to be careful how to approach this. But if you are developing a web application, remember that the technology is only a small portion of the product. The strategy, go-to-market and marketing in general is what is going to make the product a success. Do you really think the pirates are going to have the wherewithal to successfully pirate and market such a product?
If there are certain aspects of your application that are unique that is sensitive to the success of the product if it were to be pirated (such as algorithms or particular workflows), you may want to consider ensuring the development of those aspects locally.
Finally, you have to accept your ODC partner exactly as that, a ‘partner’. So there needs to be a certain level of trust. You have to accept that ODCs are not in the business of pirating your software but developing software for clients like yourself. You will be one of many, and the best reference for this are the testimonials you will receive from their other customers.
The quality of the code is going to be poor
This is one of the most prominent myths I come across, and sure it may have been true several years ago, the reality is that most of the resources working on the projects are going to be quite senior. When you talk to the companies running the ODCs, you realise that they have extremely stringent resource acceptance criteria, such as high IQ, top percentile of university graduates and high expectations of English language.
In most cases, the quality of code I have seen is as good and sometimes better than a lot of the code developed locally.
But don’t let this myth get mixed up with the reality that sometimes, your ODC does not clearly understand your requirements. So you have your requirement, you believe that you have documented and described the requirement to the n’th degree, and then when you finally get the code, it is not what you expected. This is a communication issue (which could happen to your local team if left unsupervised as well), and does not mean that the quality is rotten.
It is not possible to run projects using Agile methodologies with an offshore team
Because of the fact that your team is remote does not mean that the team cannot be run using Agile methodologies. In fact, I believe ODCs lend themselves quite nicely to Agile development, particularly if you select an ODC that is in a relatively good timezone as you.
You can have daily stand-ups, write your requirements as stories, manage them into sprints and allow your remote team to use disciplines such as TDD and pair programming. You just must accept that the team is remote, and the biggest challenge is communication and interaction with that team, particularly when clarifying requirements. So make sure you pay close attention to the communication aspect (hence why timezone helps). But see point 7 below for more detail.
Stick to the large ODC providers
Sure there is more security and better processes with the larger ODC providers, but there are 2 downsides that you will have to take on board (in my opinion outweighing the benefits). Firstly, you are likely to pay 25-50% more for resources from larger ODCs as they have greater overheads, and secondly, if you are a start-up or smaller organisation, you are not going to get the top class developers or attention from these companies. They will be reserved for their blue chip clients. Remember, companies such as Microsoft, Cisco, SAP amongst others are outsourcing as well and pumping millions of dollars into these companies, and those customer will get the top notch service, no matter what you think.
As long as you shop wisely, and do your homework on your ODCs you will find some great smaller ODCs where you will be one of their premier clients and will receive the attention you deserve. The quality of resources are still going to be fantastic, and you will be able to screen who works on your project anyway.
I cannot recommend enough the benefits of physically visiting your team and ODC. The cost to travel there a couple of days will probably be the equivalent of a few days of development time from that team, should be budgeted in the project and is money well spent.
Language and Culture are a huge barrier
Sure, this is a barrier, but I do not think that these days it is a huge barrier. Most resources that you will be working with in your ODC (particularly the senior ones) will have exceptional English. Many ODCs encourage all their resources to speak English constantly in the workplace so they can get the practise.
This will be a diminishing issue as the project carries on, you will soon discover what the constraints and difficulties are, and how to best communicate with the team. For example, in a project I ran with one ODC, I initially conducted stand-ups over IM chat (as written English was more comfortable for the team), but after that became impractical, we moved to telephone calls with the team leader who would convey updates on behalf of his team. As the rest of the team became more confident with their English, they would start to participate and you would all soon be working as one autonomous team.
A big no-no is to alienate the team and treat them as outsiders. The sooner you accept them as part of your team, and ultimately your company, the sooner you will get better results from them. Remote teams, like local teams, will take great pride in their company, and if they feel to be part of your company, that can only benefit you
Give your ODC team instructions and let them write code
This is not as much a myth as it is an expectation that most people adopt that infuriate me when they finally admin that the ODC failed! I constantly find local teams (product managers and subject matter experts) passing on their instructions and then walk away from the development hoping to get a great result at the end. Managing the ODC team is a full time job, just as it would be managing a local team.
I have found that the best mix for a local team to manage a remote team is a product manager and one technical lead. Both these resources need to be available 100% of the time to the remote team, but as the project progresses, the demand on them will be less.
The product manager will be responsible for clarifying requirements and final user testing, whilst the technical lead will partially act like the architect and review the results of what is delivered. I believe that the cost overhead is certainly bearable considering your remote team would cost 60%-75% less than a local team.
So there you go, that is what I have discovered in the last few years working with ODCs, do you have any opinions and your own experiences? I would love to hear about them.
