By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

If you expect to get top quality work for pennies on the dollar, you are fooling yourself. Prices for outsourced developers can be lower, especially when contracting outside the U.S.; but the common advice "you get what you pay for" applies here as well. Chasing rock-bottom prices when outsourcing software development can lead to missed deadlines, bad code quality and a lot of wasted time and effort.

You can think of off-shore pricing in the same way as in the U.S. There is an average wage for a decent developer. Paying more than that wage will probably get a more skilled person, while paying less will get you someone more junior. Better people produce a better product in less time and overseas rates work the same way.

The culture of the service provider also is an important consideration. Various cultures of the world value different things and these differences can make effective communication difficult.

Any time you describe a feature or function you want in your application, you are (possibly unknowingly) making assumptions. When outsourcing software development, you assume the person you are explaining things to will be able to clarify points they don't understand. You also assume they will point out flaws in the design they can see and you might have missed. You further assume they will do what you ask and not what they think is best. These unconscious assumptions can get you into trouble and there's no way to avoid them because you're simply not aware of them.

If you work with a culture similar to your own, your assumptions and those of the service provider will more closely match, which can reduce the possibility of encountering bumps in the road.

For the first project, it is best to outsource only applications that streamline back-end business processes. Try and keep the embodiment of your strategic advantage in-house. This is not always possible -- especially for small companies with no internal development staff -- but in any case, intellectual property can be difficult and expensive to defend in foreign countries. If you need to outsource your "secret sauce," do so after getting to know your outsourcing provider.

This is not to say you can't outsource your main application; just not the key parts. Well-designed applications are built using many interchangeable pieces. The pieces that entail your strategic advantage should be developed in-house or by a trusted outsourcing firm. Those that provide supporting features can be outsourced successfully, then integrated into the whole.

11 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Briefly, scope, and deliverables expected. Without tightly defining scope you necessarily get what you need, and without defining what you expect as deliverables what you get may not be enough to use what you outsourced.

First and foremost, can they deliver on time. From the experiences I've been involved with, only one project delivered on time and within budget, and had a correspondingly solid quality product at the same time.

@Veretax, you're right. While specifying scope seems obvious, specifying deliverables is often neglected. I've had to reverse engineer several projects when new clients come to me complaining their previous developer won't give them the code. If it's in the contract and part of the standard milestone deliverables, even if the relationship goes bad you've got something to fall back on.

I kind of agree with @MichaelLarsen, but would paraphrase his comment as, “can they deliver a quality product on time.” While that sounds like a simple answer, I think that what we define as quality is variable, which means we’re asking more than a single, simple question.

@mcorum, exactly! The definition of quality differs from person to person. Much more so from culture to culture. Outsourcing overseas requires much more detail in specifying quality measurements. I've found that the culture in South America is more similar to the U. S., and so those unknown assumptions we all make about what's "obvious" are less of a risk.

I have not been happy with the quality of our projects that have been outsourced. I have been asked to test the work of contracted teams because no-one trusted the results of their work.

It's important to factor in the true cost of outsourcing. This includes full-time employee resources who will have to monitor the contracted team, check their work, and maintain their product when they are long gone.

@abuell - How does this affect your willingness to outsource to a different team? Has the experience soured you on the entire idea?

I agree there are shadow costs to outsourcing and they must be included in the ROI calculations. But, if you can find a team that you trust, you can leverage their technical skill to achieve something you may not have been able to do with an in-house team.

Outsourcing is short-sighted and counterproductive. The immediate benefits do more long-term harm than short-term good to a business. Instead of developing in-house talent, instead of keeping Americans working, instead of controlling the end products, companies are abrogating their ability to develop and create.

I am not a fan of outsourcing. I worked with a software system that basically had programmer names I could not pronounce even on a good day. Whether they were outsourced or hired as contractors by the software company I do not know. My issue is the code, in a lot of cases was not the easiest to read or the most efficient. In some case we re-wrote modules to boost performance. It may have been cheaper for the software vendor but if customers have to write work around code to make it usable, they will not get positive feedback. It may cause them to lose future customers.