Offshoring – the good, the bad and the ugly


offshore concerns

offshore concerns

So, this post may be a bit contentious. I am a big believer in the appropriateness of tool use – don’t use a hammer to turn screws, a screwdriver to pry apart boards on the wall, or a crowbar to drive nails. Having said this, I really do not think that offshoring is useful for anything but very, very defined projects; as such, I do not suggest it much it all.

Offshoring is a great way to save lots of money from technology costs, particularly those pesky IT costs. However, if the actual labor cost is the only criteria that you use, you should hire children in the cheapest fourth-world country that you can find. This would be a disaster, of course; it completely fails to take into account the value provided for the cost.

Cheap, fast, good – choose one

What the financial and accounting groups that strongly push offshoring forward does not take into account is the ROI. The uneducated children in the example above would be dirt cheap but given that they would provide garbage, the ROI is non-existent. As the cost grows, the value should as well and in greater proportion so that the ROI for any expenditure is as high as possible. The usual argument given for the use of offshore resources is that technology and IT values are fixed, so that the best ROI is found by reducing the input costs as much as possible. For any functionality that fits this description, I certainly have sympathy; it is, however, completely incorrect for the one of largest category of IT spending – product development.

From product development, the value from the IT group is most certainly not fixed; if it is, you are probably in a commodity category and need to think a little differently about how you approach technology. For fixed value output functions – email administration, network setup, support, etc. – the best and least expensive way to provide these services is to automate them. There is no need to have a person fulfilling this technology output, certainly not for the simple reason of just having a person there.

Support is a different beast

Support is a classic example of this – these services are sent offshore to cheapen costs but customers are not happy with the service they receive in the vast majority of these circumstances. If your support is a service differentiator, you are best served by handling it locally; if it is not, you should automate as much as possible and still use local personnel – this will give a better customer experience and allow you to charge a premium or serve a value-add for your marketing and sales efforts. One of the companies at which I worked in the past had such a good support group – as expensive as they were – that they would routinely win business against a much larger and funded competitor. It grew to the point that the competitor had to buy out our company to focus its efforts on combating open source challengers.

Product development is different

Product development, on the other hand, will be the main value proposition for your company. This is most certainly not a fixed-value activity and should be considered a critical part of the business. Active collaboration, multiple iterations, and back and forth communication are critical for developing the best product, as is active investment in the company by the people actually doing the work. This is difficult to do even with contractors on-site – they are there for communication and collaboration, but they do not have the same desire to make the company succeed.

For offshore personnel, however, this difficulty is multiplied by a thousand. Communication is a challenge due to language, time zones, and lack of face-to-face contact. These can be ameliorated somewhat with video conferencing and careful selection of vendor services. This does not remove the problem, however – it only reduces it. In addition, cultural differences exist regardless of the experience level of the people involved and will reduce any ability to produce the best product from this back and forth discussion. This difficultly depends heavily on the type of technology output being proposed – software packages for the mining industry (some similarities throughout the world due to physical limitations) will be easier and less subject to culture-specific biases versus a social media network, which is heavily dependent on the country, region, or even city in which the development occurs. The latter case will introduce huge problems in decision-making for the people creating the technology.

Coding is different from product development

Note – merely coding something that has already been fully designed and realized is *not* the same as product development in my mind. This activity is one of the areas where I am fine with and support using offshore resources, as there are minimum requirements for collaboration and maximum potential for creating milestones and overseeing the project.
—————————————————
Image courtesy of iStock

Questions to ask your IT provider (part 1) - backups
How do create a Minimum Viable Product (MVP) for your startup in 14 days or less

Leave a comment

Your email address will not be published. Required fields are marked *