Some people think that offshoring software development = outsourcing software development. That’s not the case. You have multiple options. Let’s talk about the main options and how they may or not make sense for you:
1) Outsourcing (Project Based) – If you may have peaks in valleys in your workload (e.g., you have a project that requires a boost in resources for a period of time) it doesn’t make sense to hire full-time staff to address a period of peak demand. In this model, you bid out your project to one or more software development outsourcing companies, and pick a winner. This is what most people think you are talking about when it comes to doing software development offshore. It makes a lot of sense to outsource if you don’t feel that software development is a particular competence you need in house in your business. Or you may think it’s worth investing in your own staff, onshore, but you want to access some lower cost resources offshore from time to time. A downside of this model is that you don’t really get any leverage from the investment you make in training the developers on your business and your systems. The developers scatter to the winds when the project is done. So, in most cases, this isn’t a model I favor. Experience shows that it doesn’t work all that well—you often get a product of questionable quality. On the other hand, if you need some very specific skills for a project—experience with integration to a certain ERP system, or porting your application to a certain mobile device with which your developers have no experience, then this approach could make some good sense. Perhaps you don’t need that skill in-house for the long-run, and hiring an expert for the duration of your project makes a lot of sense.
2) Outsourcing (Dedicated Team) – This is like #1, except in this case you recognize that you have a constant need for software development resources to develop subsequent iterations of your product. This is really a norm for successful software development companies. Perhaps you are using Agile sprints, where you release new functionality periodically—say every 3-4 weeks. And when a sprint is done, you do another one, based on a backlog of requirements that you are working off. So there’s always some new development to be done, as long as new customers and revenue keep coming in. So instead of bidding the project out, as in #1, you contract for a period of, say, 2-3 years with a company that provides you with a dedicated team of developers. You invest in ramping up the team to the point where they understand your product, your development process and your business, and the team gets progressively more productive as their knowledge and understanding grows. A lot of offshore development companies will work with option #1 if they have to, but they prefer option #2. It means a constant revenue stream for them, and in the end they’ll be delivering a better service to the customer as the team’s capabilities grow.
3) Captive – A “captive” offshore development shop is one that works for only one onshore customer. In other words, the onshore company creates a legal entity in the offshore country and builds the software development center the hard way: Hire a lawyer, hire an office manager, rent office space, hire team leads and hire developers, testers, contract for a cleaning service and healthcare insurance, etc. Doing all of these things means that this approach is going to take a lot longer to start up than the others. And there is some risk it just won’t work (e.g., you have no track record in the country and you have trouble hiring good staff). But over the long run it could cost less than outsourcing, and you have the opportunity to create a great culture and, hopefully, benefit from that with low turnover and staff that will go the extra mile to deliver for you. But the savings will only come when you reach a certain scale, so you can spread all of your overhead and up-front costs and hassles over a large number of developers. What scale do you need? In my experience you need at least 25 developers offshore to make it worthwhile, and maybe more (and certainly this would depend on the offshore location you choose). So it’s worth considering a captive operation at that scale, but if you’re not sure you need that many, it’s probably not worth it. If you decide to build your own captive operation, what you won’t get is the benefit of the offshore development company’s expertise. Some offshore development companies have made some good investments in processes and tools. For example, if you visit an offshore development firm, ask for a demo of their automated test tools and see what they can show you. Are their capabilities better or worse than your own? In a lot of cases you’ll find they are better. If you are building your own shop, you can’t benefit from those capabilities—you’ll need to invest on your own. But if you want to get the lowest long-run costs and you can tolerate a slow start-up time, a captive shop could be an option for you.
4) Build, Operate, Transfer (BOT) – BOT is like #2, except the development shop agrees to transfer the team to you after some period of time. So, for instance, at the end of a three-year contract, you might have the option to buy out the team from the development shop, and the employees become yours. Some development shops will agree to do this, and some won’t. And the ones that do are often hoping you won’t bother to buy the team out and they’ll get another few years of revenue from you. The advantage of this approach vs. creating a captive site from scratch, is that you should be able to fire it up much quicker, since you can take advantage of the offshore development company’s pre-existing recruiting capability, office, development processes and tools. Of course you’ll pay for that, but if you strongly feel that the staff should be yours, and not the offshore development company’s, and you are in a hurry to get started and want to reduce your risk, BOT might be a good option for you.
All of these are viable options and the one to choose depends on your needs. The only one I don’t like much is project-based outsourcing (#1) since you don’t benefit from the investment you make in training the developers on your business and systems. If you have a one-off project, or a relatively simple project, or one that requires some very specific skills that you don’t have in house, that might be OK, but otherwise take a look at options 2,3, and 4.
CamiApp 