First, it is not easy. If you think this will solve issues within your current development lifecycle - don't bet on it. If you're going to seriously begin to use off-shore resources, you better plan appropriately, or you'll pay the price with development timelines that get extended and budgets that creep beyond your expectations. In the worst case scenario, you'll end up rolling product into production that has not been properly tested and vetted.
Some of the breakdowns that my teams encountered in using off-shore resources are as follows:
- Communication - eliminating the natural lag in communications as teams work shifts that do not align.
- Design Aberrations - ensuring the product developed fully conforms to the original design/requirements.
- Coding Standards - putting processes in place to ensure that the off-shore development team followed the development coding standards of our internal teams.
- Quality of Code - ensuring that the code had been properly tested all the way through integration testing with other application silos/subsystems.
- Quality of the Team - ensuring the consistency of development resources applied to projects.
- Product Knowledge - ensuring that knowledge of team was retained from project to project.
Communication: Each and every day, without your knowledge dozens and dozens of project decisions are made as developers lean across the walls and talk to each other or see each other walking around the office. My teams have been no different, requirements and designs could change based on a hurdle that needed to be solved and a quick conversation in the hall. Suddenly you have a team separated by multiple time zones - in my case, they had left the office for the day by the time we arrived in the office. If the remote team had a question, or hit a roadblock and needed direction, there was an automatic lag of at least 1 work day. If it was a serious issue, the team might loose several days as communication threads worked their way through email. In extreme instances, we might have some of the remote team stay late or some of the local team come in early to establish conference calls and work out the issues.
Design Aberrations: The standard methodology we used to develop project requirements within the organization wasn't sufficient to support the use of outside resources. Didn't matter if those resources were on-shore or off-shore, our teams were comfortable dealing with each other and could abbreviate how the requirements were documented. There were a lot of things assumed within the requirements that didn't need further explanation because the teams had years of experience working together. This continued to feed through the process as design documents were generated by the team. Suddenly we introduced a team of developers that did not have that tribal knowledge. The results were obvious in hindsight, the off-shore resources built the product to match the documented requirements and designs. The only problem - those requirements and design documents didn't contain the unspoken elements known by the internal teams.
Coding Standards: Some of the products that we chose to develop off-shore ended up needing to be supported by local teams. We quickly found out that the coding standards we had in place were not documented thoroughly and left many items up for consideration. Translation, the remote team was producing code that looked like none of the other code that was used internally.
Quality of Code: The internal teams had many years of experience working together, touching each others code and making the necessary revisions to the code base. Suddenly we had bugs that had been solved being reintroduced into the code base later in the development cycle. Worse yet, we would find chunks of code that were never being executed, yet were loading up the code base.
Quality of the Team: Just as we were getting used to working with one set of developers, suddenly they would be reassigned to a different project and we would end up having to reacquaint ourselves with a new team. To say that this slowed down development and introduced inconsistencies into the code base would be an understatement.
Product Knowledge: As we completed development with one project and started up the next project, we were not assured that the team we had gotten used to would continue on and do development on the next project.
None of this is serious and can be resolved, but you need to think through the engagement up front and take the necessary measures to protect your organization. Here are some of the tactics we began to utilize to minimize the risk in the use of off-shore development resources:
Communication: We required the off-shore company to place one of their resources on-site with our local teams. They became the primary communication point between our teams and the off-shore resources. They sat in on the meetings locally and could catch the small things that needed to be communicated to the off-shore team. They could do the impromptu meetings in the hallway and get that information promptly to the remote teams. Our project timelines included buffers to accommodate the communication lag between the teams.
Design Aberrations: We ended up beefing up our Business Analyst and Architecture teams to create more thorough documentation. Our documentation became much more thorough and attempted to accommodate the things that people took for granted. The architectural diagrams became much more sophisticated outlining all servers touched, all databases touched and were color coded to identify new, changed or removed elements. Design documentation began to reference not only the objects that would be touched, but could go down to the individual methods and parameters when needed.
Coding Standards: We ended up going through our coding standards and documenting much more thoroughly how code was to be structured, how variables names were to be created, what security precautions were to be taken when creating the code, etc.
Quality of the Code: Code created by off-shore resources was required to go through the same code review process that we used for internal teams. This ensured that our senior developers were reviewing the code - exactly as would be done for internally written code and that they could catch issues and feed them back to the remote team.
Quality of the Team: After some experience with team members shifting, we ended up negotiating with the off-shore company to ensure that we had a core set of developers that would not be reassigned off of the project. This allowed us to maintain some level of consistency within the off-shore team and addressed quality of code, coding standards and communication issues.
Product Knowledge: Similar to the Quality of the Team issue - by keeping a core team of developers assigned to our projects, the off-shore teams knowledge base of our products began to increase and they could begin to anticipate some of the issues ahead of time.
I want to state again, these were experiences that my team had in working with off-shore resources. Other organizations may have different experiences. Hopefully, some of these issues and the ways in which we resolved them will assist you with determining whether you can support the use of off-shore development resources.
I typically do not use off-shore resources unless there is a need to temporarily augment our internal resources to accomplish specific development/project goals. That's a choice that I feel comfortable with based on the particular business needs within the organization. In previous roles, I've had the opportunity to work extensively with off-shore resources. If you're going to use off-shore resources, I highly recommend you pick a couple of small projects and trial a couple of different vendors to establish which one will work better with your current development paradigm. Don't be afraid to switch vendors if you don't feel you're being taken care of - ultimately, it's you that will be held accountable for the delivered product.
If you'd like more information on my background: LinkedIn Profile
