North Americans are relentless at wanting things as cheap as possible. This drive is what has led many companies to look at using less expensive resources from other countries help bring down the costs of products and services. Some have succeeded, but many more have failed. And until a couple of years ago, I never really understood why.

Then I got an opportunity to find out first-hand, and relocated to Costa Rica for a year and a half, working on the other end of the offshoring pipeline. I’d like to think I’ve got a fairly decent idea of how an offshore service company operates. Not just in terms of hiring people, assigning work, and handling the operation of the company, but also in terms of dealing with clients — the people who want to use an offshore company.

If you are such a company looking for cheaper alternatives, I have good news for you: there’s only two models you should ever have to worry about. The bad news? One of those models has a pretty darn big hole in it.

Software development is a strange beast to begin with. Whereas something physical, like a t-shirt, can be held and examined for construction and quality, software has always been a tougher nut to crack. You need well-trained, keenly-minded people to check and recheck a software release to make sure it will function as designed. And given a dozen developers, you’ll get two dozen different ways to solve the same problem.

But I’m getting ahead of myself. That’s assuming you’ve even managed to explain the problem adequately in the first place.

The two models are separated by one thing: organisation. Namely, your organisation. Not your company, but your ability to gather together information, assets, and direction, and then provide it all in a coherent consistent manner to your development partner.I used to be on the providing side. Now, I receive it. So I’d like to think I have a unique perspective.

Staff Augmentation

The first model is the one that many companies would like: the simple ability to quickly add a few extra skilled (and presumably inexpensive) people to their project to help achieve deadlines and not blow your budget out of the water.

The goal is simple: add a couple of people, and continue much as you would if you had those same people sitting in your office. You might only know them through email, possibly through phone calls or IM, but you treat them (mostly) as a part of your team. At least until the work (or the contract) runs out, anyway.

And in reality, this is the model that usually doesn’t work.

The problem here is that most companies aren’t organised enough to handle this responsibly. What they want is (near-) instant comprehension, and quick turnaround, usually with as few people as possible. Almost always, those companies fail to understand that their offshore provider isn’t a part of their company, which means there’s a cultural divide (not just corporate, but usually social, as well).

I know, this sounds like a silly point: of course they’re not part of the company. It’s an obvious point, but only when you’re separated from it. When you’re in the thick of it, chances are you won’t think about it, you will only see that there are poorly-performing people on the team.

This is something I see more often than I’d care to see. A project is in trouble, and it’s utterly necessary to have additional people work on the project as soon as possible. But there’s not enough documentation, not enough information, and the newly-augmented staff start to struggle quickly because they cannot know enough.

The only way to (somewhat) solve this is with supervision – someone who is actively overseeing the extra hands, providing some level of direction and assurance. But, as noted, it’s only a partial solution, since you’re still dealing with different cultures.

Service

The best kind of offshoring is a proper Service: whole aspects of work (such as maintenance or quality assurance) that are farmed out in their entirety to another organization. By splitting the effort off, you aren’t trying to mingle cultures (as much) and there’s a greater chance for success.

The theory is this: where the given group doing the particular practice physically sits is mostly irrelevant. So long as they are responsible for the work, without integration with an in-house team doing the same thing (which is where differences in cultures and practices arise), you’ll have fewer problems.

You won’t eliminate problems, however – you’ll still need to be very clear on communication (what’s being done, when is it due, how to establish feedback) and expections. And you’ll need to do regular check-ins (at least twice weekly) to ensure things are proceeding according to plan, and allow the offshore team to raise any concerns (that haven’t been brought up via email, ticketing sytems, etc.)

The biggest problem to eliminate, however, is assumption. Notably, your assumption – you’ll assume that the offshore is a professional organization that will deliver exactly what you want. And that can’t be further from the truth. The people in that organization might be professional, but they’re not mind-readers: they don’t know you, they don’t think like you, and they’ve been taught differently. They’ll (probably) do good work, but it won’t be to your standards or your requirements, unless they are very clearly stated from the start.

In either case, just remember to not just lob things over the fence. Just as in real life: garbage over, garbage back.