Considering Offshoring? Consider These Lessons Learned
Considering Offshoring? Consider These Lessons Learned
A Zone Leader reflects on lessons learned from when clients decided to send work offshore and gives some things to consider before engaging in such a relationship.
Join the DZone community and get the full member experience.Join For Free
The mid-1990s was an important time period for Information Technology. It was during that time that the Internet really began to gain momentum, Java 1.0 was released by Sun Microsystems, and General Electric opened their first data center in India — offshoring their IT for the first time.
Fast-forward to today, over twenty years later, the concept of using offshore or nearshore personnel to assist with Information Technology goals and objectives is no longer considering forward thinking. Since the late 1990s, I worked alongside both nearshore and offshore co-workers on projects. While I have encountered some positive experiences, I thought I would provide a collection of lessons learned from these engagements.
Who Is Really Doing the Work?
As a corporate employee, I have been a part of the initial meetings with partners who offer services and workers at lower rates. This is accomplished by leveraging offshore or nearshore staff that are paid at a lower rate than their domestic counterparts. From a project cost perspective, this can be very attractive.
When the time arrives to have technical talks with the offshore people, the end result can be very comforting. On the other end of the call or web conference are educated and experienced individuals who have an understanding of the technology at the center of their work. Questions posed to these individuals are met with solid answers, with thought-provoking questions often posed back to the corporation seeking their services. It is a good feeling.
The challenge is to make sure these are the same individuals who will actually be doing the work when the engagement begins. On more than one occasion those top-notch people are replaced with individuals with a far lower level of understanding of the technology in use. This becomes evident when the first round of solution delivery is received.
Tip: have a solid understanding on who is doing the work and plan to be a part of the pull-request process.
You Are Trying to Save Money, So Are They
As noted above, the most attractive aspect of offshore work is to save money. I very much realized this is a shared goal when we attempted to nearshore development at one point in my career.
As a group, we were pleased with the early stages of working with a nearshore provider. Prior attempts to offshore were met with challenges in dealing with the time zone differences between our eastern time zone and the offshore location. This nearshore provider was in a time zone that was just an hour different than hours.
As a final step before signing the contract, we had a check-in call with Gartner. The Gartner analyst listened to our situation and needs. Candidly, he asked us to validate that our data would only be accessed by the one location and that no other provider would be doing work on their behalf.
The analyst's request for information ultimately caused the contract to be dropped. When making the inquiry, we were ultimately informed that our development was actually being outsourced to another nearshore option, in another South American country. To make things even more interesting, that provider had already sold the work to another nearshore option in another part of South America. As a result, our intellectual property would be spread across three different groups... and countries.
Just as we were trying to save money, so were two of the three service providers that we were unknowingly going to work with as a part of this contract.
Tip: have an understanding on where the work will be completed and who will really be accessing your data.
Focus Is Not Always Where It Should Be
When in a crunch, the use of offshore or nearshore workers can help teams meet their goals. They can provide additional developers to provide ample horsepower to help reach an aggressive goal.
As a consultant, I was brought into a project where this approach was employed. There was no way a deadline could be missed, so offshore developers were hired. They were given a set of requirements and acted upon them to help the client reach their goal.
The problem was that the resulting code base was less than ideal. Use of deprecated methods, lack of standards from one developer to another, misspellings in the code, or just sloppy coding was more the norm than the exception. This led to a challenge when trying to support and further enhance the application.
While the goal was met, future work was crippled by technical debt items that had to be addressed and validated.
Tip: make sure to have solid standards/tooling in place and (again) plan to be a part of the pull-request approach lifecycle.
Make Sure Your Long-Term Interests Are Considered
Before starting my college education, I spent some time in the music industry. At one point I was in a band that had their own bus to travel from one gig to the next. Following an album release, we found ourselves touring the Midwest section of the United States. It was a great time... until our bus started having problems. This impacted the heating system, which turns out to be very important when traveling to Duluth, Minnesota during late November.
We ended up finding a mechanic who could get the electrical system functioning. Not enough to keep the heater going, but to keep the lights and other aspects related to safety working. Although we froze while in the bus, we made it back to our home town when the mini-tour ended. The problem, the temporary fix ended up costing us more money than if we would have fixed the situation the right way the first time.
The bus story comes to mind, because, often, long-term interests are not always top of mind when engaging an offshore or nearshore provider. Two ways in which this has been seen personally:
copying bad code from another system.
not viewing the design from a production support perspective.
When I reviewed the code and inquired about the origin, I was told it was simply copied from the old system to save time. However, in reviewing the prior code, there were aspects of the code that no longer applied and some that were actual incorrect business rules. This is what drove my involvement with this situation. At the same time, there were design decisions made which seemed to complicate the supportability for the solution that was delivered.
Tip: be active in the pull request process to make sure bad code is not introduced to save time.
Finally, the biggest aspect to outsourcing is also the one that is easy to miss — understanding the goals of your provider. This basically means to take a step back and look at the entire forest when considering an engagement.
Your corporation exists for a reason. Maybe you build the best widget. Maybe you service widgets better than anyone else. Maybe you provide third-party options for widgets. Maybe you are the best at hosting widgets. You get the gist.
Well, service providers exist to provide services for their clientele. At the core, they are doing it as a means to generate revenue. Regardless of the public or private state of the company, someone is at the top of that pyramid pushing everyone to focus on maximizing profitability.
When you understand the offshore provider is trying to do their best to maximize their profit from you, it can be easy to see how some of these challenges emerge.
Certainly, if an offshore developer can do the work for a fraction of the cost of another, expect the provider to use the cheapest dev to maximize the difference in billing rates. This may come with the compromise of copying the existing code because it will help them complete the project faster — which is helpful during fixed bid engagements. All the while, you can't expect long-term objectives to be lined up with yours — since those developers will be on another project once this engagement ends.
Tip: you just have to make sure you understand everyone is trying to do what's best for their own interests.
As I noted in the introduction, I have encountered positive experiences from offshore and nearshore efforts. These experiences have provided successful deliveries of projects that have impacted hundreds of thousands of end-users over my long-running career in Information Technology.
At the same time, I have been part of a team that has been a tactical team to resolve some of the results of the challenges I noted in this article. I have also been put into a position to head off some of these challenges as they emerge in the project — preventing a situation from going from bad to worse. My goal in writing this article is to communicate the challenges I have encountered in the hope that such issues can be mitigated.
In no way do I think that anyone has intentions to provide anything other than their best effort. It is just that experience and understanding can lead to a different level of quality, which does not always match the expectations of the client.
Have a really great day!
Opinions expressed by DZone contributors are their own.