Posted by Cary Toor
Today, most company that are mid-size or larger are actively developing at least some of their software applications off-shore. This is also a viable option for small, tech-savvy companies. This may include hiring developers, analysts, and/or software testers or contracting the entire project out. Why? The cost, of course: $3,500 per month for a mid-level developer (in India) as compared to $13,000 for a mid-level developer in the US; a 4-for-1 cost advantage for off-shore. Yes, costs are increasing for off-shore resources, but a large cost advantage still exists.
I ran a software development and consulting firm for 30-plus years that was late to the game of using off-shore resource. This isn’t because we were xenophobic or fixated on using only American labor, but because we made a significant business out of fixing broken off-shored projects for over a decade-and-ahalf. The purpose of this discussion is (1) to tell the story of what we learned and how we eventually began using off-shore resources very effectively in both our own development projects and in fixing broken off-shore projects and (2) to provide some general tips that companies can employ to increase the probability of success in their projects with off-shore labor.
A Little History
Off-shore software development as an industry is really only about 25-years old. For a very brief history, the trend toward off-shore development seriously started in the mid-1990s during the Y2K and .com bubbles, not just to save money, but to acquire somewhat experienced developers and software testers who were virtually unavailable due to the unbelievable demand in the late 1990s. This trend continued on the other side of the .com bust as global telecommunications improved, off-shore resource quality improved, and the cost for US software development resources ratcheted higher. Off-shore labor suppliers have made it so easy to contract both for labor and complete development projects that virtually any organization of any size or level of expertise can do it. I am amazed by the fact that you can acquire off-shore resources faster than you can hire US resources, and for a fraction of the cost.
Early on, we saw 2 gaps between US and off-shore resources:
- Skills Gap. In the 1990s and early 2000s, off-shore resources in general had a much lower level of expertise than US resources with a similar level of experience. I don’t believe this has anything to do with superiority of US resources, but instead with off shore resources’ a lack of exposure to complex projects and coding tasks as well as lack of techniques and development patterns necessary to effectively write production software.
- Culture Gap. In the 1990s and early 2000s, off shore resources did not have an understanding of our business goals, or even business structure. For example, reports were an alien concept in many of the countries typically used for resources and businesses in the US operated very differently from the businesses in the countries supplying off-shore resources.
For that reason, in the late 1990s and early 2000s, productivity of off-shore developers was much lower than productivity of US resources with the same experience levels; starting out at maybe 3-to-1, which was easily justified by the cost advantage that was even wider than it is today. As off-shore developers
were exposed to more projects, more complex projects and better development techniques, and as their own economies became more sophisticated, this factor has been substantially reduced to what I believe to be around 1.25-to-1 today.
Out of Sight / Out of Mind
Based on the review of the many projects in which I have been involved, the primary reason for offshore failure is basically the same as it is for US projects: lack of management attention. It is even easier to ignore off-shore projects than it is to ignore a development team down the hall or one floor below where you sit. This includes:
- Just like development firms in the US, off-shore development companies like to sell complete projects (as opposed to resources managed by the customer), giving them more flexibility to manage and deploy their resources profitably. However, this requires these companies to impose the project management structure and discipline necessary for project success; something which only the most disciplined companies are good at.
- Even routine project problems can quickly blow up due to factors such as opposing time zones (developers working during US down hours), lack of understanding of the business process, and generally, the difficulty in communicating.
- Any development project runs into on-going issues such as the need for clarification or additional detail in specifications. Because of time zone differences, the distance of users and the difficulty in communications, off shore teams typically ask fewer questions and make more assumptions. (Everyone involved in software development knows that assumptions are death!)
- The most difficult factor in contracting out software development, either on-shore or off-shore, is ensuring that projects are moving forward correctly (i.e. the developer is building what the user wants). Since mid-project reviews and associated feedback tend to be more difficult with off-shore developers, they are done less.
Even with everyone’s best intentions, all of these factors make it easy for projects to go off the rails. The 4-to-1 cost advantage can easily turn to breakeven or even negative if significant rework is required.
Tactics to Increase the Probability of Success
There are a number of tactics which we used that significantly increased the probability of a successful off-shore project. These include:
- Take Control of Off-Shore Resources. I do not believe that off-shoring of entire projects (including project management) is necessarily the best way to go. I prefer a strategy in which the customer hires off-shore resources to staff the project, while the project management and a senior technical resource (and some testing) is maintained in-house by customers. First, this removes the out-of-sight / out-of-mind problem. Second, this structure allows the customer to keep control of the project and project schedule while managing the communications.
Even if your organization is only providing a Project Manager, the best approach is to integrate the off-shore resources into your team structure. Make sure there is an opportunity for daily communications. (For example, if you are on the East Coast, have developers in India start 2-3 hours later and work later 2-3 hours later so you can communicate with them first thing in the morning.) If you have a daily scrum session, make sure the off-shore resources are included. Alternatively, get a detailed daily update via email with any issues that need to be resolved and review them each morning. Maintain these disciplines throughout the project life cycle.
If you want (or need) to contract out the entire project, make sure you have regular (at least weekly) detailed project reviews and be prepared to make users available to the developers.
- Own the Source Code. One of the biggest problems I have experienced (both with US-based developers and off-shore developers) is that source code is not where it is supposed to be. For US-based developers, this is more easily remedied. For off-shore developers, it has the potential to cause substantial problems (either through everyone’s best or worst intentions). It is impossible to evaluate the work performed to date (or cut off the contractor from the project) if you don’t have access to the Source Code. If you don’t want to open up your organization’s Source Code Control System to outside developers, set up a project in bitbucket, github, or some similar tool and make sure code is checked-in every night. Do a demonstration complete build with the contractor once-a-month. Put this in the contract (see below).
- Own the Application Testing Process. Clearly, it is beneficial to make sure that anything which comes back from the off-shore team is tested by that team. However, it is essential for the contracting organization to test during every release to identify exactly which tasks can be marked as complete. Releases and testing should be incremental (i.e. once per week, twice per month, etc.) Alternatively, have one company doing the development and another doing the testing.
- Requirements / Specification. Make sure that the requirements and build specifications are very clear. In addition to written requirements and specifications, we used medium-fidelity visualizations to make sure that the application will look and flow as desired.
Contracts
Contracts with off-shore companies can be very difficult to enforce since, unless the dollar amount is large, there isn’t really any effective enforcement mechanism. That doesn’t mean that the contract isn’t important. In fact, it is probably more so. In addition to the boilerplate software development contract, the following items are essential:
1. Set the jurisdiction so that it is local to your organization, not in the foreign country.
2. Do not permit resources to be moved on and off the project without your concurrence (or at least notification). It is fairly easy to figure out if resources are being moved around based on (1) the speed at which assigned tasks are completed, (2) the amount of clarification required to correctly complete a task, and (3) the number of assumptions (correct or incorrect) made by the developer for a task. Clearly, a developer working on a project from its inception will have a more thorough background than one coming into the project at a later date.
3. Make sure there are overlapping hours between your organization’s work schedule and the developers work schedule.
4. If you have a daily scrum session (or even a weekly project review), specify it as clearly as possible in the contract (including agenda, estimated length, and who should attend).
5. If you want status reports from developers, testers, or project managers, specify the frequency (daily, weekly, etc.), content, and format.
6. Specify your source code control strategy. Make sure the contract states that all files are to be checked-in at the end of each day. As discussed above, make sure you specify a weekly (or semi-monthly) demonstration build to ensure that the source code is in the correct location.
7. Detail your release strategy (i.e. starting in month 2 of the project, there should be an incremental release every 2 weeks).
8. Identify who is responsible for designing the application architecture.
9. Identify who is responsible for unit and integration testing.
10. If your organization has standards you want followed, make sure they are attached to the contract.
If your vendor will not agree to these terms, there are plenty of off-shore vendors who will. Find another vendor!
Conclusion
Nothing about dealing with off-shore developers should be any different from your organization’s strategy in dealing with on-shore developers. The best strategy for dealing with off-shore developers is to integrate off-shore them into your team and treat them the same as you would your own developers. This will greatly increase the benefit of using offshore developers as well as the likelihood of success.
As a Co-Founder and Principal for Information Concepts, a software development firm, Cary Toor directly managed or oversaw the development of hundreds of software development projects over the 30 years. Cary recently founded T-Ventures Corp to help small companies implement their software products and projects. (Cary.Toor@TVenturesCorp.Com).