Sensible Offshoring

Last week I talked about how common offshoring models can and do go badly wrong, reducing or eliminating the savings expected from lower labour rates. The key problem here is in increasing communication span. I think of it like pulling a slice of pizza away from the rest; the strings of cheese that stretch between the two represent the more difficult communication between the people involved. I admit I am somewhat anti-offshoring, not least as it exports jobs from the national economy, but if you must do it there are models that work well.

The simplest way to avoid the pitfalls of outsourcing is to buy services. That way you don’t care how many people are involved, where they work or who they work for. If the supplier screws up their own organisation, that will reflect in their costs and assuming a competitive market (quite a big assumption I admit) they won’t survive. There is still a trap here though. Because services are such an attractive model, you may be tempted to dress up a requirement as a service when it is not. Take bug fixing for example; you pay a fixed rate per bug reported or bug fixed. Sounds simple? It isn’t. Every bug is different and you cannot reliably predict how many you will get or how much effort will be needed to fix them. You’ll make the supplier jump through hoops and come up with some sort of plausible contract, but they will either end up charging you what is essentially a man-day rate, or they will build healthy headroom into the contract to cover the uncertainty. There will also be a significant overhead in billing, plus endless debates about what is a simple, medium or complex defect. The supplier will of course push everything to the highest level of complexity, and if you have given away your expertise, how are you going to counter that? Of course, you could retain some expertise and thus engage in some twinning.

A good service model has a very simple structure. For example, handing off payments to a third party provider works fine. You pay a set fee or percentage agreed up front, the supplier takes the payment and gives you the money, less their cut. If there’s an API for it, then that’s a good sign. If the service does not have a simple definition, do something else (like employ your own staff).

If you are a small / medium sized organisation then outsourcing likely already makes sense as a way for you to access expensive niche skills people that you don’t have the critical mass to employ full time. If you’re already outsourced, then your communication span is already lengthened and having the outsourcer provide resources from offshore won’t make it much worse. Go into it with your eye open though and look at the full picture, not just the supplier’s day rates. If working with offshore teams causes delays elsewhere in your organisation, are you really saving money?

Finally, if you are a large multinational, consider setting up your own offshore centre. I have seen this work well where the offshore team are motivated by feeling part of the organisation they are working for. Offshore teams can have more autonomy (if you avoid the remote-control model) as they are not constrained by a contract. Without the distortion of an outsourcing contract, objectives are aligned.