First a few words about the idea of offshoring. Many developers think offshoring is a threat to their job. I can tell you right now that if you can potentially be replaced by an offshore developer, then yes, you have a big problem. You are just a developer. Being just a developer can get you replaced fairly quickly, even by another local developer. To avoid being replaced you must become a problem solver: a problem solver whose specialty is software development.

This post is not about the potential threat of offshoring for your job, so if you are particularly concerned by that, keep reading this blog, I have few articles directly related to developer job security coming.  Meanwhile, you can check existing content that covers the subject. A few years ago, Chad Fowler wrote a book called My Job Went to India: 52 Ways to Save Your Job, later renamed The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life). I highly suggest you purchase the book as it summarizes it pretty well.

The advantages of outsourcing

There are several advantages for local development teams in outsourcing a part of their software projects.

  • You have access to talent worldwide: given the difficulty for western countries to find skills locally, access to talent worldwide is a real asset. There are tons of great developers out there waiting to provide you the best.
  • Cost controlled to the cent: outsourced projects can be started and stopped very quickly.
  • Highly scalable: because of the availability of the skills out there, it’s very easy to scale up.
  • Empower your local team: if you use outsourcing to empower your local team instead of trying to replace it, you’ll get best results.
  • You contribute to a better world: a developer you hire in India is able to support a whole family alone with only one salary. If you pay him the same rate as in your own country (which I do often when I’m financially able to), a whole village can be supported.

The only potential disadvantages are directly related to the way you manage them. Over the past 10 years I have outsourced up to 400 projects with hundreds of different providers spread over all 5 continents. Here are the 10 core principles that allowed me to reach almost 100% success rate with my recent outsourced projects. These 10 principles are divided into 3 categories: choice, supervision & strategy.

Choice

Choice is about picking the right guys. Choice is very important and you should spend time on it.

1. Avoid lowest & highest bidders

The potential problem you may encounter with lowest bidders is obvious. When asked what he thought about as he sat atop the Redstone rocket, waiting for liftoff, Alan Shepard answered “The fact every part of this ship was built by the low bidder”.  What about the highest ones? It seems that there is some correlation between bid amount and quality of the deliverable you will get. However, I found that in most cases, quality was high enough with average bidders and therefore selecting highest bidders would be a total waste of your project budget.

2. Check ratings

Offshoring platforms often give you the rating of previously completed jobs. That information should be taken seriously and used to make your choice. You wouldn’t hire anyone without checking with his 2 or 3 previous bosses right?  On a rating scale of 10, I usually discard any bid with a rating under 9 as well as bidders without any rating yet. Sometimes, I forget this rule for very small project so I can help new providers to get their first rating.

3. Prioritize motivation

Many bidders bid without reading your specifications carefully. I know this because I have posted absurd or incomplete specifications in the past (by mistake) and very few bidders actually reported it. Now I read all cover letters carefully and give more credit to those who actually write about the project itself. Some bidders will write about possible solutions to your problem and others will actually discuss how they will implement it. In practice, I have observed that the most motivated ones tend to perform better than the others.

Supervision

4. Protect your intellectual property

Seems obvious right?  But still, that’s one of the most common mistakes as most of us completely forget it. Things can go bad and the company you hired for the project can claim full ownership of their work. Or worse, they decide to use what you paid for in their own businesses. Ensure that a proper NDA and intellectual property rights assignment is signed. Most offshoring platforms provide that by default, but if you plan to go alone with no support, this is something you must handle yourself and require before starting work.

5. Refuse custom frameworks

Very often the developers or company you hire decide to use a custom framework or library they have written. Verify it is acceptable to you. Sometimes the development shop will give you full rights on the code they wrote specifically for you but not for their libraries. This is problematic. You have a huge problem if you are so dependent on them that changing trivial things in the application requires you to hire the same development shop. It’s not only about legal stuff, but also the potential complexity of the code that they wrote that makes it impossible for the standard developer to understand. Keeping the potential to continue your project without them is a really important choice that you will want to keep.

6. Impose standards

Make sure that they use standards in the technology of choice. Even if they don’t use specific custom libraries (see previous point), you may face another problem: a specific way of coding that doesn’t meet industry standards and globally accepted guidelines. In the worst case, you could be forced to rewrite everything from scratch to make any maintenance possible. I tend to give priority to main stream technologies for that reason. PHP or .NET for instance, depending on the project I outsource.

7. Review early, review often

You don’t want to discover at the end of the project the code did not meet your quality standards, eg missing comments, missing or poor documentation, poor coding practices, etc. Reviewing the work frequently will allow you to give feedback early in the development phase. Reviewing frequently is also the most effective way to adjust any misunderstandings of your specifications. Each review gives you the opportunity to clarify requirements.

In addition to requesting frequent demonstrations, require access to the repository. If this is not possible, request that you are sent the full source every week for review.

 

Strategy

8. Test providers with small projects

Before I give a bigger project to a provider, I test them with one or two smaller ones. I also try to give specific projects to specific providers that have performed well in the past on similar stuff. For example, I outsourced few web design jobs to a provider through a well known offshoring platform and now I work with him directly by email because I know he will perform really well.

9. Accept multiple bidders to reduce risk

For critical projects, I select two or three bidders then I take the best implementation. This works best with very small projects (under $5000). It takes more of your time but it is sometimes required. It was with this approach that I discovered that bidders with motivated content perform better than others.

For bigger projects, you can use a combination of the point 8 and this one: you test multiple bidders with a small chunk of your big project and see which one performs the best.

10. Assemble components

Another way to reduce risk is to outsource components that your core team can assemble locally. One advantage of this approach is that you can easily switch between providers and no one really gets access to the whole thing (reduce intellectual property risks).  But the most underrated benefit of this approach is that your architects are then obliged to develop an open architecture that will help you extend the application or replace whole parts of it painlessly in the future.

Final thoughts

Applying these principles alone is not enough. You will need to fail a few times to really learn what can be written in a simple blog post. Experience gained by practice is the only way to success. Don’t get discouraged if your first 2 offshoring projects fail. Offshoring empowers thousands of teams worldwide and you can do it too.