In this article I summarize my experiences with working with an outsourced IT development team for just over a year.
Introduction
If you've been working in IT for any length of time, you undoubtedly know about the rise in outsourcing IT work over the past few years. Typically, IT outsourcing is synonymous with hiring a consulting firm in India, but many US firms also offer IT outsourcing services. Outsourcing is one of those business ideas that looks great on paper, but has hidden costs that often outweigh the benefits.
My experience with IT outsourcing began in early 2004. The company I worked for at the time, Transcender, had recently been purchased, and part of my job after the buyout involved managing some of the projects that the team in India worked on.
First Impressions
It took some adjustment to get used to the idea of working with outsourced developers. Some of my friends had just been laid off, perhaps at least partially due to the fact that the company had a team of developers working in India.
Incidentally, putting names and faces to the outsourced developers forces you to change your perceptions. You realize that these aren't evil people trying to put you and your friends out of jobs. They are generally just hard working people trying to earn a living and better their lives, just like we are. It's a shame that all too often it ends up being an us vs. them scenario, because I suspect there's a lot we could learn from each other given the proper environment.
Continuous Improvement?
Not long after starting working with us, the team in India was given the tasks of creating study guides and a few practice tests. Writing clearly and concisely for a largely English-speaking audience is difficult even for many Americans, but I can only imagine that it's doubly difficult for someone who speaks English as a second language. Additionally, most of the outsourced developers were inexperienced in writing practice exams and study guides. As a result, the creation of these practice tests and study guides took much longer than if they had been written by experienced internal staff. So, time to market was much longer, and I'd be surprised if the actual costs of those products were much lower during this time. But, the management of the company was committed to the relationship and was willing to spend this time to teach them their methods of development in order to save costs in the long run. This had the not surprising effect of causing at least some of the internal developers to fear that we were essentially training our replacements. It became painfully obvious that we were looked at essentially as an entry in the financial report, and any attempt to reduce that cost would be considered. This was not a recipe for success.
At any rate, the outsourced developers were given more responsibilities in writing practice tests. Eventually, we were told that all content development would be done in India and our jobs would be to review that material. The only problem with that plan is that we were seeing a lot of turnover in the Indian firm, and many of the same mistakes were repeated due to a lack of experience, which was frustrating and led to further morale problems. By the time I left Transcender in May of 2005, I think that only 2 or 3 of the original team in India were left. Based on talking with other people who dealt with similar arrangements in other companies, this seems to be normal for this type of work in India. Additionally, Transcender experienced internal attrition as well due to poor morale and other reasons, with about half of the original developers leaving the company during this time.
I felt that the message that we were getting as internal developers was clear. The quality didn't matter; outsourcing was cheaper and that was the most important thing when it came down to it. Of course, this isn't what we were actually being told. We were being told that it was our job to ensure that the quality remained consistent with out customers' expectations, but were given constraints that ultimately proved unreasonable, in hindsight.
Lessons Learned
I believe that there are several lessons to be learned from my experiences working with an IT team from India. The most important lesson in my opinion is to ensure that you are aware of the hidden costs. There will be communication difficulties that you will have to overcome. There will be culture issues that you will have to address. There will be a learning period, which may become much longer than you anticipate. All of these things take time, which doesn't directly relate to the bottom line, but will quickly affect those things that do. Anticipate a high turnover rate. Anticipate a much larger amount of overhead and oversight than you think. If you plan appropriately and factor in the hidden costs, then it's possible that outsourcing can help you manage costs. However, if you're considering outsourcing development on a product that is critical to the success of your organization, then I don't think that the cost savings are worth it. You're likely to lose control of the development process, which will affect the quality of the product and could affect internal morale, both of which will ultimately hurt sales.
Conclusion
My conclusion is that you should never outsource the development of your core product. Furthermore, I don't think that IT outsourcing, in general, is the answer for saving money. Outsourced developers, regardless of location, do not have any attachment to you or your product other than the check that they receive each month, so it's unlikely that they'll put the same amount of thought and effort into creating the product as internal developers. You will spend more time than you can imagine simply communicating back and forth. While I think outsourcing may work in some situations, such as when the outsourced firm has expertise that you do not have, be aware of the hidden costs of managing the relationship, which can often be much higher than you think they will be.