I usually use this blog to promote IT outsourcing to SMBs.
While outsourcing makes total sense indeed, the decision to outsource should never be made lightly, as it can yield to a very unpleasant experience. My observation though is that the various failures result from the same few causes, which I listed below as the 10 reasons not to outsource:
-
You never outsourced before and are considering outsourcing a strategic project. If that is the case, start first with a 3 to 4 month long pilot project; it will enable you to learn a lot
-
You believe that when it comes to outsourcing, “the bigger the supplier, the better”. In fact, too big a discrepancy between suppliers and their clients is one of the major reasons why outsourcing projects fail
-
You believe that offshore resources are not as capable as US ones. If you feel like that, your supplier will certainly sense it, and it is bad enough to likely to result in failure
-
Your in-house team has poor project supervision capabilities. Without strict project supervision, chances are that the development team will run loose, and the distance is not going to help. What you should do in this case is first hire a project manager (or subcontract one in your area)
-
Your decision to outsource is only dictated by cost-cutting reasons. I view this one as possibly the most likely cause for failure. Companies in this situation tend to choose the contender who provided with the lowest price offer. If you have got a low price, be sure you will get what you are paying for
-
Sending a problem away does not make it disappear, especially in today’s flat world. I love this comment I read a while ago in CIO magazine. “If you are outsourcing a problem, it will still be a problem”
-
There is no clear consensus in-house on the features to implement. If you are in this case, I suggest the following approach:
-
Write down the 5 major benefits you want to get from your application. They will be the ultimate measure of each deliverable
-
Take your original estimate and multiply it by 2
-
Choose a supplier who has a proven capability to use highly iterative (Agile like) development techniques
-
Make sure you have an interface to the offshore team located in the USA and fluent in English
-
Establish a daily communication line (should be part of Agile), and make sure your supplier has enough command of the English language to make the daily standup meetings profitable
-
-
There is no shortage of talents in your area. Why go offshore? Hire or subcontract locally
-
You are not willing to do your homework on the potential supplier and their country of origin. Take India for instance: the country has poor infrastructure, and their industry is plagued by an insane attrition rate. If these factors are critical for your success, then avoid Indian suppliers; if there are of little relevance in your case, then you can safely consider Indian suppliers as potential providers
-
You cannot communicate your company’s uniqueness. Your organization is unique, and you want the solutions developed for you to be unique too. The problem is that in order to reduce their risks and optimize their profit, some suppliers, especially large ones, will push for reusing existing building blocks, templates or look-and-feel, resulting in an application with little “personality”. One person in your organization should be in charge of making sure your corporate personality (uniqueness) is built in the solution, in other word “what you want is what you get”.
There is no project too big or too small to be outsourced, and no organization too small to successfully outsource some IT developments.
Contrary to a common opinion, outsourcing does not require a lot of extra efforts.
A successful outsourcing operation requires common sense, very good project management and excellent communication skills. With hundreds of thousands of skilled engineers available around the planet, technical resources are NOT an issue.
Email This Post


Hi! Did you redesign? I was entrecard hopping and noticed something different here. Nice.
Left by Vera on October 15th, 2008