One Programmer's Encounter with Outsourcing

My experience with IT outsourcing began in early 2004. The company I worked for at the time had recently been purchased by another company, and the new owners had already begun outsourcing some of their work to an independent Indian outsourcing firm based in New Delhi. Part of my job after the buyout involved managing some of the projects that the team in India worked on.

 

My employer's business is creating and selling practice exams that allow IT professionals — network administrators, database administrators, developers, internetworking people and others — to prepare for certification exams offered by Microsoft, Cisco, CompTIA and other technology companies. At one time it was considered the top player in its niche.

 

I had been working for the company for four years at the time of the sale, and during that period we had already been sold once before, just before our particular IT niche experienced a sharp downturn of business. Consequently, I wasn't surprised to see that the new company was looking to cut costs. We had already been focused on this for several years and had already experienced two rounds of layoffs as a result.

 

First Impressions

 

It took some adjustment to get used to the idea of working with service provider 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 service provider developers forces you to change your perceptions. An important part of coming to this realization was communicating with the other developers. You realize that these aren’t evil people trying to put you and your friends out of jobs. They're generally just hard-working people trying to earn a living and better their lives, just like we American developers were. 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 to work with us, the team in India was given the tasks of creating study guides and a few practice tests. The study guides are essentially small, focused books that range from 150 to 200 pages in length. Similar to writing a book, creating a study guide involves determining the layout of the material and creating an outline and structure for the training material, and then writing the actual content. Creating a practice test is a little different. Whereas with the study guides, it's important to attempt to describe a topic in as much detail as possible, writing questions and answers for a practice test requires more specific content, since each question is typically focused on a very narrow topic. A content developer for these types of products needs to be able to fully understand the material and then be able to communicate that material as clearly and concisely as possible.

 

Writing clearly and concisely for a largely English-speaking audience is difficult even for most Americans, but I can only imagine that it’s doubly difficult for someone who speaks a different form of English or speaks English as a second language. Additionally, most of the service provider developers were inexperienced in writing practice exams and study guides. As a result, the creation of these products took much longer than if they had been written by experienced internal staff. So, time to market was much longer, and I would guess that the expense of developing the guides and tests was comparable to what it was prior to outsourcing.

 

For example, as an experienced content developer, I could write a typical practice exam in approximately six to eight weeks, depending on the details of the exam being simulated. In some cases, the service provider developers took over six months to complete an exam — and that included significant rewriting by internal developers. This occurred several times. To be fair, the development time did improve, but this happened more as a directive than as an indication of increased productivity from the service provider developers. That is, the products eventually came to be released in approximately the same timeframe as if the products had been developed internally.

 

However, I considered the products of lower quality than if they had been developed by the internal development staff. For example, in many cases, the practice exam questions and study guides written by the service provider didn't actually cover the material on the exam or would contain many grammatical errors. Additionally, it became clear on several of the exams that the author at the service provider didn't fully understand the material, producing many technical errors within the products. (I found this ironic, since the company provides technical training in 30 countries, according to its Web site.) This ultimately increased support costs in the form of additional error reports and content fixes. Ultimately, I believe reduced quality will affect long-term sales, not to mention the reputation of the company.

 

But, the management at my company was committed to the relationship. They were willing to spend this time to teach the service provider developers their methods of development in order to save costs in the long term. This had the not-surprising effect of triggering fear among at least some of the internal developers 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 was worthy of consideration by management.

 

After about a year of working with us, the service provider 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 was that we were seeing a lot of turnover in the India-based firm. This resulted in many of the same mistakes being repeated due to a lack of experience, which was frustrating and led to further morale problems. By the time I left my employer in May 2005, only two or three of the original development people of about eight developers in India were still working with us. From my conversations with other people who have dealt with similar arrangements in other companies, this seems to be the norm for the kind of work that my firm was outsourcing. Additionally, my former company experienced internal attrition, primarily, I think, because of poor morale. We didn't see a future there. During the 18 months we worked with the overseas team, about half of the original 10 developers left the company.

 

The message we were getting as internal developers was clear. The quality didn’t matter; outsourcing was cheaper; and that was what was most important. Of course, this wasn'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 the reality was that the constraints we had to work under ultimately proved unreasonable. Essentially, the quality of the material being provided to us was not improving, but management wanted the products to be released more quickly.

 

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 be aware of the hidden costs. When dealing with a team of developers that isn't a direct part of your company or corporate culture, they typically won't have the same understanding of your goals, which can lead to products with lower quality or development that costs more. If your internal team is constantly redoing work created by the outsourced developers, then you're essentially increasing costs, not reducing them. Additionally, one of the most important hidden costs to consider is the morale cost of outsourcing the work. If you're outsourcing work that has historically been done by internal developers, those developers will understandably begin to fear for their jobs, which obviously lowers their morale. If the internal developers' jobs aren't in jeopardy, then it's important to ensure that this message is communicated to them.

 

Next, there will be communication challenges to overcome. This will consume much more time that you might realize. When dealing with a team located in a different country, communicating is even more difficult. Keeping multiple lines of communication available is important. In our case, we used the phone for weekly status meetings, and instant messaging and e-mail for any other communications. Given the time difference between the two locations (11.5 hours), there were only a few hours when both teams were working at the same time.

 

Third, there will be cultural issues you will have to address. For example, if the outsourcing firm is located in another country, then it's important to learn how the foreign country's culture differs from that of your own. In some countries, there's a clear system of communication that should be followed and deviating from that hierarchy can cause issues to develop within the foreign firm.

 

Last, there will be a learning period, which may become much longer than you anticipate and — as long as attrition remains a problem for the service provider — will continue on and on.

 

Resolving all of these issues takes time, which doesn’t directly relate to the bottom line, but will quickly affect those factors that do. Anticipate a high turnover rate. Anticipate a much larger amount of overhead and oversight than you expect. 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, ask yourself if 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 can ultimately hurt your company in the long term. It’s important to realize that, like any contracted work, the quality of the work varies widely. It may take you several tries before you find a service provider with a team of people that meshes well with your internal group.

 

If you're convinced that outsourcing development to an offshore service provider will save you money, then I would offer the following advice. In order to become comfortable with the relationship, start with an internal, non-customer-facing project that isn't critical to the success of your business. For example, start with an application that would help improve the efficiency of your business or your processes. In our case, it might have been more effective to outsource the development of our internal authoring engine, which ended up being developed by internal programmers. Doing so would have allowed us to save costs or get a new exam engine to market faster.

 

I also suggest starting small. That way, you'll be able to gauge how much time will be required to manage the relationship, as well as the quality of the work provided by the service provider team.