How not to Offshore

Countries such as India, Malaysia have large number of highly-educated people who are prepared to work for a fraction of the cost of a US or European employee. This is a compelling argument for offshoring, so what could possibly go wrong? As I know from experience and speaking with many others who work in the IT industry, plenty can and does go wrong. We’ve all been on audio conferences where we struggle to understand each other. Despite the education and motivation of the offshore workers, it seems to take about five times more people to get a job done compared to working on-shore. People say yes when they mean no and commit to things they cannot deliver. Incidentally, if you have anything other than a simple request of your bank or utility provider, don’t use the web chat option. It will be routed offshore and there seems to be a cultural desire to help which means people will attempt to do things they don’t have the access or training to do. So what’s going on?

The principal issue is with Communication Span. By moving work offshore, people who used to work closely together are now separated by geography, organisation and time zone. What could previously be resolved by a short conversation now involves tickets, emails, change forms, approvals even meetings. (see A Beautiful Example). Worse, as I explained in Outsourcing is Stupid. Discuss and the following posts, offshoring is mostly carried out through an outsourcer which adds poorly aligned objectives and contract constraints to the communication span.

The worst possible, but very common, scenario is what I call the remote-control model. The classic example has onshore analysts writing program specifications which are then picked up by offshore developers. Developers are seen as a commodity resource, so just get them as cheaply as possible, i.e. offshore. Great theory. As anyone who’s worked as either an analyst or developer (I’ve done both) knows, no spec survives contact with code. The idea that you can write a perfect spec first time which the developer will fully understand and implement in code is bullshit only believed in the rarefied air above the Truth Ceiling. I have frequently seen a piece of work that an analyst (or Solution Architect as seems to be the latest grandiose title) could complete herself in a day or two take several weeks with the usual paper chase. Where are the cost savings now? You can bet they are still being claimed in some pretty presentations courtesy of the Project Management Office. Just cost the inflated offshore days at the onshore rates and you get even bigger savings! Just like the sales, the more you spend the more you save.

Another problem with offshoring through an outsourcing contract is the skills of staff working on your account. Through a bid process and other negotiations, you have likely pushed down the cost of the contract as far as you can, and this is usually achieved by minimising day rates. The outsourcer will respond to this by hiring staff at the lowest rate possible, which means you won’t get highly skilled staff. Of course, you could pay the outsourcer more, but then you’ll get the lowest level of skill they can get away with anyway to maximise their margin.

There are a couple of less obvious problems. You will typically see the introduction of new roles both onshore and offshore to ‘manage the relationship’ Relationship Managers, Service Managers and so on – more laddershakers. Of course, these costs don’t get factored in when declaring success. There is also a lack of incentive to automate repeatable processes as they are seen as being ‘dealt with’ by having them done offshore.

So should you ever offshore? Yes, if you do it right – more on that next week.